From report at bugs.python.org  Fri Jan  1 04:28:27 2010
From: report at bugs.python.org (Richard Hansen)
Date: Fri, 01 Jan 2010 03:28:27 +0000
Subject: [New-bugs-announce] [issue7615] unicode_escape codec does not
	escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>


New submission from Richard Hansen <rhansen at bbn.com>:

The description of the unicode_escape codec says that it produces "a
string that is suitable as Unicode literal in Python source code." [1] 
Unfortunately, this is not true as it does not escape quotes.  For example:

  print u'a\'b"c\'\'\'d"""e'.encode('unicode_escape')

outputs:

  a'b"c'''d"""e

I have attached a patch that fixes this issue by escaping single quotes.
 With the patch applied, the output is:

  a\'b"c\'\'\'d"""e

I chose to only escape single quotes because:
  1.  it simplifies the patch, and
  2.  it matches string_escape's behavior.


[1] http://docs.python.org/library/codecs.html#standard-encodings

----------
components: Unicode
files: unicode_escape_single_quotes.patch
keywords: patch
messages: 97112
nosy: rhansen
severity: normal
status: open
title: unicode_escape codec does not escape quotes
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15716/unicode_escape_single_quotes.patch

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

From report at bugs.python.org  Fri Jan  1 06:38:07 2010
From: report at bugs.python.org (ivank)
Date: Fri, 01 Jan 2010 05:38:07 +0000
Subject: [New-bugs-announce] [issue7616] test_memoryview
	test_setitem_writable failures with Intel	ICC
In-Reply-To: <1262324287.94.0.590004351292.issue7616@psf.upfronthosting.co.za>
Message-ID: <1262324287.94.0.590004351292.issue7616@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

3 memoryview tests fail with Intel ICC 11.1. They don't fail with gcc
4.4.1-4ubuntu8 on the same machine.


======================================================================
FAIL: test_setitem_writable (__main__.BytesMemorySliceSliceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_memoryview.py", line 98, in test_setitem_writable
    self._check_contents(tp, b, b"ababcf")
  File "Lib/test/test_memoryview.py", line 290, in _check_contents
    self.assertEquals(obj[1:7], tp(contents))
AssertionError: bytearray(b'ababaf') != bytearray(b'ababcf')

======================================================================
FAIL: test_setitem_writable (__main__.BytesMemorySliceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_memoryview.py", line 98, in test_setitem_writable
    self._check_contents(tp, b, b"ababcf")
  File "Lib/test/test_memoryview.py", line 273, in _check_contents
    self.assertEquals(obj[1:7], tp(contents))
AssertionError: bytearray(b'ababaf') != bytearray(b'ababcf')

======================================================================
FAIL: test_setitem_writable (__main__.BytesMemoryviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_memoryview.py", line 98, in test_setitem_writable
    self._check_contents(tp, b, b"ababcf")
  File "Lib/test/test_memoryview.py", line 263, in _check_contents
    self.assertEquals(obj, tp(contents))
AssertionError: bytearray(b'ababaf') != bytearray(b'ababcf')



# icc --version
icc (ICC) 11.1 20090630

The OS is Ubuntu 9.10 64-bit in VMWare, running 2.6.31-16-server.

My configure options are:

export LANG=C
./configure --enable-unicode=ucs2 --with-gcc=icc --with-cxx-main=icc\
            OPT="-O2 -w1 -fomit-frame-pointer -xHost -multibyte-chars
-fp-model precise -no-prec-div"

----------
components: Library (Lib)
messages: 97113
nosy: ivank
severity: normal
status: open
title: test_memoryview test_setitem_writable failures with Intel ICC
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  1 14:38:06 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 01 Jan 2010 13:38:06 +0000
Subject: [New-bugs-announce]
	[issue7617]	distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option()	should
	recognize ${configuration_name}-gcc
In-Reply-To: <1262353086.09.0.683625884424.issue7617@psf.upfronthosting.co.za>
Message-ID: <1262353086.09.0.683625884424.issue7617@psf.upfronthosting.co.za>


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

distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option()
currently only recognizes "gcc" or "gcc-${version" (e.g. "gcc-4.4.2"),
but it doesn't recognize "${configuration_name}-gcc" (e.g. "x86_64-pc-
"x86_64-pc-linux-gnu-gcc-4.4.2"). Python is configured with such fully
qualified configuration names in some distributions (e.g. Gentoo).

Configuration names are described in:
http://sourceware.org/autobook/autobook/autobook_17.html
http://www.gnu.org/software/autoconf/manual/html_node/Specifying-

----------
assignee: tarek
components: Distutils
files: python-distutils-recognize_configuration_names.patch
keywords: patch
messages: 97114
nosy: Arfrever, tarek
severity: normal
status: open
title: distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option() should recognize ${configuration_name}-gcc
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15717/python-distutils-recognize_configuration_names.patch

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

From report at bugs.python.org  Fri Jan  1 19:45:50 2010
From: report at bugs.python.org (Artem)
Date: Fri, 01 Jan 2010 18:45:50 +0000
Subject: [New-bugs-announce] [issue7618] optparse library documentation has
	an insignificant	formatting issue
In-Reply-To: <1262371550.06.0.14749743487.issue7618@psf.upfronthosting.co.za>
Message-ID: <1262371550.06.0.14749743487.issue7618@psf.upfronthosting.co.za>


New submission from Artem <vazovsky.reg at gmail.com>:

In optparse documentation, in the end of first chapter there is an
example which shows how optparse can print usage summary for user. In
the last row of this example text color is accidentally changed from
black to blue. Most probably the source of this issue is single quote
sign which is misinterpreted by the code highlighter.

----------
assignee: georg.brandl
components: Documentation
messages: 97119
nosy: georg.brandl, vazovsky
severity: normal
status: open
title: optparse library documentation has an insignificant formatting issue
versions: Python 3.1

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

From report at bugs.python.org  Fri Jan  1 23:22:52 2010
From: report at bugs.python.org (djc)
Date: Fri, 01 Jan 2010 22:22:52 +0000
Subject: [New-bugs-announce] [issue7619] imaplib shouldn't use cause
	DeprecationWarnings in 2.6
In-Reply-To: <1262384572.13.0.48856105393.issue7619@psf.upfronthosting.co.za>
Message-ID: <1262384572.13.0.48856105393.issue7619@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

imaplib still calls os.popen2(), which has been deprecated in 2.6. It
should probably use subprocess instead, even in 2.6, IMO.

See http://bugs.gentoo.org/show_bug.cgi?id=282859

----------
components: Library (Lib)
messages: 97121
nosy: djc
severity: normal
status: open
title: imaplib shouldn't use cause DeprecationWarnings in 2.6
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan  2 16:10:13 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 02 Jan 2010 15:10:13 +0000
Subject: [New-bugs-announce] [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>


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

'python.vim' syntax rules script was created for python 2 
(automatically, using script 'vim_python.py').

This patch updates it to run by python 3.

Some bugs with highlighting strings and numbers are resolved, too.

Also, 'syntax_test.py' is updated; relatively extensive tests on 
numbers, strings and statements added.

----------
components: Demos and Tools
files: vimsyntax.diff
keywords: patch
messages: 97134
nosy: July
severity: normal
status: open
title: Vim syntax highlight
type: feature request
versions: 3rd party
Added file: http://bugs.python.org/file15719/vimsyntax.diff

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

From report at bugs.python.org  Sat Jan  2 17:48:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jan 2010 16:48:27 +0000
Subject: [New-bugs-announce] [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>


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

[Test]

`configure` should support --with-system-expat option (similarly to
--with-system-ffi) to use an internal copy of expat. It will be useful
for some distributions (e.g. Gentoo), which prefer to use system
libraries instead internal copies.

----------
messages: 97137
nosy: georg.brandl
severity: normal
status: open
title: Test issue

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

From report at bugs.python.org  Sun Jan  3 18:09:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 17:09:45 +0000
Subject: [New-bugs-announce] [issue7622] [patch] improve unicode methods:
	split() rsplit() and	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Content of the patch:
 - removed code duplication between bytearray/string/unicode
 - new header "stringlib/split.h" with common methods:
    stringlib_split/_rsplit/_splitlines
 - added "maxcount" argument to "stringlib_count"
 - better performance for split/replace unicode methods

Benchmark coming soon...

----------
components: Interpreter Core
files: stringlib_split_replace.diff
keywords: patch
messages: 97168
nosy: flox
severity: normal
status: open
title: [patch] improve unicode methods: split() rsplit() and replace()
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file15726/stringlib_split_replace.diff

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

From report at bugs.python.org  Sun Jan  3 18:29:18 2010
From: report at bugs.python.org (Winfried Plappert)
Date: Sun, 03 Jan 2010 17:29:18 +0000
Subject: [New-bugs-announce] [issue7623] PropertyType missing in Lib/types.py
In-Reply-To: <1262539758.51.0.472094594886.issue7623@psf.upfronthosting.co.za>
Message-ID: <1262539758.51.0.472094594886.issue7623@psf.upfronthosting.co.za>


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

I wonder why there is not PropertyType defined in Lib/types.py. I found it out the hard way when I was xref'ing my Python files and the program died missing a key "<type 'property'>". It can easily be defined as PropertyType  = type(property()). See also Issue1327971  where PropertyType gets defined locally and the matching diff file,  http://bugs.python.org/file13036/test_pyclbr_property.diff.

----------
components: Library (Lib)
messages: 97169
nosy: wplappert
severity: normal
status: open
title: PropertyType missing in Lib/types.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Jan  3 20:13:33 2010
From: report at bugs.python.org (Roger Gammans)
Date: Sun, 03 Jan 2010 19:13:33 +0000
Subject: [New-bugs-announce] [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>


New submission from Roger Gammans <rgammans at computer-surgery.co.uk>:

The following sequence causes isinstance to raise an exception rather than to return False.

>>> class foo:
...     pass
... 
>>> import collections
>>> isinstance(foo,collections.Callable)
True
>>> isinstance(foo(),collections.Callable)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/abc.py", line 131, in __instancecheck__
    return (cls.__subclasscheck__(subclass) or
  File "/usr/lib/python2.6/abc.py", line 147, in __subclasscheck__
    ok = cls.__subclasshook__(subclass)
  File "/usr/lib/python2.6/_abcoll.py", line 117, in __subclasshook__
    if any("__call__" in B.__dict__ for B in C.__mro__):
AttributeError: class foo has no attribute '__mro__'
>>>

----------
components: Library (Lib)
messages: 97175
nosy: rgammans
severity: normal
status: open
title: isinstance(... ,collections.Callable) fails with oldstyle class i nstances
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan  3 21:04:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 20:04:29 +0000
Subject: [New-bugs-announce] [issue7625] bytearray needs more tests for
	"b.some_method()[0] is not	b"
In-Reply-To: <1262549069.0.0.191506722529.issue7625@psf.upfronthosting.co.za>
Message-ID: <1262549069.0.0.191506722529.issue7625@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

There's not enough tests to verify such cases:
 - b.split()[0] is not b
 - b.rsplit()[0] is not b
 - b.splitlines()[0] is not b
 - b.partition('.')[0] is not b
 - b.rpartition('.')[0] is not b
 - (other ?)

However similar tests exist in Lib/test/test_bytes:
 * ByteArrayTest.test_copied()
   -> some tests for ('replace', 'translate')
 * ByteArrayTest.test_partition_bytearray_doesnt_share_nullstring
   -> some tests for ('partition', 'rpartition')
 * BytearrayPEP3137Test.test_returns_new_copy()
   -> some tests for ('zfill', 'rjust', 'ljust', 'center')

----------
components: Tests
messages: 97176
nosy: flox
priority: low
severity: normal
stage: needs patch
status: open
title: bytearray needs more tests for "b.some_method()[0] is not b"
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan  3 21:13:29 2010
From: report at bugs.python.org (Stefan Schweizer)
Date: Sun, 03 Jan 2010 20:13:29 +0000
Subject: [New-bugs-announce] [issue7626] Entity references without semicolon
	in HTMLParser
In-Reply-To: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>
Message-ID: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>


New submission from Stefan Schweizer <steve.schweizer at gmail.com>:

HTMLParser should only handle entity references that are terminated with a semicolon. I know that the semicolon can be omitted in some cases (http://www.w3.org/TR/html4/charset.html#h-5.3) and that some browsers are more tolerant, but the following example causes some odd output:

>>> import HTMLParser
>>> class EntityrefParser(HTMLParser.HTMLParser):
...     def handle_data(self, data):
...         print "handle_data '%s'" % data
...     def handle_entityref(self, name):
...         print "handle_entityref '%s'" % name
... 
>>> p = EntityrefParser()
>>> p.feed("<p>spam&eggs are delicious</p>")

Expected Result:
handle_data 'spam&eggs are delicious'

Actual Result:
handle_data 'spam'
handle_entityref 'eggs'
handle_data ' are delicious'

----------
components: Library (Lib)
messages: 97177
nosy: stefan.schweizer
severity: normal
status: open
title: Entity references without semicolon in HTMLParser
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan  4 01:25:11 2010
From: report at bugs.python.org (Rob Austein)
Date: Mon, 04 Jan 2010 00:25:11 +0000
Subject: [New-bugs-announce] [issue7627] mailbox.MH.remove() lock handling
	is broken
In-Reply-To: <1262564711.76.0.763774175522.issue7627@psf.upfronthosting.co.za>
Message-ID: <1262564711.76.0.763774175522.issue7627@psf.upfronthosting.co.za>


New submission from Rob Austein <sra at hactrn.net>:

.remove() method of MH class in the mailbox module of the standard library references a file object after closing it.  This throws a ValueError exception (I/O operation on closed file).

The f.close() call just before the os.remove() call in the innermost try: block should just be removed, the finally: clause of the outer try: block will clean things up correctly.  As far as I know it is completely legal (if slightly unusual) to delete an open file on any unix-like operating system, and the locking semantics won't work correctly otherwise in any case.

----------
components: Library (Lib)
messages: 97185
nosy: sraustein
severity: normal
status: open
title: mailbox.MH.remove() lock handling is broken
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan  4 02:59:25 2010
From: report at bugs.python.org (bkovt)
Date: Mon, 04 Jan 2010 01:59:25 +0000
Subject: [New-bugs-announce] [issue7628] round() doesn't work correctly in
	3.1.1
In-Reply-To: <1262570365.97.0.975021093737.issue7628@psf.upfronthosting.co.za>
Message-ID: <1262570365.97.0.975021093737.issue7628@psf.upfronthosting.co.za>


New submission from bkovt <bkovt-python at yahoo.com>:

round(125, -1) produces 120 in Python 3.1.1. It produces 130.0 in 2.6.4.

----------
messages: 97186
nosy: bkovt
severity: normal
status: open
title: round() doesn't work correctly in 3.1.1
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jan  4 03:17:16 2010
From: report at bugs.python.org (Markus)
Date: Mon, 04 Jan 2010 02:17:16 +0000
Subject: [New-bugs-announce] [issue7629] Compiling with mingw32 gcc,
	content of variable "extra_postargs" invalid
In-Reply-To: <1262571436.76.0.58896649428.issue7629@psf.upfronthosting.co.za>
Message-ID: <1262571436.76.0.58896649428.issue7629@psf.upfronthosting.co.za>


New submission from Markus <hardcorevenom at gmx.de>:

I tried to build "pylzma" with "python setup.py build -cmingw32" and got the following message.

C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DWIN32=1 -DCOMPRESS_MF_MT=1 -DWITH_COMPAT=1 -IC:\work\dev\Python26\include -I. -IC:\work\dev\Python26\include -IC:\work\dev\Python26\PC -c pylzma.c -o build\temp.win32-2.6\Release\pylzma.o /MT
gcc: /MT: No such file or directory

"/MT" is the content of variable "extra_postargs" in "cygwinccompiler.py" upon the gcc call. Oddly "/MT" is a switch of the MSVC compiler not MinGW.
I modified "cygwinccompiler.py" and cleared extra_postargs with "[]" it compiled without a problem then.

----------
assignee: tarek
components: Distutils
messages: 97187
nosy: popelkopp, tarek
severity: normal
status: open
title: Compiling with mingw32 gcc, content of variable "extra_postargs" invalid
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan  4 06:41:58 2010
From: report at bugs.python.org (parmax)
Date: Mon, 04 Jan 2010 05:41:58 +0000
Subject: [New-bugs-announce] [issue7630] Strange behaviour of decimal.Decimal
In-Reply-To: <1262583718.55.0.703932214446.issue7630@psf.upfronthosting.co.za>
Message-ID: <1262583718.55.0.703932214446.issue7630@psf.upfronthosting.co.za>


New submission from parmax <md5xxx1 at gmail.com>:

>>> from decimal import Decimal
>>> dec = Decimal(2 ** 1024)
>>> dec
Decimal('179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216')
>>> dec += Decimal('0.1')
>>> dec
Decimal('1.797693134862315907729305191E+308')
>>> dec == Decimal(2 ** 1024) + Decimal('0.1')
True
>>> dec -= Decimal(2 ** 1024)
>>> dec
Decimal('2.109752663820230210576934273E+280')
>>> dec == Decimal('0.1')
False
>>>

----------
components: Library (Lib)
messages: 97192
nosy: parmax
severity: normal
status: open
title: Strange behaviour of decimal.Decimal
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan  4 10:58:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Jan 2010 09:58:58 +0000
Subject: [New-bugs-announce] [issue7631] undefined label: bltin-file-objects
In-Reply-To: <1262599138.12.0.461032308241.issue7631@psf.upfronthosting.co.za>
Message-ID: <1262599138.12.0.461032308241.issue7631@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

~/dev/py3k-wide/Doc$ make html
[...]
/home/wolf/dev/py3k-wide/Doc/library/filesys.rst:30: WARNING: undefined
label: bltin-file-objects -- if you don't give a link caption the label
must precede a section header.                                                  
/home/wolf/dev/py3k-wide/Doc/library/socket.rst:578: WARNING: undefined
label: bltin-file-objects -- if you don't give a link caption the label
must precede a section header.                                                  
/home/wolf/dev/py3k-wide/Doc/library/tokenize.rst:19: WARNING: undefined
label: bltin-file-objects -- if you don't give a link caption the label
must precede a section header.                                                 
/home/wolf/dev/py3k-wide/Doc/reference/datamodel.rst:784: WARNING:
undefined label: bltin-file-objects -- if you don't give a link caption
the label must precede a section header.                                             
/home/wolf/dev/py3k-wide/Doc/using/cmdline.rst:238: WARNING: undefined
label: bltin-file-objects -- if you don't give a link caption the label
must precede a section header.
[...]

This is because http://docs.python.org/library/stdtypes.html#bltin-file-objects doesn't exist anymore in py3k

----------
assignee: georg.brandl
components: Documentation
messages: 97201
nosy: ezio.melotti, georg.brandl, pitrou
severity: normal
status: open
title: undefined label: bltin-file-objects

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

From report at bugs.python.org  Mon Jan  4 13:50:05 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jan 2010 12:50:05 +0000
Subject: [New-bugs-announce] [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>


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

In a debug build:

Python 3.2a0 (py3k:76671M, Dec 22 2009, 19:41:08) 
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "2183167012312112312312.23538020374420446192e-370"
[30473 refs]
>>> f = float(s)
oversize b in quorem

----------
messages: 97205
nosy: eric.smith, mark.dickinson, skrah
severity: normal
status: open
title: dtoa.c: oversize b in quorem
versions: Python 3.2

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

From report at bugs.python.org  Mon Jan  4 14:01:13 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jan 2010 13:01:13 +0000
Subject: [New-bugs-announce] [issue7633] decimal.py: type conversion in
	context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>


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

I think that context methods should convert arguments regardless of position:

Python 2.7a0 (trunk:76132M, Nov  6 2009, 15:20:35) 
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> c = getcontext()
>>> c.add(8, Decimal(9))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 3866, in add
    return a.__add__(b, context=self)
TypeError: wrapper __add__ doesn't take keyword arguments
>>> 
>>> c.add(Decimal(9), 8)
Decimal('17')
>>> 


Also, perhaps c.add(9, 8) should be allowed, too.

----------
messages: 97207
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: type conversion in context methods

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

From report at bugs.python.org  Tue Jan  5 01:19:51 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 05 Jan 2010 00:19:51 +0000
Subject: [New-bugs-announce] [issue7634] next/previous links in
	documentation skip some sections
In-Reply-To: <1262650791.24.0.247088120925.issue7634@psf.upfronthosting.co.za>
Message-ID: <1262650791.24.0.247088120925.issue7634@psf.upfronthosting.co.za>


New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:

The next/previous links in the documentation skip some sections. This happens both in HTML format and the CHM Windows help file.

e.g.: in the Library Reference, section "8.5 StringIO" [next] points to "8.7 textwrap", skipping section "8.6 cStringIO". And section "9.12 UserDict" [next] points to "9.15 Types", skipping sections 9.13 and 9.14 (UserList and UserString). Same with their reverse links: 9.15 [previous] points to 9.12.

It seems those links connect *files*, not *sections*, and such logic fails when a single file contains more than a section. From a user POV that's not the expected behavior: the next/previous links should navigate the complete document, regardless of its physical implementation (the actual .rst files).

(In that case this might be a Sphinx bug rather than a Python one)

----------
assignee: georg.brandl
components: Documentation
messages: 97239
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: next/previous links in documentation skip some sections
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  5 01:34:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Jan 2010 00:34:07 +0000
Subject: [New-bugs-announce] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>


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

The short doc for 19.6. xml.dom.pulldom has lots of ...s that appear to indicate missing text. If so, this issue is a flag for a future project for someone who knows what to fill in.

If nothing is missing and the section is intended to be understood in its cryptic state, it should say so.

----------
assignee: georg.brandl
components: Documentation
messages: 97240
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: 19.6 xml.dom.pulldom doc: stub?
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  5 03:19:00 2010
From: report at bugs.python.org (steven Michalske)
Date: Tue, 05 Jan 2010 02:19:00 +0000
Subject: [New-bugs-announce] [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

As a complement to the append action, an update action would update a set with new values.


"update"
update a set with this option?s argument

justification:
adding email addresses at the command line, makes it less code to have a unique list.

----------
messages: 97242
nosy: hardkrash
severity: normal
status: open
title: Add a set update action to optparse
type: feature request

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

From report at bugs.python.org  Tue Jan  5 03:43:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Jan 2010 02:43:54 +0000
Subject: [New-bugs-announce] [issue7637] Improve 19.5. xml.dom.minidom doc
In-Reply-To: <1262659434.4.0.874382323645.issue7637@psf.upfronthosting.co.za>
Message-ID: <1262659434.4.0.874382323645.issue7637@psf.upfronthosting.co.za>


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

1. "When you are finished with a DOM, you should clean it up. This is necessary because some versions of Python do not support garbage collection of objects that refer to each other in a cycle. Until this restriction is removed from all versions of Python, it is safest to write your code as if cycles would not be cleaned up."

This appears to refer to early 2.x CPython versions without the gc module. Such (cryptic) back references are not appropriate for 3.x docs. Even in 3.x, immediate unlink might be a good idea, especially for CPython (which would then clean up immediately). But none of these issues are specific to DOM objects. Suggested replacement for the above and the current next sentence ("The way to clean up a DOM is to call its unlink() method:")

"When you are finished with a DOM, you can call the unlink method to encourage early cleanup of unneeded objects:"

Anything more is redundant with the doc for the method.
'''
dom1.unlink()
dom2.unlink()
dom3.unlink()
'''
One example at most is quite sufficient.

2. '''Node.toxml([encoding]) 
Return the XML that the DOM represents as a string.

With no argument, the XML header does not specify an encoding, and the result is Unicode string if the default encoding cannot represent all characters in the document. Encoding this string in an encoding other than UTF-8 is likely incorrect, since UTF-8 is the default encoding of XML.

With an explicit encoding [1] argument, the result is a byte string in the specified encoding. It is recommended that this argument is always specified. To avoid UnicodeError exceptions in case of unrepresentable text data, the encoding argument should be specified as ?utf-8?.
'''
I find this API a bit confusing.

In 3.x, "Return ... a string." means str (unicode), but the rest implies that 'string' should be 'string or bytes'.

"default encoding": what is it? ascii, utf-8 as almost implied, something in sys module (if so, please specify).

A cleaner API would have been 1. always return str (unicode) or 2. always return bytes, with encoding='utf-i' default or 3. return str if no encoding given or bytes if one is given, with no default.

3. Revision of following antipattern example would be for 2.x also:
'''
def getText(nodelist):
    rc = ""
    for node in nodelist:
        if node.nodeType == node.TEXT_NODE:
            rc = rc + node.data
    return rc
'''
should be (not tested, but pretty straightforward)

def getText(nodelist):
    rc = []
    for node in nodelist:
        if node.nodeType == node.TEXT_NODE:
            rc.append(node.data)
    return ''.join(rc)

----------
assignee: georg.brandl
components: Documentation
messages: 97244
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Improve 19.5. xml.dom.minidom doc
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan  5 03:55:19 2010
From: report at bugs.python.org (David)
Date: Tue, 05 Jan 2010 02:55:19 +0000
Subject: [New-bugs-announce] [issue7638] Counterintuitive str.splitlines()
	inconsistency.
In-Reply-To: <1262660119.0.0.105485577843.issue7638@psf.upfronthosting.co.za>
Message-ID: <1262660119.0.0.105485577843.issue7638@psf.upfronthosting.co.za>


New submission from David <vencabot_teppoo at hotmail.com>:

Qualifier: This is the first issue that I've raised, so I apologise before-hand for any protocol flubs.

str.splitlines()'s implementation jives unexpectedly with str.split().

In this code snippet, a server buffers input until it receives a blank line, and then it processes the input:

request_buffer = ""

while request_buffer.split("\n")[-1] != "" or request_buffer == "":
    request_buffer += self.conn.recv(1024)
    print("Got a line!")

print("Got an empty line!")
self.handleRequest(request_buffer)


I found out the hard way that this code isn't prepared to handle clients that use a different "new line" standard, such as those that send "\r". I discovered str.splitlines() at that point and found that, to some extent, it works as advertised: splitting lines regardless of exactly what new line character is being used.

However, this code doesn't work:

request_buffer = ""

while request_buffer.splitlines[-1] != "" or request_buffer == "":
    request_buffer += self.conn.recv(1024)
    print("Got a line!")

print("Got an empty line!")
self.handleRequest(request_buffer)


Python complains that -1 is out of request_buffer.splitlines()'s range. I know that str.splitlines() treats empty lines, because I've used it on longer strings for testing trailing blank lines before; it only refuses to count a line as being blank if there isn't another line after it. "derp".splitlines() has a length of 1, but "".splitlines() has a length of 0. "derp\n".splitlines() also has a length of 1, thus excluding the trailing blank line.

In my opinion, "".splitlines() should have 1 element. "derp".splitlines() should persist as having 1 element, but "derp\n".splitlines() should have 2 elements. This would result in the same functionality as str.split("\n") (where "\n".split("\n") results in two empty-string elements), but it would have the benefit of working predictably with all line-breaking standards, which I assume was the idea all along.

----------
messages: 97245
nosy: vencabot_teppoo
severity: normal
status: open
title: Counterintuitive str.splitlines() inconsistency.
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan  5 20:03:27 2010
From: report at bugs.python.org (Mikhail Terekhov)
Date: Tue, 05 Jan 2010 19:03:27 +0000
Subject: [New-bugs-announce] [issue7639] bdist_msi fails on files with long
	names
In-Reply-To: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>
Message-ID: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>


New submission from Mikhail Terekhov <termim at gmail.com>:

When I try to build msi installer for my module that contains files with long names it crashes with the following traceback

C:\home\python\dist_msi_bug>python setup.py bdist_msi
running bdist_msi
running build
running build_scripts
installing to build\bdist.win32\msi
running install_scripts
running install_data
running install_egg_info
Removing build\bdist.win32\msi\Lib\site-packages\hello-0.1-py2.6.egg-info
Writing build\bdist.win32\msi\Lib\site-packages\hello-0.1-py2.6.egg-info
Traceback (most recent call last):
  File "setup.py", line 8, in <module>
    data_files = [(".", ["data.seq.one.dat", "data.seq.two.dat"])],
  File "c:\python26\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "c:\python26\lib\distutils\dist.py", line 975, in run_commands
    self.run_command(cmd)
  File "c:\python26\lib\distutils\dist.py", line 995, in run_command
    cmd_obj.run()
  File "c:\python26\lib\distutils\command\bdist_msi.py", line 242, in run
    self.add_files()
  File "c:\python26\lib\distutils\command\bdist_msi.py", line 270, in add_files
    key = dir.add_file(file)
  File "c:\python26\lib\msilib\__init__.py", line 340, in add_file
    short = self.make_short(file)
  File "c:\python26\lib\msilib\__init__.py", line 299, in make_short
    assert file not in self.short_names
AssertionError


It seems that Directory.make_short fails to create unique short names in some cases. The test files are attached.

----------
components: Windows
files: dist_msi_bug.zip
messages: 97271
nosy: mmm77
severity: normal
status: open
title: bdist_msi fails on files with long names
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15747/dist_msi_bug.zip

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

From report at bugs.python.org  Tue Jan  5 20:38:10 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 05 Jan 2010 19:38:10 +0000
Subject: [New-bugs-announce] [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>


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

I've noticed a severe bug in my python 2.6.2 io module, and looking at _buffered_raw_seek in http://svn.python.org/view/python/trunk/Modules/_io/bufferedio.c?view=markup, it seems the bug is still there in the C reimplementation of buffered io classes.

The problem is, if we seek a buffered stream with whence=os.SEEK_CUR, that call is directly transmitted to the underlying raw stream, which has not the same file pointer position as the buffered stream. So in the end, the file pointer doesn't get moved at the right absolute offset, but at an offset which depends of the state of the read head buffer or the write buffer.
When using os.SEEK_CUR, it would be necessary to call tell() or to manually compute offsets, so that the seek() works as expected.

Regards, 
Pascal

----------
components: IO
messages: 97275
nosy: pakal
severity: normal
status: open
title: buffered io seek() buggy
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/issue7640>
_______________________________________

From report at bugs.python.org  Wed Jan  6 01:32:42 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Rekucki?=)
Date: Wed, 06 Jan 2010 00:32:42 +0000
Subject: [New-bugs-announce] [issue7641] Built-in Formatter accepts
	undocumented presentation type
In-Reply-To: <1262737962.32.0.137160455092.issue7641@psf.upfronthosting.co.za>
Message-ID: <1262737962.32.0.137160455092.issue7641@psf.upfronthosting.co.za>


New submission from ?ukasz Rekucki <lrekucki at gmail.com>:

The documentation states: "Most built-in types implement the following options for format specifications, although some of the formatting options are only supported by the numeric types."

The list doesn't include "s" presentation type, which is actually accepted for most built-in types *except* numeric ones. So you can write:
>>> "{:s}".format([])"
'[]'

But with numeric types you have to explicitly convert:
>>> "{!s:s}".format(5)
'5'
>>> "{:s}".format(5) # fails

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 97284
nosy: georg.brandl, lrekucki
severity: normal
status: open
title: Built-in Formatter accepts undocumented presentation type
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jan  6 03:46:31 2010
From: report at bugs.python.org (=?utf-8?b?VmFsZW50w61u?=)
Date: Wed, 06 Jan 2010 02:46:31 +0000
Subject: [New-bugs-announce] [issue7642] [patch] Minor improvement in
	os.system doc
In-Reply-To: <1262745991.38.0.384719539781.issue7642@psf.upfronthosting.co.za>
Message-ID: <1262745991.38.0.384719539781.issue7642@psf.upfronthosting.co.za>


New submission from Valent?n <valentin.depablo at gmail.com>:

Just added (maybe could be redundant but provides more info) that os.system is behaving in the samme manner in Vista and Windows 7.

Also providing the info that os.system always gives the output in python command line (not to be used to retrieve output from a command, there are better libraries already informed to users at the documentation of os.system).

No big deal... just a small help.

----------
assignee: georg.brandl
components: Documentation
files: osdoc.patch
keywords: patch
messages: 97294
nosy: Val, georg.brandl
severity: normal
status: open
title: [patch] Minor improvement in os.system doc
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15755/osdoc.patch

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

From report at bugs.python.org  Wed Jan  6 09:46:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 06 Jan 2010 08:46:46 +0000
Subject: [New-bugs-announce] [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Bytes objects and Unicode objects do not agree on ASCII linebreaks.

## Python 2

for s in '\x0a\x0d\x1c\x1d\x1e':
  print u'a{}b'.format(s).splitlines(1), 'a{}b'.format(s).splitlines(1)

# [u'a\n', u'b'] ['a\n', 'b']
# [u'a\r', u'b'] ['a\r', 'b']
# [u'a\x1c', u'b'] ['a\x1cb']
# [u'a\x1d', u'b'] ['a\x1db']
# [u'a\x1e', u'b'] ['a\x1eb']


## Python 3

for s in '\x0a\x0d\x1c\x1d\x1e':
  print('a{}b'.format(s).splitlines(1),
        bytes('a{}b'.format(s), 'utf-8').splitlines(1))

['a\n', 'b'] [b'a\n', b'b']
['a\r', 'b'] [b'a\r', b'b']
['a\x1c', 'b'] [b'a\x1cb']
['a\x1d', 'b'] [b'a\x1db']
['a\x1e', 'b'] [b'a\x1eb']

----------
components: Interpreter Core
messages: 97299
nosy: flox
severity: normal
status: open
title: What is an ASCII linebreak?
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jan  6 11:29:14 2010
From: report at bugs.python.org (Michael Mullins)
Date: Wed, 06 Jan 2010 10:29:14 +0000
Subject: [New-bugs-announce] [issue7644] bug in nntplib.body() method with
	possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>


New submission from Michael Mullins <pabloonbreak at gmail.com>:

When using NNTP.body(id,file) I get the following repeatable error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "nntplib.py", line 436, in body
    return self.artcmd('BODY {0}'.format(id), file)
  File "nntplib.py", line 410, in artcmd
    resp, list = self.longcmd(line, file)
  File "nntplib.py", line 267, in longcmd
    return self.getlongresp(file)
  File "nntplib.py", line 249, in getlongresp
    file.write(line + b'\n')
  File "/usr/lib/python3.0/io.py", line 1478, in write
    s.__class__.__name__)
TypeError: can't write bytes to text stream


But by simply changing the line

    openedFile = file = open(file, "w")

...to...

    openedFile = file = open(file, "wb")

...in the following code:

    def getlongresp(self, file=None):
        """Internal: get a response plus following text from the server.
        Raise various errors if the response indicates an error."""

        openedFile = None
        try:
            # If a string was passed then open a file with that name
            if isinstance(file, str):
                openedFile = file = open(file, "wb")

...it seems to fix the problem. I discovered this in 3.0, but downloading and inspecting the source for 3.1 shows the same problem.

MDMullins

----------
messages: 97301
nosy: mdmullins
severity: normal
status: open
title: bug in nntplib.body() method with possible fix
versions: Python 3.1

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

From report at bugs.python.org  Wed Jan  6 20:56:21 2010
From: report at bugs.python.org (Austin English)
Date: Wed, 06 Jan 2010 19:56:21 +0000
Subject: [New-bugs-announce] [issue7645] test_distutils fails on Windows XP
In-Reply-To: <1262807781.76.0.367553383725.issue7645@psf.upfronthosting.co.za>
Message-ID: <1262807781.76.0.367553383725.issue7645@psf.upfronthosting.co.za>


New submission from Austin English <austinenglish+python at gmail.com>:

IOError: [Errno 2] No such file or directory: 'C:\\Python31\\lib\\distutils\\tests\\Setup.sample'

Full output is attached.

----------
components: Windows
files: distutils.txt
messages: 97318
nosy: austin987
severity: normal
status: open
title: test_distutils fails on Windows XP
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15761/distutils.txt

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

From report at bugs.python.org  Wed Jan  6 20:59:05 2010
From: report at bugs.python.org (Austin English)
Date: Wed, 06 Jan 2010 19:59:05 +0000
Subject: [New-bugs-announce] [issue7646] test_telnetlib fails in Windows XP
In-Reply-To: <1262807945.09.0.76029719332.issue7646@psf.upfronthosting.co.za>
Message-ID: <1262807945.09.0.76029719332.issue7646@psf.upfronthosting.co.za>


New submission from Austin English <austinenglish+python at gmail.com>:

socket.error: [Errno 10053] An established connection was aborted by the software in your host machine

Full output is attached.

----------
components: Windows
files: telnetlib.txt
messages: 97319
nosy: austin987
severity: normal
status: open
title: test_telnetlib fails in Windows XP
versions: Python 3.1
Added file: http://bugs.python.org/file15762/telnetlib.txt

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

From report at bugs.python.org  Wed Jan  6 21:18:41 2010
From: report at bugs.python.org (Adam Jackson)
Date: Wed, 06 Jan 2010 20:18:41 +0000
Subject: [New-bugs-announce] [issue7647] Add statvfs flags to the posix
	module
In-Reply-To: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>
Message-ID: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>


New submission from Adam Jackson <ajax at redhat.com>:

Though the statvfs call exists in the posix module, the posix-defined values for the f_flag field are not.  This makes it hard to know whether a filesystem is readonly without also knowing the value for ST_READONLY on the machine you're running on.

Attached patch is against python2 svn, but probably applies to python3 too.

----------
components: Extension Modules
files: posix-statvfs-symbols.patch
keywords: patch
messages: 97322
nosy: ajax at redhat.com
severity: normal
status: open
title: Add statvfs flags to the posix module
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15764/posix-statvfs-symbols.patch

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

From report at bugs.python.org  Thu Jan  7 00:11:19 2010
From: report at bugs.python.org (Austin English)
Date: Wed, 06 Jan 2010 23:11:19 +0000
Subject: [New-bugs-announce] [issue7648] test_urllib2 fails on Windows if
	not run from C:
In-Reply-To: <1262819479.55.0.149764939883.issue7648@psf.upfronthosting.co.za>
Message-ID: <1262819479.55.0.149764939883.issue7648@psf.upfronthosting.co.za>


New submission from Austin English <austinenglish+python at gmail.com>:

Passes fine if run from C:, but when run from any other drive, fails:

test_trivial (__main__.TrivialTests) ... ERROR

======================================================================
ERROR: test_trivial (__main__.TrivialTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\Python31\lib\urllib\request.py", line 1189, in open_local_file
    stats = os.stat(localfile)
WindowsError: [Error 3] The system cannot find the path specified: '\\Python31\\
lib\\urllib\\request.py'

----------
components: Windows
files: url.txt
messages: 97332
nosy: austin987
severity: normal
status: open
title: test_urllib2 fails on Windows if not run from C:
versions: Python 3.1
Added file: http://bugs.python.org/file15767/url.txt

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

From report at bugs.python.org  Thu Jan  7 02:08:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 01:08:00 +0000
Subject: [New-bugs-announce] [issue7649] "u'%c' % char" broken for chars in
	range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

On Py2.x u'%c' % char returns the wrong result if char is in range '\x80'-'\xFF':
>>> u'%c' % '\x7f'
u'\x7f'  # correct
>>> u'%c' % '\x80'
u'\uff80'  # broken
>>> u'%c' % '\xFF'
u'\uffff'  # broken

This is what happens whit %s and 0x80:
>>> u'%s' % '\x80'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal
not in range(128)
>>> u'%c' % 0x80
u'\x80'

u'%c' % '\x80' should raise the same error raised by u'%s' % '\x80'.

----------
assignee: ezio.melotti
components: Interpreter Core, Unicode
messages: 97334
nosy: ezio.melotti
priority: high
severity: normal
stage: test needed
status: open
title: "u'%c' % char" broken for chars in range '\x80'-'\xFF'
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Jan  7 02:49:55 2010
From: report at bugs.python.org (Austin English)
Date: Thu, 07 Jan 2010 01:49:55 +0000
Subject: [New-bugs-announce] [issue7650] test_uuid is invalid
In-Reply-To: <1262828995.4.0.365764114727.issue7650@psf.upfronthosting.co.za>
Message-ID: <1262828995.4.0.365764114727.issue7650@psf.upfronthosting.co.za>


New submission from Austin English <austinenglish+python at gmail.com>:

>From http://bugs.winehq.org/show_bug.cgi?id=21276

"I believe this is a bug in the python test code, not in Wine.  Wine's
UuidCreate function follows RFC 4122, section 4.4.  That is, it generates a Uuid from a pseudorandom number generator, not from a MAC address.  Thus, the error message from the test program is correct:  it doesn't appear to be a MAC address.  On the other hand, it's not an error:  this is expected.

The python code should be checking the version field of the generated Uuid first.  If it's 1, then the generated Uuid *may* be expected to contain a MAC address.  From RFC 4122, section 4.1.6:

  For UUID version 1, the node field consists of an IEEE 802 MAC
  address, usually the host address.  For systems with multiple IEEE
  802 addresses, any available one can be used.  The lowest addressed
  octet (octet number 10) contains the global/local bit and the
  unicast/multicast bit, and is the first octet of the address
  transmitted on an 802.3 LAN.

However, the test for the most significant bit not being set is also invalid on systems with no MAC address.  From the python code:
       self.assertTrue(node < (1 << 48), message)
The most significant bit of a MAC address is set when the MAC address is a multicast address.  For systems with no MAC address, a multicast address is supposed to be used.  Also from RFC 4122, section 4.1.6:

  For systems with no IEEE address, a randomly or pseudo-randomly
  generated value may be used; see Section 4.5.  The multicast bit must
  be set in such addresses, in order that they will never conflict with
  addresses obtained from network cards.

This analysis may of use to the Python folks, but it certainly isn't a Wine bug."

----------
components: Tests
messages: 97337
nosy: austin987
severity: normal
status: open
title: test_uuid is invalid
versions: Python 3.1

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

From report at bugs.python.org  Thu Jan  7 04:03:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jan 2010 03:03:57 +0000
Subject: [New-bugs-announce] [issue7651] Python3: guess text file charset
	using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>


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

If the file starts with a BOM, open(filename) should be able to guess the charset. It would be helpful for many high level modules:

 - #7519: ConfigParser
 - #7185: csv
 - and any module using open() to read a text file

Actually, the user have to choose between UTF-8 and UTF-8-SIG to skip the UTF-8 BOM. For UTF-16, the user have to specify UTF-16-LE or UTF-16-BE, even if the file starts with a BOM (which should be the case most the time).

The idea is to delay the creation of the decoder and the encoder. Just after reading the first chunk: try to guess the charset by searching for a BOM (if the charset is unknown). If the BOM is found, fallback to current guess code (os.device_charset() or locale.getpreferredencoding()).

Concerned charsets: UTF-8, UTF-16-LE, UTF-16-BE, UTF-32-LE, UTF-32-BE. Binary files are not concerned. If the encoding is specified to open(), the behaviour is unchanged.

I wrote a proof of concept, but there are still open issues:

 - append mode: should we seek at zero to read the BOM?
   old=tell(); seek(0); bytes=read(4); seek(old); search_bom(bytes)
 - read+write: should we guess the charset using the BOM if the first action is a write? or only search for a BOM if the first action is a read?

----------
components: Unicode
messages: 97341
nosy: haypo
severity: normal
status: open
title: Python3: guess text file charset using the BOM
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jan  7 11:42:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Jan 2010 10:42:52 +0000
Subject: [New-bugs-announce] [issue7652] Merge C version of decimal into
	py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>


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

I've created this issue to keep track of progress in merging Stefan Krah's work on decimal in c into py3k.

We've created a branch py3k-cdecimal (with merge tracking from py3k) for this work.  When the branch is fully working and tested we'll consult python-dev about next steps.

----------
components: Extension Modules, Library (Lib)
messages: 97347
nosy: mark.dickinson, rhettinger, skrah
severity: normal
status: open
title: Merge C version of decimal into py3k.
type: performance
versions: Python 3.2

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

From report at bugs.python.org  Thu Jan  7 21:40:29 2010
From: report at bugs.python.org (Paul Keating)
Date: Thu, 07 Jan 2010 20:40:29 +0000
Subject: [New-bugs-announce] [issue7653] Fix description of the way the
	PythonPath Windows	registry key works
In-Reply-To: <1262896829.94.0.236098759171.issue7653@psf.upfronthosting.co.za>
Message-ID: <1262896829.94.0.236098759171.issue7653@psf.upfronthosting.co.za>


New submission from Paul Keating <keating at acm.org>:

The 2.6.4 docs (at http://docs.python.org/using/windows.html) do not give enough detail for an ordinary user to work out how the registry key HKLM\SOFTWARE\Python\PythonCore\version\PythonPath actually works.

It says:

Modifying the module search path can also be done through the Windows registry: Edit HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\version\PythonPath.

It should say:

Modifying the module search path can also be done through the Windows registry. To add a folder to the module search path, create a subkey under HKLM\SOFTWARE\Python\PythonCore\version\PythonPath. The subkey name is not important (but might, say, identify the package being added to the search path). Put the name of the folder you want searched in the default string value of the key you have created. Specify multiple folders as a semicolon-delimited list. If you create more than one subkey, all will be used, in alphabetical order of subkey name. If a folder appears in more than one subkey then it will appear only once in sys.path, in the position corresponding to the first mention.

Do not amend the list of folders given in the default value at the PythonPath key level. Installers create this value but it is a holdover from earlier versions of Python and amending it has no effect.

----------
assignee: georg.brandl
components: Documentation
messages: 97371
nosy: BoarGules, georg.brandl
severity: normal
status: open
title: Fix description of the way the PythonPath Windows registry key works
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan  7 22:47:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 21:47:36 +0000
Subject: [New-bugs-announce] [issue7654] [patch] Enable additional bytes and
	memoryview tests.
In-Reply-To: <1262900856.17.0.385951173483.issue7654@psf.upfronthosting.co.za>
Message-ID: <1262900856.17.0.385951173483.issue7654@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Some tests in test_bytes are XXX.
They could be enabled.

Additionally the BaseBytesTest.test_index() is duplicated.

This patch enable the additional tests and remove dead code.

----------
components: Tests
files: enable_bytes_memoryview_tests.diff
keywords: patch
messages: 97380
nosy: flox
severity: normal
status: open
title: [patch] Enable additional bytes and memoryview tests.
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15780/enable_bytes_memoryview_tests.diff

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

From report at bugs.python.org  Thu Jan  7 23:29:31 2010
From: report at bugs.python.org (Bernard A. Badger)
Date: Thu, 07 Jan 2010 22:29:31 +0000
Subject: [New-bugs-announce] [issue7655] PEP 374 Title usage & script
	redirection typo fixes
In-Reply-To: <1262903371.51.0.129729572973.issue7655@psf.upfronthosting.co.za>
Message-ID: <1262903371.51.0.129729572973.issue7655@psf.upfronthosting.co.za>


New submission from Bernard A. Badger <badgerb at brevardcc.edu>:

Change obvious usage error /chosing/choosing/
 and script redirection  /./>/ typos.

----------
assignee: georg.brandl
components: Documentation
files: pep-0374.txt.patch
keywords: patch
messages: 97383
nosy: bab9e9, georg.brandl
severity: normal
status: open
title: PEP 374 Title usage & script redirection typo fixes
Added file: http://bugs.python.org/file15781/pep-0374.txt.patch

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

From report at bugs.python.org  Fri Jan  8 02:28:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jan 2010 01:28:33 +0000
Subject: [New-bugs-announce] [issue7656] test_hashlib fails on some
	installations (specifically	Neal's regression test runner)
In-Reply-To: <1262914113.09.0.614913015599.issue7656@psf.upfronthosting.co.za>
Message-ID: <1262914113.09.0.614913015599.issue7656@psf.upfronthosting.co.za>


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

The patch in issue3745 to build and run all hash tests in a debug build seems to have caused test_hashlib to start failing when run by the build.sh regression test runner.  See the recent emails on python-checkins, where I used -W to get a verbose listing of the failing tests.

----------
assignee: gregory.p.smith
components: Tests
messages: 97391
nosy: gregory.p.smith, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_hashlib fails on some installations (specifically Neal's regression test runner)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  8 08:02:33 2010
From: report at bugs.python.org (sangamesh)
Date: Fri, 08 Jan 2010 07:02:33 +0000
Subject: [New-bugs-announce] [issue7657] test_ctypes failure on AIX 5.3
In-Reply-To: <1262934153.84.0.332661974456.issue7657@psf.upfronthosting.co.za>
Message-ID: <1262934153.84.0.332661974456.issue7657@psf.upfronthosting.co.za>


New submission from sangamesh <swamy.sangamesh at gmail.com>:

I built the python-2.6.2 with the latest libffi-3.0.9 in AIX 5.3 using xlc compiler.
When i try to run the ctypes test cases, two failures are seen in test_bitfields.

test_ints (ctypes.test.test_bitfields.C_Test) ... FAIL
test_shorts (ctypes.test.test_bitfields.C_Test) ... FAIL

It seems that interpreting type c_int and c_short is wrong in bit field for AIX. If i change the type c_int and c_short 
to c_unit and c_ushort of class "BITS(Structure)" in file test_bitfields.py then no failures are seen and all the test 
cases got passed

This issue is common for both 32 and 64-bit versions

Attaching the complete test case result for reference.

----------
assignee: theller
components: ctypes
files: ctype-tests.txt
messages: 97395
nosy: mallayya, theller
severity: normal
status: open
title: test_ctypes failure on AIX 5.3
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15784/ctype-tests.txt

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

From report at bugs.python.org  Fri Jan  8 10:06:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Jan 2010 09:06:06 +0000
Subject: [New-bugs-announce] [issue7658] OS X pythonw.c compile error with
	10.4 or earlier	deployment target
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>


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

r77031 (trunk) and r77032 (py3k) for Issue6834 enhanced the
the OS X python interpreter launcher, python/pythonw, to
allow user-selection of the interpreter execution architecture
for multiple architecture builds, i.e. 32-bit vs 64-bit, by
using the enhanced capability of the posix_spawn system call
instead of execv.  However, posix_spawn does not exist prior
to OS X 10.5 and it is still important for the OS X installer
to support builds and execution on 10.4 and earlier systems.

The solution here is to modify Mac/Tools/pythonw.c to
conditionally compile calls to execv for builds with a
deployment target of 10.4 or earlier and use posix_spawn
for deployments of 10.5 or above.

Also, correct 32-bit arch names added in configure/configure.in:
for 10.4, they must be the more general "ppc", not "ppc7400".

APPLIES     py3k, trunk

----------
assignee: ronaldoussoren
components: Macintosh
files: issue-pythonw-10-4-py3k-trunk.txt
messages: 97397
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X pythonw.c compile error with 10.4 or earlier deployment target
type: compile error
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15785/issue-pythonw-10-4-py3k-trunk.txt

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

From report at bugs.python.org  Fri Jan  8 17:32:12 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 08 Jan 2010 16:32:12 +0000
Subject: [New-bugs-announce] [issue7659] Problems with attribute assignment
	on object instances
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>


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

It seems we can't assign attributes to "objet" class instances, which don't have a __dict__ :

IDLE 2.6.4      
>>> a = object()
>>> a.abc = 3

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    a.abc = 3
AttributeError: 'object' object has no attribute 'abc'
>>> 

This behaviour seems undocumented, and contradicts the documentation on AttributeError -> normally, a TypeError should be raised instead:

exception AttributeError
    Raised when an attribute reference (see Attribute references) or assignment fails. (When an object does not support attribute references or attribute assignments at all, TypeError is raised.)

----------
components: Interpreter Core
messages: 97416
nosy: pakal
severity: normal
status: open
title: Problems with attribute assignment on object instances
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan  8 20:09:20 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 08 Jan 2010 19:09:20 +0000
Subject: [New-bugs-announce] [issue7660] Two float('nan') are not equal
In-Reply-To: <1262977760.25.0.00378314751244.issue7660@psf.upfronthosting.co.za>
Message-ID: <1262977760.25.0.00378314751244.issue7660@psf.upfronthosting.co.za>


New submission from Jean-Michel Fauth <wxjmfauth at gmail.com>:

I did not find any report about this.

Windows 7, Python 2.6.4

>>> float('inf') == float('inf')
True
>>> float('-inf') == float('-inf')
True
>>> float('-inf') == float('inf')
False
>>> float('-inf') != float('inf')
True
>>> float('nan') == float('nan')
False
>>> float('nan') != float('nan')
True
>>> 

I'm not an expert on that field, I wonder if the following is
not related to a sign bit missmatch, see also Python 3.1.1 below.

>>> copysign(1, float('inf'))
1.0
>>> copysign(1, float('-inf'))
-1.0
>>> copysign(1, float('nan'))
-1.0
>>> copysign(1, float('-nan'))
-1.0
>>> 

Windows 7, Python 3.1.1

>>> float('inf') == float('inf')
True
>>> float('-inf') == float('-inf')
True
>>> float('-inf') == float('inf')
False
>>> float('-inf') != float('inf')
True
>>> float('nan') == float('nan')
False
>>> float('nan') != float('nan')
True
>>> 

Same behaviour as with Python 2.6.4

>>> copysign(1, float('inf'))
1.0
>>> copysign(1, float('-inf'))
-1.0
>>> copysign(1, float('nan'))
-1.0
>>> copysign(1, float('-nan'))  <<<<<<<<<<<<<<<<<<<
1.0
>>> 

Different behaviour from Python 2.6.4

----------
components: None
messages: 97432
nosy: jmfauth
severity: normal
status: open
title: Two float('nan') are not equal
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan  9 00:24:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 23:24:57 +0000
Subject: [New-bugs-announce] [issue7661] compiling ctypes fails with
	non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>


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

Traceback (most recent call last):
  File "./setup.py", line 1933, in <module>
    main()
  File "./setup.py", line 1928, in main
    'Lib/smtpd.py']
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/command/build.py", line 126, in run
    self.run_command(cmd_name)
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/command/build_ext.py", line 396, in run
    self.build_extensions()
  File "./setup.py", line 192, in build_extensions
    build_ext.build_extensions(self)
  File "/home/buildbot/cpython-ucs4-nonascii-???/trunk.pitrou-ubuntu-wide/build/Lib/distutils/command/build_ext.py", line 506, in build_extensions
    self.build_extension(ext)
  File "./setup.py", line 226, in build_extension
    if not self.configure_ctypes(ext):
  File "./setup.py", line 1735, in configure_ctypes
    execfile(ffi_configfile, globals(), fficonfig)
  File "build/temp.linux-x86_64-2.7-pydebug/libffi/fficonfig.py", line 31
SyntaxError: Non-ASCII character '\xe2' in file build/temp.linux-x86_64-2.7-pydebug/libffi/fficonfig.py on line 31, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
[54530 refs]


See e.g. http://www.python.org/dev/buildbot/builders/AMD64%20Ubuntu%20wide%20trunk/builds/238/steps/compile/logs/stdio

----------
assignee: theller
messages: 97444
nosy: pitrou, theller
priority: high
severity: normal
stage: needs patch
status: open
title: compiling ctypes fails with non-ascii path
type: compile error
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Jan  9 18:15:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 09 Jan 2010 17:15:41 +0000
Subject: [New-bugs-announce] [issue7662] time.utcoffset(dst=true)
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>


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

The proposal to add the function that will allow to get current UTC offset. Do we need a PEP for this one?

def time.utcoffset():
  """Return current UTC offset in seconds"""
  return -(time.altzone if time.daylight else time.timezone)

----------
components: Library (Lib)
messages: 97463
nosy: techtonik
severity: normal
status: open
title: time.utcoffset(dst=true)
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan 10 06:27:30 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 10 Jan 2010 05:27:30 +0000
Subject: [New-bugs-announce] [issue7663] UTF-16 build incorrectly translates
	cases for non-BMP	code points
In-Reply-To: <1263101250.07.0.175926881279.issue7663@psf.upfronthosting.co.za>
Message-ID: <1263101250.07.0.175926881279.issue7663@psf.upfronthosting.co.za>


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

This issue may extend beyond just unicode.upper() and unicode.lower(), but it's very clear with these two methods, at least.

For example, consider DESERET SMALL LETTER EW.  On a UTF-16 build, calling upper on a string containing this doesn't change it to the capital variation (DESERET CAPITAL LETTER EW):

>>> u'\N{DESERET SMALL LETTER EW}'.upper() == u'\N{DESERET SMALL LETTER EW}'
True

It can also be seen that this isn't even recognized as lower case:

>>> u'\N{DESERET SMALL LETTER EW}'.islower()
False

With a UTF-32 build, however, the expected behavior (ie, the behavior one would get for a code point in the BMP with small and capital variations) is provided.

----------
components: Interpreter Core
messages: 97500
nosy: exarkun
severity: normal
status: open
title: UTF-16 build incorrectly translates cases for non-BMP code points
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 10 11:58:31 2010
From: report at bugs.python.org (Yateen V. Joshi)
Date: Sun, 10 Jan 2010 10:58:31 +0000
Subject: [New-bugs-announce] [issue7664] python logger does not handle
	IOError Exception
In-Reply-To: <1263121111.41.0.440295567357.issue7664@psf.upfronthosting.co.za>
Message-ID: <1263121111.41.0.440295567357.issue7664@psf.upfronthosting.co.za>


New submission from Yateen V. Joshi <yjoshi at starentnetworks.com>:

I am running an in house application that uses multiprocessing logger. 
This application ftp's files from a remote host and keep them on a local
disk. Here is the scenario - 
While pulling the files, I make the local disk full (100%). The application hangs, it can not log further. Apart from other exceptions, following are prominent ones. If I further create cleanup the disk, the application does not proceed. It 
remains hung. I have to restart the application. 

  File "/export/home/yateen/ess/3rdparty/python/solaris/lib/python2.6/logging/__init__.py", line 1059, in error
    self._log(ERROR, msg, args, **kwargs)
  File "/export/home/yateen/ess/3rdparty/python/solaris/lib/python2.6/logging/__init__.py", line 1141, in _log
    self.handle(record)
  File "/export/home/yateen/ess/3rdparty/python/solaris/lib/python2.6/logging/__init__.py", line 1151, in handle
    self.callHandlers(record)
  File "/export/home/yateen/ess/3rdparty/python/solaris/lib/python2.6/logging/__init__.py", line 1188, in callHandlers
    hdlr.handle(record)
  File "/export/home/yateen/ess/3rdparty/python/solaris/lib/python2.6/logging/__init__.py", line 671, in handle
    self.release()
  File "build/bdist.solaris-2.10-sun4u/egg/cloghandler.py", line 189, in release
    self.stream.flush()


I tried looking into the logging module's code and could not find IOError exception handling there. After going through
various situations, and trial-errors (I am not a python Guru), I found following fix working - 
method handle(record), file logging/__init__.py, line#670
original code - 
        rv = self.filter(record)
        if rv:
            self.acquire()
            try:
                self.emit(record)
            finally:
                self.release()
                             
        return rv

Modified code - 
        rv = self.filter(record)
        if rv:
            self.acquire()
            try:
                self.emit(record)
            finally:
                try:
                  self.release()
                except (IOError, OSError):
                  pass
        return rv

What this tells is if there is an error in locks handling, simply leave it and proceed. With this fix, when the disk is 
cleaned up, application proceeds properly. 

What I want to know if this is an appropriate fix? Can I go ahead with it?

Thanks,
Yateen..

----------
components: Extension Modules
messages: 97504
nosy: yateenjoshi
severity: normal
status: open
title: python logger does not handle IOError Exception
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan 10 17:50:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 16:50:26 +0000
Subject: [New-bugs-announce] [issue7665] test_urllib2 fails if path contains
	"\"
In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za>
Message-ID: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

/tmp/py2u? ? un\icode $ ./python Lib/test/regrtest.py test_urllib2
test_urllib2
test test_urllib2 failed -- Traceback (most recent call last):
  File "/tmp/py2u? ? un\icode/Lib/test/test_urllib2.py", line 36, in test_trivial
    f = urllib2.urlopen(file_url)
  File "/tmp/py2u? ? un\icode/Lib/urllib2.py", line 126, in urlopen
    return _opener.open(url, data, timeout)
  File "/tmp/py2u? ? un\icode/Lib/urllib2.py", line 391, in open
    response = self._open(req, data)
  File "/tmp/py2u? ? un\icode/Lib/urllib2.py", line 409, in _open
    '_open', req)
  File "/tmp/py2u? ? un\icode/Lib/urllib2.py", line 369, in _call_chain
    result = func(*args)
  File "/tmp/py2u? ? un\icode/Lib/urllib2.py", line 1260, in file_open
    return self.open_local_file(req)
  File "/tmp/py2u? ? un\icode/Lib/urllib2.py", line 1297, in open_local_file
    raise URLError(msg)
URLError: <urlopen error [Errno 2] No such file or directory: '/tmp/py2u\xe2\x80\xa6 \xe2\x86\x92 un/icode/Lib/urllib2.pyc'>

1 test failed:
    test_urllib2

----------
components: Tests
messages: 97522
nosy: flox
severity: normal
status: open
title: test_urllib2 fails if path contains "\"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 10 18:36:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 17:36:10 +0000
Subject: [New-bugs-announce] [issue7666] test_lib2to3 fails if path contains
	space
In-Reply-To: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>
Message-ID: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

test_lib2to3
diff: op?rande suppl?mentaire ? unicode/Lib/lib2to3/pytree.py ?
diff: Pour en savoir davantage, faites: ? diff --help ?.
test test_lib2to3 failed -- Traceback (most recent call last):
  File "/tmp/py2u? ? un\icode/Lib/lib2to3/tests/test_parser.py", line 164, in test_all_project_files
    self.fail("Idempotency failed: %s" % filepath)
AssertionError: Idempotency failed: /tmp/py2u? ? un\icode/Lib/lib2to3/pytree.py


Patch attached.

----------
components: Tests
files: lib2to3_path_with_space.py
messages: 97525
nosy: flox
severity: normal
stage: patch review
status: open
title: test_lib2to3 fails if path contains space
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15818/lib2to3_path_with_space.py

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

From report at bugs.python.org  Sun Jan 10 19:11:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 18:11:53 +0000
Subject: [New-bugs-announce] [issue7667] test_doctest fails with non-ascii
	path
In-Reply-To: <1263147113.71.0.132140640007.issue7667@psf.upfronthosting.co.za>
Message-ID: <1263147113.71.0.132140640007.issue7667@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

/tmp/py2u??unicode $ ./python Lib/test/regrtest.py test_doctest
test_doctest
**********************************************************************
File "/tmp/py2u??unicode/Lib/test/test_doctest.py", line 2052, in test.test_doctest.test_DocFileSuite
Failed example:
    suite.run(unittest.TestResult())
Expected:
    <unittest.result.TestResult run=3 errors=0 failures=2>
Got:
    <unittest.result.TestResult run=3 errors=2 failures=0>
**********************************************************************
1 items had failures:
   1 of  40 in test.test_doctest.test_DocFileSuite
***Test Failed*** 1 failures.
test test_doctest failed -- 1 of 421 doctests failed

1 test failed:
    test_doctest

----------
components: Tests
messages: 97533
nosy: flox
severity: normal
status: open
title: test_doctest fails with non-ascii path
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 10 19:15:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 18:15:24 +0000
Subject: [New-bugs-announce] [issue7668] test_httpservers fails with
	non-ascii path
In-Reply-To: <1263147324.56.0.696076411083.issue7668@psf.upfronthosting.co.za>
Message-ID: <1263147324.56.0.696076411083.issue7668@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

/tmp/py2u??unicode $ ./python Lib/test/regrtest.py test_httpservers
test_httpservers
  File "/tmp/tmplX9agF/cgi-bin/file1.py", line 1
SyntaxError: Non-ASCII character '\xe2' in file /tmp/tmplX9agF/cgi-bin/file1.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
[17270 refs]
  File "/tmp/tmpVDMVU4/cgi-bin/file1.py", line 1
SyntaxError: Non-ASCII character '\xe2' in file /tmp/tmpVDMVU4/cgi-bin/file1.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
[17270 refs]
  File "/tmp/tmpAh6jTS/cgi-bin/file1.py", line 1
SyntaxError: Non-ASCII character '\xe2' in file /tmp/tmpAh6jTS/cgi-bin/file1.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
[17270 refs]
  File "/tmp/tmpLPF9CV/cgi-bin/file2.py", line 1
SyntaxError: Non-ASCII character '\xe2' in file /tmp/tmpLPF9CV/cgi-bin/file2.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
[17270 refs]
test test_httpservers failed -- multiple errors occurred; run in verbose mode for details

1 test failed:
    test_httpservers

----------
components: Tests
messages: 97536
nosy: flox
severity: normal
status: open
title: test_httpservers fails with non-ascii path
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 10 19:18:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 18:18:27 +0000
Subject: [New-bugs-announce] [issue7669] test_unicode_file fails with
	non-ascii path
In-Reply-To: <1263147507.26.0.603744082511.issue7669@psf.upfronthosting.co.za>
Message-ID: <1263147507.26.0.603744082511.issue7669@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

/tmp/py2u??unicode $ ./python Lib/test/regrtest.py test_unicode_file
test_unicode_file
test test_unicode_file failed -- Traceback (most recent call last):
  File "/tmp/py2u??unicode/Lib/test/test_unicode_file.py", line 173, in test_single_files
    self._test_single(TESTFN_UNICODE)
  File "/tmp/py2u??unicode/Lib/test/test_unicode_file.py", line 147, in _test_single
    self._do_single(filename)
  File "/tmp/py2u??unicode/Lib/test/test_unicode_file.py", line 48, in _do_single
    self.assertTrue(os.path.exists(os.path.abspath(filename)))
  File "/tmp/py2u??unicode/Lib/posixpath.py", line 338, in abspath
    path = join(os.getcwd(), path)
  File "/tmp/py2u??unicode/Lib/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 29: ordinal not in range(128)

1 test failed:
    test_unicode_file

----------
components: Tests
messages: 97537
nosy: flox
severity: normal
status: open
title: test_unicode_file fails with non-ascii path
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 10 19:42:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 18:42:14 +0000
Subject: [New-bugs-announce] [issue7670] _sqlite3: Block *all* operations on
	a closed Connection	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>


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

Add call to pysqlite_check_connection() on the follow methods:

 * create_function()
 * create_aggregate()
 * set_authorizer()
 * set_progress_handler()
 * __call__()

Eg. fix the following segfault:

   c = Connection("test")
   c.close()
   c.set_authorizer(func)

The patch includes unit tests to test all methods on a closed connection.

sqlite3 already raises an error for some operations on a closed socket (eg. connection.commit()), but not on all operations.

----------
components: Extension Modules
files: sqlite_closed.patch
keywords: patch
messages: 97538
nosy: haypo
severity: normal
status: open
title: _sqlite3: Block *all* operations on a closed Connection object
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15819/sqlite_closed.patch

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

From report at bugs.python.org  Sun Jan 10 20:07:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 19:07:16 +0000
Subject: [New-bugs-announce] [issue7671] test_popen fails if path contains
	semi-colon "; "
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

/tmp/semi;colon $ ./python -3 Lib/test/regrtest.py test_popen
test_popen
sh: /tmp/semi: Aucun fichier ou r?pertoire de ce type
sh: colon/python: Aucun fichier ou r?pertoire de ce type
test test_popen failed -- Traceback (most recent call last):
  File "/tmp/semi;colon/Lib/test/test_popen.py", line 31, in test_popen
    ["foo", "bar"]
  File "/tmp/semi;colon/Lib/test/test_popen.py", line 24, in _do_test_commandline
    got = eval(data)[1:] # strip off argv[0]
  File "<string>", line 0
    
   ^
SyntaxError: unexpected EOF while parsing

1 test failed:
    test_popen

----------
components: Tests
messages: 97543
nosy: flox
severity: normal
status: open
title: test_popen fails if path contains semi-colon ";"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 10 21:52:03 2010
From: report at bugs.python.org (Sean Soria)
Date: Sun, 10 Jan 2010 20:52:03 +0000
Subject: [New-bugs-announce] [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>


New submission from Sean Soria <bugs.python at seansoria.com>:

I seem to have a rather unique setup that causes this crash to be 100% reproducible. My application embeds python in order to execute user code. It is constantly loading and unloading the libraries so that they're only in memory during execution of user code. The problem I'm seeing is with the calls to CRYPTO_set_locking_callback and CRYPTO_set_id_callback in _setup_ssl_threads in _ssl.c. These calls will override whatever callbacks my application has already set up, and then when we unload python, callbacks are never restored. When my application later makes an SSL call that requires use of locking_callback or id_callback, it will attempt to call one of the functions in _ssl.so address space. Since nothing is there, this causes the program to crash. Worse yet would be if something were loaded into the same address space and arbitrary code were executed (though I don't see how malicious code could be executed in this way).

I haven't confirmed with other version of Python, but this was discovered while upgrading the embedded version from 2.4.5 to 2.6.4, so it's very likely to exist in many other version since the code was put in place in 2007.

----------
components: Extension Modules
messages: 97551
nosy: janssen, ssoria
severity: normal
status: open
title: _ssl module causes segfault
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 11 02:05:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Jan 2010 01:05:57 +0000
Subject: [New-bugs-announce] [issue7673] audioop: check that length is a
	multiple of the size
In-Reply-To: <1263171957.43.0.71285781195.issue7673@psf.upfronthosting.co.za>
Message-ID: <1263171957.43.0.71285781195.issue7673@psf.upfronthosting.co.za>


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

Most functions of audioop takes as input a byte string (audio data) and a size argument (number of bytes of a sample). Functions don't check that the byte string length is a multiple of the size. It leads to read and write from/to uninitialised memory and might crash.

Example on writing into uninitilized memory:

    $ python -c "import audioop; audioop.reverse('X', 2)"
    Fatal Python error: Inconsistent interned string state.
    Abandon

It allocates a string of 1 byte and write 2 bytes into this string => memory corruption.

Attached patch creates audioop_check_size() and audioop_check_parameters() functions.

----------
components: Extension Modules
files: audioop_check_length.patch
keywords: patch
messages: 97566
nosy: haypo
severity: normal
status: open
title: audioop: check that length is a multiple of the size
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15823/audioop_check_length.patch

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

From report at bugs.python.org  Mon Jan 11 07:52:31 2010
From: report at bugs.python.org (Chris Leary)
Date: Mon, 11 Jan 2010 06:52:31 +0000
Subject: [New-bugs-announce] [issue7674] select.select() corner cases:
	duplicate fds, out-of-range fds
In-Reply-To: <1263192751.1.0.719382931138.issue7674@psf.upfronthosting.co.za>
Message-ID: <1263192751.1.0.719382931138.issue7674@psf.upfronthosting.co.za>


New submission from Chris Leary <cdl28 at cornell.edu>:

I was just reading through this ACM article that enumerates some of the issues with the select function in .NET: http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext

select.select() currently suffers from the same documentation problem where the behavior with duplicate and/or out-of-range file descriptors in one of the sequences (i.e. rlist) is not described.

Given the current implementation of seq2set in trunk it appears that:

1. A ValueError is raised when a given file descriptor is out of range. (Typically a result of the programmer passing a non-fd value, since FD_SETSIZE is "normally at least equal to the maximum number of descriptors supported by the system.")

2. Duplicate file descriptor numbers are collapsed into the fd_set, and are therefore idempotent at a system API level.

However, the language-level support code generally assumes no duplication, as there is a fixed size array of (FD_SETSIZE + 1) pylist entries (one additional for a sentinel value). Although there is a TODO to dynamically size that to the largest targeted file descriptor number, that would still assume one PyObject per file descriptor in the input sequences.

The set2list function used to produce a return value will, however, return duplicates: for each value in the input list, if the corresponding fd is set, that pyobject is added to the return list.


Proposed Changes
----------------

At a glance it would seem that the Right Thing to do is to collapse duplicates in the input, as if we created a set(AsFileDescriptor(o) for o in input_list), so that no duplicates will be returned in the result; however, you *can* have a heterogeneous input list with a fileno like 5 and a file-like object whose fileno() resolved to 5, in which case you don't want to arbitrarily choose only one of those PyObjects to return. Therefore, I'm thinking it's probably best to leave it as-is and document it.

In any case, if we want to explicitly allow duplicates in the input list we should probably make the pylist arrays into dynamically sized structures in the sizes of the corresponding input lists for correctness.

If this all makes sense I'll be happy to come up with a module/documentation/unit test patch.

----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 97578
nosy: cdleary, georg.brandl
severity: normal
status: open
title: select.select() corner cases: duplicate fds, out-of-range fds
type: behavior

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

From report at bugs.python.org  Mon Jan 11 10:40:13 2010
From: report at bugs.python.org (pablo stapff)
Date: Mon, 11 Jan 2010 09:40:13 +0000
Subject: [New-bugs-announce] [issue7675] help() doesn't accept unicode
	literals in built in	docstrings
In-Reply-To: <1263202813.15.0.977842764671.issue7675@psf.upfronthosting.co.za>
Message-ID: <1263202813.15.0.977842764671.issue7675@psf.upfronthosting.co.za>


New submission from pablo stapff <pablo.stapff at gmail.com>:

We use umlaut in our docstrings and when we use the help() function to extract the documentation, the function reports an error:

UnicodeEncodeError: 'ascii' codec can't encode character....

Our docstrings are specified as unicode literals and the source file contains the line:

# -*- coding: utf-8 -*-


just import the module and make:

 help(tudelut.tudelut)

----------
components: Library (Lib)
files: tudelut.py
messages: 97584
nosy: psd
severity: normal
status: open
title: help() doesn't accept unicode literals in built in docstrings
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15827/tudelut.py

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

From report at bugs.python.org  Mon Jan 11 13:36:21 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Mon, 11 Jan 2010 12:36:21 +0000
Subject: [New-bugs-announce] [issue7676] IDLE shell shouldn't use TABs
In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za>
Message-ID: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za>


New submission from Cherniavsky Beni <cben at users.sf.net>:

IDLE defaults to indenting with 4 spaces in editor windows, but hard TABs in the Python Shell window.  This is inconsistent with PEP 8; what's worse, it's makes copy-paste code between the shell and editor windows confusing and dangerous!

Recently I gave a 3-day Python course to 6 people.  I spent some time explaining the dangers of TABs with Python's indentation-sensitive syntax and telling them "just use 4 spaces and all will be OK".  A few hours later one of them asked me why IDLE is refusing to run his code.  Turns out he copy-pasted code he tried out in the shell, edited it and tried running it, which resulted in a mix of tabs and spaces (which triggered IDLE's tabnanny check) and a mixture of 4 and 8 indents (which is ugly).

I had to explain IDLE's confusing behavior, introduce them to Untabify, and apologize for the inconvenience.  All this TABs stuff (and Untabify) are things people should eventually learn - but they shouldn't bite them on their first day!  (This is what Ubuntu calls a "papercut".)

The rationale for the current behavior seems to be making indentation clear despite the prompt offsetting the first line by 4:

>>> for i in range(3):
        print i

There are 3 alternative behaviors that would be better:

 (1) Use 8 spaces instead of a TAB.
 (2) Use 4 spaces.
 (3) Use 4 spaces, but add a GUI left margin of 4 to continuation lines.

(3) would be ideal, making copy-paste work cleanly while looking good.  I'm not sure if it can be implemented easily, but I'll look into it.

If it's hard, (2) would still be a big improvement IMHO.  I think correct behaviour is more important than looking good after ">>> " - but others may disagree on this.

If there is doubt, (1) is still strictly an improvement.  It can lead to mixed 8/4 spaces - but at least there won't be invisible problems that the user doesn't understand.

[Configurability concerns: all I said above refers to the *default* behavior of IDLE, which should follow 4-spaces.  The user should be able to configure it to use another width, or TABs.  This option already exists - but it's ignored outright by the shell window.  Solutions (2) and (3) would make the shell window respect it.]

----------
components: IDLE
messages: 97586
nosy: cben
severity: normal
status: open
title: IDLE shell shouldn't use TABs
type: behavior

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

From report at bugs.python.org  Mon Jan 11 16:22:34 2010
From: report at bugs.python.org (Rene Dudfield)
Date: Mon, 11 Jan 2010 15:22:34 +0000
Subject: [New-bugs-announce] [issue7677] distutils,
	better error message for setup.py upload -sign without identity.
In-Reply-To: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za>
Message-ID: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za>


New submission from Rene Dudfield <illume at users.sourceforge.net>:

hi,

When using setup.py upload --sign without --identity, gpg can give weird messages.

Rather than this error message:
"""running upload
gpg --detach-sign --local-user gn -a dist/pywebsite-0.1.18pre.tar.gz
gpg: skipped "gn": secret key not available
gpg: signing failed: secret key not available
error: command 'gpg' failed with exit status 2
make: *** [upload] Error 1"""

It might be nicer to also mention using --identity=, as well as a link to the documentation for --sign (url and also the help from "--help upload").

cheers,

----------
assignee: tarek
components: Distutils
messages: 97589
nosy: illume, tarek
severity: normal
status: open
title: distutils, better error message for setup.py upload -sign without identity.
type: behavior

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

From report at bugs.python.org  Mon Jan 11 22:26:50 2010
From: report at bugs.python.org (Steven K. Wong)
Date: Mon, 11 Jan 2010 21:26:50 +0000
Subject: [New-bugs-announce] [issue7678] subprocess.Popen pipeline example
	code in the	documentation is lacking
In-Reply-To: <1263245210.2.0.116487607425.issue7678@psf.upfronthosting.co.za>
Message-ID: <1263245210.2.0.116487607425.issue7678@psf.upfronthosting.co.za>


New submission from Steven K. Wong <sliderw at hotmail.com>:

The example code at http://www.python.org/doc/2.6.2/library/subprocess.html#replacing-shell-pipeline should be updated to add the close() call noted below:

output=`dmesg | grep hda`
==>
p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
p1.stdout.close()  # <----- this line is not in the doc, but we should add it
output = p2.communicate()[0]

The parent process does not use p1.stdout after passing it to p2, so it should close p1.stdout after that. If it is not closed, there is a possibility for p1's process to never terminate if p2's process fails. The following code demonstrate this situation:

from subprocess import Popen, PIPE
import time
# p1 is a program that writes lots of data to the pipe
cmd = ['cat', 'a_large_file']
p1 = Popen(cmd, stdout=PIPE)
# p2 is a program that fails without reading much data from the pipe
cmd = ['python', '-c', 'import time; time.sleep(5); asdf']
p2 = Popen(cmd, stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0]
while p1.poll() is None:  # it loops forever
    print 'sleep a bit'
    time.sleep(1)

----------
assignee: georg.brandl
components: Documentation
messages: 97606
nosy: georg.brandl, steven.k.wong
severity: normal
status: open
title: subprocess.Popen pipeline example code in the documentation is lacking
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 12 04:50:31 2010
From: report at bugs.python.org (Steve Steiner)
Date: Tue, 12 Jan 2010 03:50:31 +0000
Subject: [New-bugs-announce] [issue7679] Warning building 2.7 on OS X 10.6
	libintl.h "Present But	Cannot Be Compiled"
In-Reply-To: <1263268231.52.0.347802784561.issue7679@psf.upfronthosting.co.za>
Message-ID: <1263268231.52.0.347802784561.issue7679@psf.upfronthosting.co.za>


New submission from Steve Steiner <ssteinerX at gmail.com>:

I'm configuring with:

./configure --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk/ --with-universal-archs=intel

And get the following warning.  It told me to report it, so I am.

checking libintl.h presence... yes
configure: WARNING: libintl.h: present but cannot be compiled
configure: WARNING: libintl.h:     check for missing prerequisite headers?
configure: WARNING: libintl.h: see the Autoconf documentation
configure: WARNING: libintl.h:     section "Present But Cannot Be Compiled"
configure: WARNING: libintl.h: proceeding with the preprocessor's result
configure: WARNING: libintl.h: in the future, the compiler will take precedence
configure: WARNING:     ## -------------------------------------- ##
configure: WARNING:     ## Report this to http://bugs.python.org/ ##
configure: WARNING:     ## -------------------------------------- ##

----------
assignee: ronaldoussoren
components: Macintosh
messages: 97620
nosy: ronaldoussoren, ssteinerX
severity: normal
status: open
title: Warning building 2.7 on OS X 10.6 libintl.h "Present But Cannot Be Compiled"
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 12 05:22:21 2010
From: report at bugs.python.org (dontbugme)
Date: Tue, 12 Jan 2010 04:22:21 +0000
Subject: [New-bugs-announce] [issue7680] pythonw crash while attempting to
	start() a thread object
In-Reply-To: <1263270141.77.0.964688204265.issue7680@psf.upfronthosting.co.za>
Message-ID: <1263270141.77.0.964688204265.issue7680@psf.upfronthosting.co.za>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

PythonW.exe crash, tested under Windows 7 x86 / x64, Python v2.6.4.
The crash can be reproduced by opening and running the attached code in IDLE.
TY!

Error Message:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: C:\Python26\pythonw.exe
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Code:
#!/usr/bin/env python
import threading

class MyThread (threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        
    def run(self):
        print 'hello, dude!'
        
t = MyThread()
t.start()

----------
components: IDLE
messages: 97622
nosy: dontbugme
severity: normal
status: open
title: pythonw crash while attempting to start() a thread object
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 12 13:01:23 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Tue, 12 Jan 2010 12:01:23 +0000
Subject: [New-bugs-announce] [issue7681] Incorrect division in [wave.py]
	causing crash
In-Reply-To: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>
Message-ID: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>


New submission from Alf P. Steinbach <alfps at start.no>:

CPython 3.1.1 in Windows XP.

Traceback (most recent call last):
  File "C:\Documents and Settings\Alf\sound\error.py", line 6, in <module>
    writer.setframerate( framerate )
NameError: name 'framerate' is not defined
Exception wave.Error: Error('sampling rate not specified',) in <bound method Wave_write.__del__ of <wave.Wave_write obje
ct at 0x00FE87F0>> ignored

TO FIX:

"/" needs to be changed to "//" in lines and 243 464 of [wave.py]

----------
components: Library (Lib)
files: error.py
messages: 97629
nosy: alfps
severity: normal
status: open
title: Incorrect division in [wave.py] causing crash
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file15834/error.py

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

From report at bugs.python.org  Tue Jan 12 13:22:03 2010
From: report at bugs.python.org (Sylvain Defresne)
Date: Tue, 12 Jan 2010 12:22:03 +0000
Subject: [New-bugs-announce] [issue7682] Optimisation of if with constant
	expression
In-Reply-To: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za>
Message-ID: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za>


New submission from Sylvain Defresne <sdefresne at gmail.com>:

Python compiler detect some constant expression used in if / while statement and evaluate them at compilation. However, it does not perform some simple optimisation (evaluating not unary expression or checking if and or or expression are constant because of the first expression).

The attached patch allow Python to detect some more constant expression, and to optimise test like the following:

   if __debug__ and x:
       pass

   if not __debug__:
       pass

----------
components: Interpreter Core
files: compile.diff
keywords: patch
messages: 97631
nosy: sdefresne
severity: normal
status: open
title: Optimisation of if with constant expression
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file15836/compile.diff

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

From report at bugs.python.org  Tue Jan 12 18:01:40 2010
From: report at bugs.python.org (Francesco Ricciardi)
Date: Tue, 12 Jan 2010 17:01:40 +0000
Subject: [New-bugs-announce] [issue7683] Wrong link in HTML documentation
In-Reply-To: <1263315700.03.0.719806034204.issue7683@psf.upfronthosting.co.za>
Message-ID: <1263315700.03.0.719806034204.issue7683@psf.upfronthosting.co.za>


New submission from Francesco Ricciardi <francesco.ricciardi at hp.com>:

The first page of the Python Tutorial in version 3.1 (http://docs.python.org/3.1/tutorial/index.html) has the "previous topic" link pointing to "What?s New in Python 2.0" instead of "What?s New in Python 3.1".

----------
assignee: georg.brandl
components: Documentation
messages: 97635
nosy: francescor, georg.brandl
severity: normal
status: open
title: Wrong link in HTML documentation
versions: Python 3.1

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

From report at bugs.python.org  Tue Jan 12 21:18:37 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 12 Jan 2010 20:18:37 +0000
Subject: [New-bugs-announce] [issue7684] decimal.py: infinity coefficients
	in tuples
In-Reply-To: <1263327517.52.0.041459928833.issue7684@psf.upfronthosting.co.za>
Message-ID: <1263327517.52.0.041459928833.issue7684@psf.upfronthosting.co.za>


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

It should not be possible to pass coefficients when constructing infinities from tuples. Otherwise it looks like infinities can have payloads (which they can't).

Example:

>>> import decimal, cdecimal
>>> d = decimal.Decimal((0, (4, 5, 3, 4), 'F'))
>>> d
Decimal('Infinity')

>>> d = cdecimal.Decimal((0, (4, 5, 3, 4), 'F'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
cdecimal.InvalidOperation: [<class 'cdecimal.ConversionSyntax'>]


Also, the non-coefficient of infinities should preferably be represented as an empty tuple:

>>> decimal.Decimal("Infinity").as_tuple()
DecimalTuple(sign=0, digits=(0,), exponent='F')
>>> cdecimal.Decimal("Infinity").as_tuple()
(0, (), 'F')

----------
components: Library (Lib)
messages: 97656
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: infinity coefficients in tuples
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan 12 23:03:09 2010
From: report at bugs.python.org (Michael Stephens)
Date: Tue, 12 Jan 2010 22:03:09 +0000
Subject: [New-bugs-announce] [issue7685] minor typo in re docs
In-Reply-To: <1263333789.06.0.194197176787.issue7685@psf.upfronthosting.co.za>
Message-ID: <1263333789.06.0.194197176787.issue7685@psf.upfronthosting.co.za>


New submission from Michael Stephens <me at mikej.st>:

Just something small that bothers me whenever I'm in the re docs - his name's spelled 'Malcolm Reynolds', not 'Malcom Reynolds' ;)

----------
assignee: georg.brandl
components: Documentation
files: malcolm_typo.diff
keywords: patch
messages: 97662
nosy: georg.brandl, mikejs
severity: normal
status: open
title: minor typo in re docs
versions: Python 2.7
Added file: http://bugs.python.org/file15844/malcolm_typo.diff

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

From report at bugs.python.org  Wed Jan 13 01:28:56 2010
From: report at bugs.python.org (ivank)
Date: Wed, 13 Jan 2010 00:28:56 +0000
Subject: [New-bugs-announce] [issue7686] redundant open modes 'rbb', 'wbb',
	'abb' no longer work on Windows
In-Reply-To: <1263342536.73.0.0502696558207.issue7686@psf.upfronthosting.co.za>
Message-ID: <1263342536.73.0.0502696558207.issue7686@psf.upfronthosting.co.za>


New submission from ivank <ivan at ludios.org>:

This probably only applies to Windows. The redundant 'b' modes still work on Linux.

These worked on Windows in 2.6.4:

open('test', 'rbb')
open('test', 'wbb')
open('test', 'abb')

and possibly others.

In 2.7a2, they throw ValueErrors like this:

>>> open('test', 'wbb')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid mode ('wbb')

It would be nice if the old behavior were preserved for backwards compatibility. Some programs append a 'b' indiscriminately.

----------
messages: 97674
nosy: ivank
severity: normal
status: open
title: redundant open modes 'rbb', 'wbb', 'abb' no longer work on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 13 08:28:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 07:28:23 +0000
Subject: [New-bugs-announce] [issue7687] Bluetooth support untested
In-Reply-To: <1263367703.76.0.187821272753.issue7687@psf.upfronthosting.co.za>
Message-ID: <1263367703.76.0.187821272753.issue7687@psf.upfronthosting.co.za>


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

We have bluetooth support in the socket module but it never gets tested in the regression suite.

----------
components: Library (Lib), Tests
messages: 97696
nosy: brian.curtin, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Bluetooth support untested
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/issue7687>
_______________________________________

From report at bugs.python.org  Wed Jan 13 08:47:00 2010
From: report at bugs.python.org (Frank Millman)
Date: Wed, 13 Jan 2010 07:47:00 +0000
Subject: [New-bugs-announce] [issue7688] TypeError: __name__ must be set to
	a string object
In-Reply-To: <1263368820.05.0.872831790778.issue7688@psf.upfronthosting.co.za>
Message-ID: <1263368820.05.0.872831790778.issue7688@psf.upfronthosting.co.za>


New submission from Frank Millman <frank at chagford.com>:

At the top of my program I have 'from __future__ import unicode_literals'.

The relevant lines from my program read -
    from multiprocessing.managers import BaseManager
    class MyManager(BaseManager): pass
    MyManager.register('my_function', my_function)

In multiprocessing.managers.py, the following lines are executed -

605 @classmethod
606 def register(cls, typeid, ...)
        [...]
632     def temp(...):
            [...]
642     temp.__name__ = typeid

At this point, Python raises the exception
    TypeError: __name__ must be set to a string object

I can fix it by changing my last line to -
    MyManager.register(str('my_function'), my_function)

Is it possible to allow __name__ to be a unicode object?

If not, may I suggest that line 642 of managers.py is changed to -
        temp.__name__ = str(typeid)

Frank Millman

----------
components: Library (Lib)
messages: 97697
nosy: frankmillman
severity: normal
status: open
title: TypeError: __name__ must be set to a string object
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 13 10:32:14 2010
From: report at bugs.python.org (Craig Citro)
Date: Wed, 13 Jan 2010 09:32:14 +0000
Subject: [New-bugs-announce] [issue7689] Pickling of classes with a
	metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>


New submission from Craig Citro <craigcitro at gmail.com>:

Currently, it's impossible to use the usual pickle mechanisms to pickle a dynamically created class, even if the user requests a different pickling mechanism via copy_reg. The attached patch makes this customization possible by simply transposing two blocks of code. 

Longer explanation: Classes are pickled by name, which is of course problematic when trying to pickle a dynamically created class. The natural solution would be to create a __reduce__ method on the metaclass. However, as mentioned in issue 494904, this won't work -- the issue is that for any class C with a metaclass M, C.__reduce__ is the unbound method for instances of class C, as opposed to the bound method M.__reduce__ for C (i.e. viewing C as an instance of M). Guido's patch on that ticket does the sensible thing, which is force the class to be pickled by name -- this is fine, until you want to pickle a class that's created at runtime. 

The copy_reg module exists to handle custom pickling of objects, which is exactly what's needed here. However, the code from #494904 that checks for instances of a metaclass does this *just before* it looks at the copy_reg dispatch table. The patches just reorder these tests in pickle.py and cPickle.c, so that one can register a custom pickler for instances of a metaclass. 

Comments: First, let me preemptively say that I do indeed have a use case for this fix. We ran into this bug working on Sage (http://www.sagemath.org), where we create lots of dynamic classes at runtime (to model mathematical relationships between different kinds of objects). There's a healthy mix of dynamic and non-dynamic classes floating around, and we want the user to be able to pickle them without having to know anything about how the class was created. We could create our own pickling function, but we'd much rather just use the default Python mechanisms, especially since it's such a small fix.

Second, this patch is fairly "safe," in the sense that it's pretty unlikely it can break any existing code. The only way it could break is if someone created a dynamic class, registered a pickler for it with copy_reg, and was depending on calls to pickle to fail. 

Third, there's a few extra lines of code in the chunk the patch moves around coming from ticket #502085. These are there to deal with versions of Boost circa 2002. Is it worth removing these?

The attached patch is against trunk (r77421). At least as I write this, the same patch should apply against the py3k branch (up to renaming copy_reg to copyreg, anyway), but I'm happy to do the legwork of rebasing it as needed. 

Also, I'd happily review something else in exchange for a review of this. We'll be keeping this patch around in Sage until it gets merged, so the sooner the better.

Authors: Nicolas Thiery (nthiery at users.sf.net) first hunted this down and wrote a patch for cPickle.c. I did the (fairly trivial) work of mirroring the fix in pickle.py, and added the tests in pickletester.

----------
components: Library (Lib)
files: dynamic_class_copyreg.patch
keywords: patch
messages: 97702
nosy: craigcitro
severity: normal
status: open
title: Pickling of classes with a metaclass and copy_reg
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15853/dynamic_class_copyreg.patch

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

From report at bugs.python.org  Wed Jan 13 11:48:31 2010
From: report at bugs.python.org (Francesco Ricciardi)
Date: Wed, 13 Jan 2010 10:48:31 +0000
Subject: [New-bugs-announce] [issue7690] Wrong PEP number in importlib
	module manual page
In-Reply-To: <1263379711.7.0.204631557384.issue7690@psf.upfronthosting.co.za>
Message-ID: <1263379711.7.0.204631557384.issue7690@psf.upfronthosting.co.za>


New submission from Francesco Ricciardi <francesco.ricciardi at hp.com>:

At the end of section 2.9.1 of the Library Reference, i.e. the introduction to the importlib module manual page, there is the See Also box that often we can find in the manual pages. The last PEP of the box has the title ("Using UTF-8 as the Default Source Encoding") and number 3128. Number and title collide.

I believe the title is correct, i.e. the numbe should be changed to 3120, and the link correspondingly.

----------
assignee: georg.brandl
components: Documentation
messages: 97707
nosy: francescor, georg.brandl
severity: normal
status: open
title: Wrong PEP number in importlib module manual page
versions: Python 3.1

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

From report at bugs.python.org  Wed Jan 13 14:16:19 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 13:16:19 +0000
Subject: [New-bugs-announce] [issue7691] test_bsddb3 files are not always
	removed when test fails
In-Reply-To: <1263388579.43.0.73329737897.issue7691@psf.upfronthosting.co.za>
Message-ID: <1263388579.43.0.73329737897.issue7691@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

The series of failures 2808-2838 in buildbot x86 XP-4 is due to a file which was not removed after test 2807 was aborted.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%20trunk/builds/2807

----------
components: Tests
keywords: buildbot
messages: 97713
nosy: flox
severity: normal
stage: test needed
status: open
title: test_bsddb3 files are not always removed when test fails
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 13 15:01:25 2010
From: report at bugs.python.org (Bugger)
Date: Wed, 13 Jan 2010 14:01:25 +0000
Subject: [New-bugs-announce] [issue7692] Pointless comparision of unsigned
	integer with zero
In-Reply-To: <1263391285.46.0.0470280640961.issue7692@psf.upfronthosting.co.za>
Message-ID: <1263391285.46.0.0470280640961.issue7692@psf.upfronthosting.co.za>


New submission from Bugger <buffer.100.webmaster at spamgourmet.com>:

Hi,

small preprocessor warning.

Pointless comparision of unsigned integer with zero. Check PyMem_NEW.

Can an usigned int be smaller than 0? < comparision is "pointless" here.

Bye, Bugger

----------
components: None
messages: 97716
nosy: Bugger
severity: normal
status: open
title: Pointless comparision of unsigned integer with zero
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 13 15:08:23 2010
From: report at bugs.python.org (Peter Bienstman)
Date: Wed, 13 Jan 2010 14:08:23 +0000
Subject: [New-bugs-announce] [issue7693] tarfile.extractall can't have
	unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>


New submission from Peter Bienstman <Peter.Bienstman at UGent.be>:

import tarfile

fname = unichr(40960) + u"a.ogg"

f = file(fname, "w")
f.write("A")
f.close()
        
tar_pipe = tarfile.open("test.tar", mode="w|",
    format=tarfile.PAX_FORMAT)
tar_pipe.add(fname)
tar_pipe.close()

tar_pipe = tarfile.open("test.tar")
tar_pipe.extractall(u".") # Just "." as string works fine.

This gives:

Traceback (most recent call last):
  File "a.py", line 15, in <module>
    tar_pipe.extractall(u".") # Just "." as string works fine.
  File "/usr/lib/python2.6/tarfile.py", line 2031, in extractall
    self.extract(tarinfo, path)
  File "/usr/lib/python2.6/tarfile.py", line 2068, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/usr/lib/python2.6/posixpath.py", line 70, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xea in position 1: ordinal not in range(128)

----------
components: Extension Modules
messages: 97717
nosy: pbienst
severity: normal
status: open
title: tarfile.extractall can't have unicode extraction path
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Wed Jan 13 17:48:39 2010
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 13 Jan 2010 16:48:39 +0000
Subject: [New-bugs-announce] [issue7694] DeprecationWarning from
	distuils.commands.build_ext needs	stacklevel
In-Reply-To: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>
Message-ID: <1263401319.23.0.932890994142.issue7694@psf.upfronthosting.co.za>


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

2.7 has a new DeprecationWarning inside the build_ext command for code
which sets the 'compiler' to anything other than a string or None.
Because the warning occurs within property getter / setters, it needs
to boost the stacklevel for the warning above the default value of 1.
In addition, the setter is called from within '__setattr__', which means
that it needs to be incremented again in that case.

The attached patch does both of these things.

----------
assignee: tarek
components: Distutils
files: python-2.7-distutils_warning.patch
keywords: patch
messages: 97725
nosy: tarek, tseaver
severity: normal
status: open
title: DeprecationWarning from distuils.commands.build_ext needs stacklevel
versions: Python 2.7
Added file: http://bugs.python.org/file15857/python-2.7-distutils_warning.patch

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

From report at bugs.python.org  Wed Jan 13 21:02:30 2010
From: report at bugs.python.org (Conor Hughes)
Date: Wed, 13 Jan 2010 20:02:30 +0000
Subject: [New-bugs-announce] [issue7695] missing termios constants
In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>
Message-ID: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>


New submission from Conor Hughes <conorh at berkeley.edu>:

Module termios is missing some constants useful for handling control characters under Mac OS X (and Solaris, and probably BSD but I don't have a pure BSD system to test against).

In particular, these systems support a control character "DSUSP" (which is similar to SUSP), but there is no provided symbol for the index into the cc array to use. The correct value for the proposed termios.VDSUSP would be 11 on MacOS and Solaris. I'm no Linux wizard but I don't believe it has this control character.

In addition, MacOS supports a control character STATUS, and the correct value for the proposed termios.VSTATUS would be 18.

Likewise, _POSIX_VDISABLE (or some similar identifier) is missing from the module. I believe the correct value on Solaris would be '\x00', MacOS '\xff', Linux '\x00'.

----------
components: Library (Lib)
messages: 97736
nosy: conorh
severity: normal
status: open
title: missing termios constants
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Wed Jan 13 22:33:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 21:33:51 +0000
Subject: [New-bugs-announce] [issue7696] Improve Memoryview/Buffer
	documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Various notes while reading the Memoryview documentation:

 - ?memoryviews allow Python code to access the internal data of an object that supports the buffer protocol without copying. Memory can be interpreted as simple bytes or complex data structures.? This is quite obscure because there's no definition of the "buffer protocol".

 - a link from 6.10 to the c-api/buffer.html page may be useful

 - the memoryview.suboffsets attribute is not documented on the "6.10 memoryview Type" page

 - there's no glossary entry for the "buffer protocol" (does it deserve an entry?)

 - "Memoryview" is title-cased in one case (c-api/buffer.html) but lowercased for the title of section 6.10 (stdtypes.html#memoryview-types)

----------
assignee: georg.brandl
components: Documentation
messages: 97738
nosy: flox, georg.brandl
severity: normal
status: open
title: Improve Memoryview/Buffer documentation
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jan 13 23:35:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 22:35:09 +0000
Subject: [New-bugs-announce] [issue7697] os.getcwd() should raise
	UnicodeDecodeError for arbitrary	bytes
In-Reply-To: <1263422109.69.0.664719767717.issue7697@psf.upfronthosting.co.za>
Message-ID: <1263422109.69.0.664719767717.issue7697@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

When the current working directory is not decodable, the os.getcwd() function should raise an error.

>>> sys.getfilesystemencoding()
'utf-8'
>>> cwd=b'/tmp/\xe7'
>>> os.mkdir(cwd); os.chdir(cwd)
>>> os.getcwdb()
b'/tmp/\xe7'
>>> os.getcwd()  # Should raise UnicodeDecodeError
'/tmp/\udce7'

Python 2 raises the error.

----------
components: Extension Modules
messages: 97740
nosy: flox
severity: normal
status: open
title: os.getcwd() should raise UnicodeDecodeError for arbitrary bytes
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jan 14 01:49:08 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 14 Jan 2010 00:49:08 +0000
Subject: [New-bugs-announce] [issue7698] pystack macro in Misc/gdbinit
	incorrectly uses	PyEval_EvalFrame
In-Reply-To: <1263430148.48.0.231391407201.issue7698@psf.upfronthosting.co.za>
Message-ID: <1263430148.48.0.231391407201.issue7698@psf.upfronthosting.co.za>


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

pystack tries to detect C frames which it can extract Python frame info from.  However, it still references the old, now (supposedly) unused PyEval_EvalFrame function.  This leads it to never find any frames, since PyEval_EvalFrameEx is now what's actually on the stack.  It should be referring to that function.

Attached makes the necessary change.

----------
components: Demos and Tools
files: evalframeex.patch
keywords: patch
messages: 97744
nosy: exarkun
severity: normal
status: open
title: pystack macro in Misc/gdbinit incorrectly uses PyEval_EvalFrame
versions: Python 2.6
Added file: http://bugs.python.org/file15864/evalframeex.patch

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

From report at bugs.python.org  Thu Jan 14 02:46:02 2010
From: report at bugs.python.org (Michael Stephens)
Date: Thu, 14 Jan 2010 01:46:02 +0000
Subject: [New-bugs-announce] [issue7699] strptime, strftime documentation
In-Reply-To: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za>
Message-ID: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za>


New submission from Michael Stephens <me at mikej.st>:

The documentation for strftime and strptime behavior strikes me as a bit jumbled right now. The behavior of datetime.datetime.strptime is explained by a reference to time.strptime, which in turn references time.strftime to explain the format string.

The docs for the datetime.{datetime,date,time}.strftime methods, on the other hand, reference the 'strftime Behavior' section of the datetime module docs to explain the behavior of the format string. This section even notes the differences between strptime and strftime behavior.

I've tried to clear this up a little bit by renaming this section 'strftime and strptime Behavior' and referencing it from the datetime.datetime.strptime docs.

----------
assignee: georg.brandl
components: Documentation
files: strptime.diff
keywords: patch
messages: 97748
nosy: georg.brandl, mikejs
severity: normal
status: open
title: strptime, strftime documentation
versions: Python 2.7
Added file: http://bugs.python.org/file15866/strptime.diff

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

From report at bugs.python.org  Thu Jan 14 11:20:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 10:20:21 +0000
Subject: [New-bugs-announce] [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

The -3 flag no longer works with Python 2.7.

~ $ ./python -3 -c 'print 1 <> 2, {}.has_key(3)'
True False


On python 2.6:

~ $ ./python -3 -c 'print 1 <> 2, {}.has_key(3)'
<string>:1: DeprecationWarning: <> not supported in 3.x; use !=
-c:1: DeprecationWarning: dict.has_key() not supported in 3.x; use the in operator
True False

----------
messages: 97754
nosy: flox
severity: normal
status: open
title: "-3" flag does not work anymore
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 14 12:56:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 11:56:22 +0000
Subject: [New-bugs-announce] [issue7701] fix output string length for
	binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>


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

binascii_b2a_uu() estimate the output string length using 2+bin_len*2.
It's almost correct... except for bin_len=1. The result is a memory
write into unallocated memory:

   $ ./python -c "import binascii; binascii.b2a_uu('x')"
   Debug memory block at address p=0x87da568: API 'o'
       33 bytes originally requested
       The 3 pad bytes at p-3 are FORBIDDENBYTE, as expected.
       The 4 pad bytes at tail=0x87da589 are not all FORBIDDENBYTE (0xfb):
           at tail+0: 0x0a *** OUCH
           at tail+1: 0xfb
           at tail+2: 0xfb
           at tail+3: 0xfb
       The block was made by call #25195 to debug malloc/realloc.
       Data at p: 00 00 00 00 00 00 00 00 ... 00 00 00 21 3e 20 20 20
   Fatal Python error: bad trailing pad byte
   Abandon

Current output string length estimation for input string 0..10:

    >>> [len(binascii.b2a_uu("x"*bin_len)) for bin_len in xrange(10)]
    [2, 6, 6, 6, 10, 10, 10, 14, 14, 14]
    >>> [(2+bin_len*2) for bin_len in xrange(10)]
    [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

The estimation is correct for all lengths... except for bin_len=1. And
it's oversized for bin_len >= 9. The exact length is:

    2+ceil(bin_len*8/6) <=> 2+(bin_len+5)*8//6 <=> 2+(bin_len+2)*4//3

Example with length 0..10:

    >>> [len(binascii.b2a_uu("x"*bin_len)) for bin_len in xrange(10)]
    [2, 6, 6, 6, 10, 10, 10, 14, 14, 14]
    >>> [(2+(bin_len+2)*4//3) for bin_len in xrange(10)]
    [4, 6, 7, 8, 10, 11, 12, 14, 15, 16]

Attached patch uses the correct estimation.

----------
components: Extension Modules
files: binascii_b2a_uu_length.patch
keywords: patch
messages: 97759
nosy: haypo
severity: normal
status: open
title: fix output string length for binascii.b2a_uu()
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15871/binascii_b2a_uu_length.patch

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

From report at bugs.python.org  Thu Jan 14 14:15:14 2010
From: report at bugs.python.org (alito)
Date: Thu, 14 Jan 2010 13:15:14 +0000
Subject: [New-bugs-announce] [issue7702] Wrong order of parameters of
	_get_socket in SMTP class in	smtplib.py
In-Reply-To: <1263474914.94.0.504255550545.issue7702@psf.upfronthosting.co.za>
Message-ID: <1263474914.94.0.504255550545.issue7702@psf.upfronthosting.co.za>


New submission from alito <alito at organicrobot.com>:

Trivial change with (almost) no effect.

The method signature for _get_socket in the SMTP class in stmplib.py is 

def _get_socket(self, port, host, timeout)

It should be:

def _get_socket(self, host, port, timeout)

Evidence:
1) It calls socket.create_connection((port, host), ....) but socket.create_connection expects (host, port).
2) The only time it is called in smtplib.py, it is called as self._get_socket(host, port, self.timeout)
3) In the derived class SMTP_SSL, it is defined as (self, host, port, timeout)


I wrote _almost_ no effect because the debugging output from it will now be in the right order (host, port).

Patch wrt python svn trunk follows:

Index: smtplib.py
===================================================================
--- smtplib.py	(revision 77465)
+++ smtplib.py	(working copy)
@@ -266,11 +266,11 @@
         """
         self.debuglevel = debuglevel
 
-    def _get_socket(self, port, host, timeout):
+    def _get_socket(self, host, port, timeout):
         # This makes it simpler for SMTP_SSL to use the SMTP connect code
         # and just alter the socket connection bit.
         if self.debuglevel > 0: print>>stderr, 'connect:', (host, port)
-        return socket.create_connection((port, host), timeout)
+        return socket.create_connection((host, port), timeout)
 
     def connect(self, host='localhost', port = 0):
         """Connect to a host on a given port.

----------
components: Library (Lib)
messages: 97761
nosy: alito
severity: normal
status: open
title: Wrong order of parameters of _get_socket in SMTP class in smtplib.py
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Jan 14 15:17:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 14:17:11 +0000
Subject: [New-bugs-announce] [issue7703] Replace buffer()-->memoryview() in
	Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

In order to upgrate the tests for ctypes, following changes are required:
 - binascii.hexlify should accept memoryview() objects
 - the ctypes character buffer should accept assignment of memoryview() objects using their "raw" property

Then we can backport the Py3 ctypes tests to Py2.

----------
messages: 97765
nosy: flox
severity: normal
stage: needs patch
status: open
title: Replace buffer()-->memoryview() in Lib/ctypes/test/
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 14 21:44:28 2010
From: report at bugs.python.org (pedro flores)
Date: Thu, 14 Jan 2010 20:44:28 +0000
Subject: [New-bugs-announce] [issue7704] Math calculation problem
	(1.6-1.0)>0.6, python said TRUE
In-Reply-To: <1263501868.58.0.76775224698.issue7704@psf.upfronthosting.co.za>
Message-ID: <1263501868.58.0.76775224698.issue7704@psf.upfronthosting.co.za>


New submission from pedro flores <pflores82 at gmail.com>:

this simple comparison (1.6-1.0)>0.6 , python answer TRUE, and that isnt true.

----------
components: Windows
files: bug.py
messages: 97785
nosy: DhaReaL
severity: normal
status: open
title: Math calculation problem (1.6-1.0)>0.6, python said TRUE
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15883/bug.py

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

From report at bugs.python.org  Fri Jan 15 06:59:45 2010
From: report at bugs.python.org (Alexis Ballier)
Date: Fri, 15 Jan 2010 05:59:45 +0000
Subject: [New-bugs-announce] [issue7705] libpython2.6.so is not linked
	correctly on FreeBSD when	threads are enabled
In-Reply-To: <1263535185.62.0.219430416726.issue7705@psf.upfronthosting.co.za>
Message-ID: <1263535185.62.0.219430416726.issue7705@psf.upfronthosting.co.za>


New submission from Alexis Ballier <aballier at gentoo.org>:

As reported in https://bugs.gentoo.org/show_bug.cgi?id=300961 :

# gcc foo.c -lpython2.6
/usr/lib/gcc/i686-gentoo-freebsd7.2/4.4.2/../../../libpython2.6.so: undefined
reference to `pthread_create'
collect2: ld returned 1 exit status



libpython2.6.so doesn't get linked with -pthread; I'll attach a patch fixing this, the configure script does its magic but doesn't reuse that magic for setting LDSHARED.

----------
components: Build
files: python_fbsd_pthread.patch
keywords: patch
messages: 97800
nosy: aballier
severity: normal
status: open
title: libpython2.6.so is not linked correctly on FreeBSD when threads are enabled
versions: Python 2.6
Added file: http://bugs.python.org/file15890/python_fbsd_pthread.patch

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

From report at bugs.python.org  Fri Jan 15 14:14:20 2010
From: report at bugs.python.org (Andrej Krpic)
Date: Fri, 15 Jan 2010 13:14:20 +0000
Subject: [New-bugs-announce] [issue7706] Missing #include guards
In-Reply-To: <1263561260.15.0.13041437234.issue7706@psf.upfronthosting.co.za>
Message-ID: <1263561260.15.0.13041437234.issue7706@psf.upfronthosting.co.za>


New submission from Andrej Krpic <akrpic77 at gmail.com>:

Patch provides consistency with include guards already present in core.
This issue is somehow next step to #1495999 and #1492356.
These headers are missing from MSVC when targeting MS Windows CE .

HAVE_PROCESS_H already used in:
Modules/posixmodule.c, Python/thread_nt.h

HAVE_SYS_TYPES_H already used in:
Modules/io/_iomodule.c, Objects/fileobject.c, ...

HAVE_SIGNAL_H already in:
Modules/posixmodule.c

HAVE_ERRNO_H already in:
Include/Python.h, Python/ceval.c, ...
DONT_HAVE_ERRNO_H is not used anywhere

HAVE_FCNTL_H already in:
Modules/posixmodule.c, Modules/socketmodule.c

----------
components: Interpreter Core
files: missing_ifdef_s.patch
keywords: patch
messages: 97809
nosy: akrpic77
severity: normal
status: open
title: Missing #include guards
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file15891/missing_ifdef_s.patch

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

From report at bugs.python.org  Fri Jan 15 17:35:15 2010
From: report at bugs.python.org (Alon Zakai)
Date: Fri, 15 Jan 2010 16:35:15 +0000
Subject: [New-bugs-announce] [issue7707] multiprocess.Queue operations
	during import can lead to	deadlocks
In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za>
Message-ID: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za>


New submission from Alon Zakai <thoughtcube at gmail.com>:

Creating a multiprocessing.Queue and operating on it while being imported can lead to a deadlock.

The attached file will work if run directly (python test.py) but will hang if imported from the interpreter (import test).

Additional comments are in the file.

----------
components: Library (Lib)
files: test.py
messages: 97820
nosy: kripken
severity: normal
status: open
title: multiprocess.Queue operations during import can lead to deadlocks
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15894/test.py

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

From report at bugs.python.org  Fri Jan 15 18:20:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 17:20:38 +0000
Subject: [New-bugs-announce] [issue7708] test_xmlrpc fails with non-ascii
	path
In-Reply-To: <1263576038.96.0.565214554799.issue7708@psf.upfronthosting.co.za>
Message-ID: <1263576038.96.0.565214554799.issue7708@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Another buildbot failure (repeated on AMD64 Ubuntu wide).


test_xmlrpc
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 59299)
Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/xmlrpc/server.py", line 474, in do_POST
    size_remaining = int(self.headers["content-length"])
ValueError: invalid literal for int() with base 10: 'I am broken'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/socketserver.py", line 282, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/socketserver.py", line 308, in process_request
    self.finish_request(request, client_address)
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/socketserver.py", line 321, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/socketserver.py", line 637, in __init__
    self.handle()
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/http/server.py", line 360, in handle
    self.handle_one_request()
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/http/server.py", line 348, in handle_one_request
    method()
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/xmlrpc/server.py", line 502, in do_POST
    self.send_header("X-traceback", traceback.format_exc())
  File "/home/buildbot/cpython-ucs4-nonascii-???/3.x.pitrou-ubuntu-wide/build/Lib/http/server.py", line 418, in send_header
    self.wfile.write(("%s: %s\r\n" % (keyword, value)).encode('ASCII', 'strict'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 93: ordinal not in range(128)

----------
components: Tests
keywords: buildbot
messages: 97827
nosy: flox
severity: normal
stage: test needed
status: open
title: test_xmlrpc fails with non-ascii path
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jan 15 19:55:18 2010
From: report at bugs.python.org (Phlip)
Date: Fri, 15 Jan 2010 18:55:18 +0000
Subject: [New-bugs-announce] [issue7709] the msg parameters of PyUnit
	assertions, such as assertEqual,
	should not obscure the automated diagnostics, such as '%s != %s'
In-Reply-To: <1263581718.9.0.313576531416.issue7709@psf.upfronthosting.co.za>
Message-ID: <1263581718.9.0.313576531416.issue7709@psf.upfronthosting.co.za>


New submission from Phlip <phlip2005 at gmail.com>:

The various assertions are not DRY when they force you to repeat any automatic diagnostic in a message string, if you provide it.

Here's an example:

    def assertEqual(self, first, second, msg=None):
         self.assert_((first == second), msg or '%s != %s' % (first, second))

I think it should work like this:
 
     def assertEqual(self, first, second, msg=''):
         self.assert_((first == second),
 		(msg + ('\n%s != %s' % (first, second))).strip())
 
That way, if you provide a message (such as a message describing the semantic _meaning_ why "41" should not equal "42"), the assertion does not throw away the automatically generated "41 != 42".

In the current system, to correctly reflect the 41 and 42, you must add them to the msg body. This is redundant with the assertions' primary behaviors...

----------
components: Tests
messages: 97833
nosy: Phlip
severity: normal
status: open
title: the msg parameters of PyUnit assertions, such as assertEqual, should not obscure the automated diagnostics, such as '%s != %s'
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Jan 15 20:35:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 19:35:23 +0000
Subject: [New-bugs-announce] [issue7710] Inconsistent Exception for int()
	conversion
In-Reply-To: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>
Message-ID: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

On Python 3:

>>> int('\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character '\x00' in position 0: invalid decimal Unicode string

>>> int('\01')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '\x01'

>>> int('\x80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte

>>> int('\xc0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0: unexpected end of data


On Python 2, it raises ValueError (except for '\0').

----------
components: Interpreter Core
messages: 97839
nosy: flox
severity: normal
status: open
title: Inconsistent Exception for int() conversion
versions: Python 3.2

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

From report at bugs.python.org  Sat Jan 16 06:15:20 2010
From: report at bugs.python.org (Scott Kitterman)
Date: Sat, 16 Jan 2010 05:15:20 +0000
Subject: [New-bugs-announce] [issue7711] csv error name incorrect
In-Reply-To: <1263618920.78.0.558103176688.issue7711@psf.upfronthosting.co.za>
Message-ID: <1263618920.78.0.558103176688.issue7711@psf.upfronthosting.co.za>


New submission from Scott Kitterman <sklist at kitterman.com>:

Using the csv module I encountered an ASCII NUL in a file and got this error:

"_csv.Error: line contains NULL byte"

According to the documentation ( http://docs.python.org/library/csv.html#module-contents ) it should be csv.Error:.  Attempting to trap the error using try:/except _csv.Error: does not work.  It needs to be except csv.Error:.

----------
components: None
messages: 97864
nosy: kitterma
severity: normal
status: open
title: csv error name incorrect
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Jan 16 06:42:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jan 2010 05:42:27 +0000
Subject: [New-bugs-announce] [issue7712] Add a context manager to change cwd
	in test.test_support
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

To simplify the tests that require a different CWD I wrote a context manager that allows to change the working directory. I used it on #3426 to test os.path.abspath() with ASCII and non-ASCII CWDs and realized that it can also be used to fix #5684 where a zipfile fails to extract the content of the archive in the CWD if it is read-only.

Patch attached.

----------
assignee: ezio.melotti
components: Tests
files: tempcwd.patch
keywords: needs review, patch, patch
messages: 97865
nosy: ezio.melotti, flox
priority: normal
severity: normal
stage: patch review
status: open
title: Add a context manager to change cwd in test.test_support
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15904/tempcwd.patch

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

From report at bugs.python.org  Sat Jan 16 16:01:30 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 15:01:30 +0000
Subject: [New-bugs-announce] [issue7713] implement ability to disable
	automatic search path	additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

setup.py adds in various places hardcoded paths to locations in the filesystem that may contain libraries/includes to compile a given module or feature.

While this behaviour is probably interesting for some users, it is undesirable for distributions that use a package manager to track and install dependencies in a given offset on top of a host system such as Mac OS X, Solaris, AIX, HPUX, etc.

Examples are:
http://trac.macports.org/browser/trunk/dports/lang/python26/files/patch-setup.py.diff
http://www.mail-archive.com/openpkg-dev at openpkg.org/msg09547.html
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/dev-lang/python/files/python-2.5.1-no-usrlocal.patch

It would be great if there was a way to disable setup.py from looking for hardcoded paths, and instead completely rely on the behaviour of compiler and linker (or e.g. CFLAGS as given)

----------
components: Build
messages: 97880
nosy: grobian
severity: normal
status: open
title: implement ability to disable automatic search path additions
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jan 16 17:25:11 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 16:25:11 +0000
Subject: [New-bugs-announce] [issue7714] configure GCC version detection fix
	for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

configure.in contains a check for the compiler in use for Darwin like this:

gcc_version=`gcc -v 2>&1 |  grep version | cut -d\  -f3`

This yields in a wrong answer if the output of gcc -v has "version" in another place as well, such as when --enable-version-specific-runtime-libs is enabled.  A better way to retrieve the compiler version is to use GCC's -dumpversion argument, which works with Apple's GCC 3.3, 4.0.1 and 4.2.1 and doesn't need additional grepping/cutting, etc.

The attached patch uses -dumpversion to retrieve the GCC version, which allows a successful configure run.

----------
components: Build
files: python-2.5.1-darwin-gcc-version.patch
keywords: patch
messages: 97883
nosy: grobian
severity: normal
status: open
title: configure GCC version detection fix for Darwin
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15911/python-2.5.1-darwin-gcc-version.patch

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

From report at bugs.python.org  Sat Jan 16 17:33:48 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 16:33:48 +0000
Subject: [New-bugs-announce] [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

Configure will die on Darwin with the message

Unexpected output of 'arch' on OSX

when GNU arch is in use.  The following patch simply adds the output as given by GNU arch to allow a successful configure run.

----------
components: Build
files: python-2.6.4-gnu-arch-darwin.patch
keywords: patch
messages: 97884
nosy: grobian
severity: normal
status: open
title: Allow use of GNU arch on Darwin
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15912/python-2.6.4-gnu-arch-darwin.patch

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

From report at bugs.python.org  Sat Jan 16 19:25:01 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 18:25:01 +0000
Subject: [New-bugs-announce] [issue7716] IPv6 detection,
	don't assume existence of /usr/xpg4/bin/grep
In-Reply-To: <1263666299.94.0.843434843075.issue7716@psf.upfronthosting.co.za>
Message-ID: <1263666299.94.0.843434843075.issue7716@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

The solaris case implementation of the ipv6 check assumes /usr/xpg4/bin/grep is available.  This gives error messages on e.g. IRIX where /etc/netconfig is available, but no /usr/xpg4/bin/grep.  This is simply fixed by using $GREP which is set by configure, and will be set to /usr/xpkg4/bin/grep if no suitable grep was found in the path.

Attached patch incorporates this change.

----------
files: python-2.5.1-no-hardcoded-grep.patch
keywords: patch
messages: 97892
nosy: grobian
severity: normal
status: open
title: IPv6 detection, don't assume existence of /usr/xpg4/bin/grep
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15913/python-2.5.1-no-hardcoded-grep.patch

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

From report at bugs.python.org  Sat Jan 16 20:03:54 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:03:54 +0000
Subject: [New-bugs-announce] [issue7717] Compilation fixes for IRIX
In-Reply-To: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>
Message-ID: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

Patches to fix compilation issues on IRIX, on behalf of Frank Everdij and Stuart Shelton.

----------
components: Build
files: python-2.7-irix.patch
keywords: patch
messages: 97896
nosy: grobian
severity: normal
status: open
title: Compilation fixes for IRIX
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15915/python-2.7-irix.patch

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

From report at bugs.python.org  Sat Jan 16 20:07:10 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:07:10 +0000
Subject: [New-bugs-announce] [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

Create a libpythonX.Y.so library on IRIX.  Patch on behalf of Stuart Shelton.

----------
components: Build
files: python-2.6-irix-libpython2.6.patch
keywords: patch
messages: 97897
nosy: grobian
severity: normal
status: open
title: Build shared libpythonX.Y.so on IRIX
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15917/python-2.6-irix-libpython2.6.patch

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

From report at bugs.python.org  Sat Jan 16 20:16:45 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:16:45 +0000
Subject: [New-bugs-announce] [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>


New submission from Fabian Groffen <grobian at gentoo.org>:

NFS on certain platforms (most notably AIX, Solaris) use .nfsXXXXX files that appear and disappear automagically.  distutils can get confused by that once a .nfsXXXXX file was earlier seen with listdir and then removed by the OS before its copied.

Simply ignore .nfsXXXXX files as workaround.

----------
assignee: tarek
components: Distutils
files: python-2.5.1-distutils-aixnfs.patch
keywords: patch
messages: 97898
nosy: grobian, tarek
severity: normal
status: open
title: distutils: ignore .nfsXXXX files
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file15918/python-2.5.1-distutils-aixnfs.patch

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

From report at bugs.python.org  Sat Jan 16 22:46:01 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 16 Jan 2010 21:46:01 +0000
Subject: [New-bugs-announce] [issue7720] Errors in tests and C
	implementation of raw FileIO
In-Reply-To: <1263678361.41.0.947080196973.issue7720@psf.upfronthosting.co.za>
Message-ID: <1263678361.41.0.947080196973.issue7720@psf.upfronthosting.co.za>


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

My own fileio implementation fails against the latests versions of the io test suite, under python2.6, because these now require FileIO objects to accept unicode strings in their write methods, whereas the doc mentions raw streams only deal with bytes/bytearrays.

Below is the faulty test (unicode literals or ON). The unicode "xxx" is written to the io.FileIO instance, and the stdlib implementation indeed accepts unicode args (in _fileio.c : "if (!PyArg_ParseTuple(args, "s*", &pbuf)...").

In test_io.py :

   def test_destructor(self):
        record = []
        class MyFileIO(io.FileIO):
            def __del__(self):
                record.append(1)
                io.FileIO.__del__(self)
            def close(self):
                record.append(2)
                io.FileIO.close(self)
            def flush(self):
                record.append(3)
                io.FileIO.flush(self)
        f = MyFileIO(test_support.TESTFN, "w")
        f.write("xxx")
        del f
        self.assertEqual(record, [1, 2, 3])

----------
components: IO
messages: 97910
nosy: pakal
severity: normal
status: open
title: Errors in tests and C implementation of raw FileIO
versions: Python 2.6

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

From report at bugs.python.org  Sat Jan 16 22:56:02 2010
From: report at bugs.python.org (Martin Manns)
Date: Sat, 16 Jan 2010 21:56:02 +0000
Subject: [New-bugs-announce] [issue7721] Code in xrange documentation does
	not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>


New submission from Martin Manns <mmanns at gmx.net>:

In the Python 2.6.4 documentation "2. Built-in Functions" at
http://docs.python.org/library/functions.html,
the section about the xrange function (paragraph "CPython implementation detail") contains the following code:

islice(count(start, step), (stop-start+step-1)//step)

However, count only accepts one parameter, so that this solution does
not work. Furthermore, islice only accepts positive values for step.

Therefore, the code does not work.

I tested this with Python 2.5.4 and Python 2.6.4 on Debian Linux (AMD64).

----------
assignee: georg.brandl
components: Documentation
messages: 97912
nosy: georg.brandl, mm
severity: normal
status: open
title: Code in xrange documentation does not work
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sun Jan 17 04:35:27 2010
From: report at bugs.python.org (Bill Thiede)
Date: Sun, 17 Jan 2010 03:35:27 +0000
Subject: [New-bugs-announce] [issue7722] calendar.{HTMLCalendar,
	TextCalendar}.formatyear have incorrect definition
In-Reply-To: <1263699327.27.0.112532747824.issue7722@psf.upfronthosting.co.za>
Message-ID: <1263699327.27.0.112532747824.issue7722@psf.upfronthosting.co.za>


New submission from Bill Thiede <couchmoney at gmail.com>:

The documentation for both HTMLCalendar and TextCalendar from the calendar module have formatyear defined as:

TextCalendar.formatyear(theyear, themonth[, w[, l[, c[, m]]]])

and 

HTMLCalendar. formatyear(theyear, themonth[, width])

However the function definitions are actually:

TextCalendar.formatyear(self, theyear, w=2, l=1, c=6, m=3)

and 

HTMLCalendar.formatyear(self, theyear, width=3)

There is no 'themonth' parameter in either.  I wouldn't be surprised if this was a cut-n-paste error from the 'formatmonth' variants.

----------
assignee: georg.brandl
components: Documentation
messages: 97931
nosy: georg.brandl, wathiede
severity: normal
status: open
title: calendar.{HTMLCalendar,TextCalendar}.formatyear have incorrect definition
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan 17 14:45:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 13:45:53 +0000
Subject: [New-bugs-announce] [issue7723] sqlite only accept buffer() for
	BLOB objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Since buffer() is deprecated in Python 2.7, it should not be used for BLOB input/output.


SAMPLES = (
  ('unicode', u''),
  ('bytes', ''),
  ('buffer', buffer('')),
# ('bytearray', bytearray('')),     # unsupported
# ('memoryview', memoryview(''))    # unsupported
)

import sqlite3
conn = sqlite3.connect(':memory:')
c = conn.cursor()
c.execute('create table test(s varchar, b blob)')
c.executemany('insert into test(s, b) values (?, ?)', SAMPLES)
c.execute('select s, b from test')
print('\n'.join(str(l) for l in c.fetchall()))

# Output:
# (u'unicode', u'')
# (u'bytes', u'')
# (u'buffer', <read-write buffer ptr 0x1d8ccd0, size 0 at 0x1d8cc80>)
#
# Errors and warnings:
# __main__:4: DeprecationWarning: buffer() not supported in 3.x
# sqlite3.InterfaceError: Error binding parameter 1 - probably unsupported type.


Here is the Python 3 input/output:

SAMPLES = (  # Python3
  ('unicode', ''),
  ('bytes', b''),
  ('bytearray', bytearray(b'')),
  ('memoryview', memoryview(b''))
)

# ('unicode',     '')
# ('bytes',      b'')
# ('bytearray',  b'')
# ('memoryview', b'')

----------
components: Extension Modules
messages: 97943
nosy: flox
priority: high
severity: normal
status: open
title: sqlite only accept buffer() for BLOB objects (input/output)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 17 16:06:13 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 15:06:13 +0000
Subject: [New-bugs-announce] [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>


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

On OSX it is possible to compile using an SDK, which is basicly a directory tree containing include files and shared library stubs. When building using an SDK (such as the 10.4u SDK) the compiler looks in the SDK subtree instead of / (that is, look for include files in $SDKROOT/usr/include instead of /usr/include, and simularly for other locations).

Python's setup.py should do the same thing when performing build-time tests, such as looking for header files or libraries.

BTW. I'm planning to work on a patch for this, the issue is mostly here to remind me that something needs to be done.

----------
assignee: ronaldoussoren
components: Build, Macintosh
messages: 97949
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: setup.py ignores SDK root on OSX
type: compile error
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jan 17 17:45:10 2010
From: report at bugs.python.org (dauerbaustelle)
Date: Sun, 17 Jan 2010 16:45:10 +0000
Subject: [New-bugs-announce] [issue7725] '-s' option in The Python Profiles
	> Instant User's	Manual linked incorrectly
In-Reply-To: <1263746710.06.0.0136432817301.issue7725@psf.upfronthosting.co.za>
Message-ID: <1263746710.06.0.0136432817301.issue7725@psf.upfronthosting.co.za>


New submission from dauerbaustelle <jonas at lophus.org>:

[Section 27.4.2] The '-s' option links to the `cmdline` manual rather than to the `profile.Stats` documentation.

(rst source line 125)

----------
assignee: georg.brandl
components: Documentation
messages: 97956
nosy: dauerbaustelle, georg.brandl
severity: normal
status: open
title: '-s' option in The Python Profiles > Instant User's Manual linked incorrectly
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan 17 18:13:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 17 Jan 2010 17:13:17 +0000
Subject: [New-bugs-announce] [issue7726] Remove required metadata warnings
	for sdist
In-Reply-To: <1263748397.28.0.736883943174.issue7726@psf.upfronthosting.co.za>
Message-ID: <1263748397.28.0.736883943174.issue7726@psf.upfronthosting.co.za>


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

When building releases with sdist (and other distribution building options) missing metadata should not cause warnings. For public projects this is useful (i.e. projects uploaded to PyPI), but not for internally built distributions. (If a distribution is not public then why should it have a URL for example.)

----------
assignee: tarek
components: Distutils
messages: 97957
nosy: michael.foord, tarek
severity: normal
status: open
title: Remove required metadata warnings for sdist
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jan 17 20:59:28 2010
From: report at bugs.python.org (Steven Hartland)
Date: Sun, 17 Jan 2010 19:59:28 +0000
Subject: [New-bugs-announce] [issue7727] xmlrpc library returns string which
	contain null ( \x00 )
In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>
Message-ID: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>


New submission from Steven Hartland <steven.hartland at multiplay.co.uk>:

When using SimpleXMLRPCServer that is used to return data that includes strings that have a \x00 in them this data is returned, which is invalid.

The expected result is that the data should be treated as binary and base64 encoded.

The bug appears to be in the core xmlrpc library which relies on type( value ) to determine the data type. This returns str for a string even if it includes the null char.

----------
components: XML
messages: 97972
nosy: Steven.Hartland
severity: normal
status: open
title: xmlrpc library returns string which contain null ( \x00 )
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan 17 22:27:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 21:27:39 +0000
Subject: [New-bugs-announce] [issue7728] test_timeout should use
	"find_unused_port" helper
In-Reply-To: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>
Message-ID: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Some buildbot failure because of hard-coded port.

test_timeout
test test_timeout failed -- Traceback (most recent call last):
  File "/home/buildbot/cpython-ucs2/trunk.pitrou-ubuntu/build/Lib/test/test_timeout.py", line 149, in testAcceptTimeout
    self.sock.bind(self.addr_local)
  File "/home/buildbot/cpython-ucs2/trunk.pitrou-ubuntu/build/Lib/socket.py", line 222, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 98] Address already in use

----------
components: Tests
keywords: buildbot
messages: 97975
nosy: flox, pitrou
severity: normal
stage: needs patch
status: open
title: test_timeout should use "find_unused_port" helper
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jan 18 09:34:39 2010
From: report at bugs.python.org (Umit Oztosun)
Date: Mon, 18 Jan 2010 08:34:39 +0000
Subject: [New-bugs-announce] [issue7729] min() working incorrectly for
	decimal and float values
In-Reply-To: <1263803679.58.0.0245965950297.issue7729@psf.upfronthosting.co.za>
Message-ID: <1263803679.58.0.0245965950297.issue7729@psf.upfronthosting.co.za>


New submission from Umit Oztosun <umit.oztosun at gmail.com>:

On MacOSX (10.5) Intel, Python 2.6.4

>>> from decimal import Decimal
>>> min(Decimal('3.0'), 10.2)
10.199999999999999

On Win32, Python 2.6.4

>>> from decimal import Decimal
>>> min(Decimal('3.0'), 10.2)
Decimal('3.0')

On Linux 32 bit, Python 2.6.4

>>> from decimal import Decimal
>>> min(Decimal('3.0'), 10.2)
10.199999999999999

However, the correct result of Win32 version seems completely coincidental, it produces invalid results for other values:

>>> min(Decimal('12.0'), 10.2)
Decimal('12.0')

We are already aware of problems related to float and Decimal comparison, but in this case it complicates matters worse: On Windows code seems to work OK, on other platforms its results are wrong; worse than this, Windows version works totally by coincidence in fact.

It should at least warn user or raise an error IMHO.

----------
components: Library (Lib)
messages: 97991
nosy: Umit.Oztosun
severity: normal
status: open
title: min() working incorrectly for decimal and float values
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 18 09:50:09 2010
From: report at bugs.python.org (djc)
Date: Mon, 18 Jan 2010 08:50:09 +0000
Subject: [New-bugs-announce] [issue7730] ssl has bad coding style
In-Reply-To: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>
Message-ID: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

Sorry to be nitpicking here, but it kind of sticks out when you take your first look at ssl.py. While PEP 8 only talks about whitespace before the function call argument list parenthesis, I think this should also go for function definition. ssl has a lot of definitions like this:

    def send (self, data, flags=0):

(But not all of them.) Maybe that should be fixed up (I can do it myself, if that's alright), and maybe PEP 8 should be clarified as well?

----------
components: Library (Lib)
messages: 97993
nosy: djc, janssen
severity: normal
status: open
title: ssl has bad coding style
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 18 12:22:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Jan 2010 11:22:36 +0000
Subject: [New-bugs-announce] [issue7731] Search is sluggish
In-Reply-To: <1263813756.21.0.177298019547.issue7731@psf.upfronthosting.co.za>
Message-ID: <1263813756.21.0.177298019547.issue7731@psf.upfronthosting.co.za>


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

docs.python.org site search is sluggish or may seem not working at all.

The reason is that before search starts, it requires a 800k+ index file to be loaded http://docs.python.org/searchindex.js

This file is usually cached. You might not notice sluggishness if it was cached when you loaded search page and were typing search query, but when you redirected to search page with get parameters the search is assumed to be started immediately. Unfortunately, JS execution delayed until index is loaded. Time controls are not updated, there is no indication what is going on and search may appear broken. User then clicks search button again and index starts loading anew.

The solution is to load index dynamically after first search request is made.

Attached patch is not tested with real server.

----------
assignee: georg.brandl
components: Documentation
files: doctools_search_response_speedup.diff
keywords: patch
messages: 98002
nosy: georg.brandl, techtonik
severity: normal
status: open
title: Search is sluggish
Added file: http://bugs.python.org/file15935/doctools_search_response_speedup.diff

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

From report at bugs.python.org  Mon Jan 18 13:07:06 2010
From: report at bugs.python.org (Trundle)
Date: Mon, 18 Jan 2010 12:07:06 +0000
Subject: [New-bugs-announce] [issue7732] imp.find_module crashes Python if
	there exists a	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>


New submission from Trundle <andy-python at hammerhartes.de>:

Create a directory "__init__.py" and execute

>>> import imp
>>> imp.find_module('__init__', ['.'])

to reproduce that issue. It will crash because Python tries to double-close a file pointer: `call_find_module` will call `PyFile_FromFile`, but `PyFile_FromFile` closes the file pointer if it's a directory (by decrefing the created file object) and ` call_find_module` then closes the already closed file.

----------
components: Library (Lib)
messages: 98007
nosy: Trundle
severity: normal
status: open
title: imp.find_module crashes Python if there exists a directory named "__init__.py"
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 18 13:32:36 2010
From: report at bugs.python.org (djc)
Date: Mon, 18 Jan 2010 12:32:36 +0000
Subject: [New-bugs-announce] [issue7733] asyncore docs reference is unclear
In-Reply-To: <1263817956.14.0.104959185051.issue7733@psf.upfronthosting.co.za>
Message-ID: <1263817956.14.0.104959185051.issue7733@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

http://docs.python.org/library/asyncore.html has this bit (for bind()):

    (The format of address depends on the address family ? see above.)

The only way this makes sense is if it points back to the "family" argument used in the create_socket() documentation, but even there the term "family" isn't actually used in the description, and it's unclear that the reference to the socket module documentation "for information on creating sockets" will have more information about the address constraints for bind(). It would probably be better if the bind() description referred to the socket documentation directly.

----------
assignee: georg.brandl
components: Documentation
messages: 98008
nosy: djc, georg.brandl
severity: normal
status: open
title: asyncore docs reference is unclear
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 18 23:07:47 2010
From: report at bugs.python.org (Joshua Bronson)
Date: Mon, 18 Jan 2010 22:07:47 +0000
Subject: [New-bugs-announce] [issue7734] discuss mark-as-invalid trick in
	heapq docs
In-Reply-To: <1263852467.57.0.690062730163.issue7734@psf.upfronthosting.co.za>
Message-ID: <1263852467.57.0.690062730163.issue7734@psf.upfronthosting.co.za>


New submission from Joshua Bronson <jabronson at gmail.com>:

Though the heapq module does not support changing the priority of a particular element of the heap (a necessary operation for the A* search family of algorithms), such an element can be marked as invalid and a new element can be added with different priority. Any element marked as invalid that makes it to the top of the heap can simply be popped off and ignored.

Users who haven't seen this trick before might mistakenly think the heapq module does not provide sufficient operations to implement A* search.

Please see the recent thread on comp.lang.python for more background:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/8adc3ce8d2219647

----------
assignee: georg.brandl
components: Documentation
messages: 98034
nosy: georg.brandl, jab, rhettinger
severity: normal
status: open
title: discuss mark-as-invalid trick in heapq docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jan 18 23:51:39 2010
From: report at bugs.python.org (Evan Teran)
Date: Mon, 18 Jan 2010 22:51:39 +0000
Subject: [New-bugs-announce] [issue7735] python creates IPv6 DNS requests
	even when built with	--disable-ipv6
In-Reply-To: <1263855099.58.0.477702556639.issue7735@psf.upfronthosting.co.za>
Message-ID: <1263855099.58.0.477702556639.issue7735@psf.upfronthosting.co.za>


New submission from Evan Teran <evan.teran at gmail.com>:

I have encountered an issue where python will do a AAAA request even when built without IPv6. This becomes an issue because on some configurations this seems to cause a 5 second delay on DNS lookups (that is a separate issue of course). Basically here is what I am seeing:

#!/usr/bin/python
import urllib2
print urllib2.urlopen('http://python.org/').read(100)

results in the following:

0.000000  10.102.0.79 -> 8.8.8.8      DNS Standard query A python.org
  0.000023  10.102.0.79 -> 8.8.8.8      DNS Standard query AAAA python.org
  0.005369      8.8.8.8 -> 10.102.0.79  DNS Standard query response A 82.94.164.162
  5.004494  10.102.0.79 -> 8.8.8.8      DNS Standard query A python.org
  5.010540      8.8.8.8 -> 10.102.0.79  DNS Standard query response A 82.94.164.162
  5.010599  10.102.0.79 -> 8.8.8.8      DNS Standard query AAAA python.org
  5.015832      8.8.8.8 -> 10.102.0.79  DNS Standard query response AAAA 2001:888:2000:d::a2

looking at socket.py in create_connection() (line 500 on my python 2.6.4 stdlib) the code is like this:

    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
        af, socktype, proto, canonname, sa = res
        sock = None
        try:
            sock = socket(af, socktype, proto)
            if timeout is not _GLOBAL_DEFAULT_TIMEOUT:
                sock.settimeout(timeout)
            sock.connect(sa)
            return sock

        except error, msg:
            if sock is not None:
                sock.close()

The 3rd argument is the socket type, which is set to 0 which apparently means unspecified. It seems to me that if python is built without IPv6 support it should instead pass AF_INET since even if it does get an IPv6 response it can't possibly use it.

----------
components: None
messages: 98036
nosy: Evan.Teran
severity: normal
status: open
title: python creates IPv6 DNS requests even when built with --disable-ipv6
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jan 19 00:24:11 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:24:11 +0000
Subject: [New-bugs-announce] [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

The following is a very subtle bug and it took me a couple of days to reduce it to a manageable test case. So please bear with me even if it's tedious.

The problem is that in some cases the use of ctypes for a callback function freezes the entire process. Even 'gdb -p' freezes when trying to attach to the affected PID. The process can not be killed with SIGTERM.

Please consider the attached example. It needs the fuse headers installed to work (package libfuse-dev under Debian).

Step 1: Compile hello_ll.c with   

gcc -Wall -g3 -O0 -fPIC `pkg-config fuse --cflags` -c hello_ll.c
gcc -Wall -g3 -O0 -shared `pkg-config fuse --libs` -o hello_ll.so hello_ll.o

into a shared library. The do_mount() function will be called with ctypes from call_hello.py.

Step 2: In call_hello.py you need to adjust the import of libfuse to match your installed FUSE version (2.6 or 2.8). The libfuse2{6,8}.py files have been autogenerated with ctypeslib. I can provide versions for other FUSE versions as well if necessary. Note that the problem is most likely not with the definitions in this file, I checked all of them carefully by hand.


Step 3: Create an empty directory 'mnt' in the working directory

Step 4: Run call_hello.py. It will mount a simple example FUSE file system in mnt, read the directory, umount the fs and exit.

Step 5: Uncomment line 36 of call_hello.py. This will substitute the C function hello_ll_opendir() (defined in hello_ll.c) by the Python function fuse_opendir(). Note that both functions do exactly the same thing, they just call the fuse function fuse_reply_err.

Step 6: Run call_hello.py again. The program will hang completely. You can salvage the mount point with "fusermount -u -z mnt".

Step 7: Comment out line 47 in call_hello.py, so that the process itself does not try to access the mountpoint anymore.

Step 8: Run call_hello.py again. Observe that the file system mounts and umounts fine. Accessing the mountpoint with a different process does not trigger the freeze either.


In summary, the process hangs only if:

1) The opendir function is implemented as a ctypes callback

and

2) the mounting process itself tries to access the mountpoint


I suspect that the ctypes callback may somehow deadlock with the thread that tries to access the mountpoint.

If someone can tell me how to get around the hanging gdb process, i'll be happy to provide a backtrace. I have already installed debugging symbols for both Python and libfuse.


Thank you for taking the time to read up to this point :-)

----------
assignee: theller
components: ctypes
messages: 98038
nosy: Nikratio, theller
severity: normal
status: open
title: ctypes freezes/deadlocks process
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 19 00:24:48 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 18 Jan 2010 23:24:48 +0000
Subject: [New-bugs-announce] [issue7737] Patch all tests to change
	assertTrue(a [not] in b [, c]) -> assert[Not]In(a, b [, c])
In-Reply-To: <1263857088.57.0.971642204628.issue7737@psf.upfronthosting.co.za>
Message-ID: <1263857088.57.0.971642204628.issue7737@psf.upfronthosting.co.za>


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

In many places throughout the existing test suite, there are assertions of the form:
     self.assertTrue(chips in menu)
and of the form:
     self.assertTrue(cheese not in shop)

If these fail, the error message will merely tell you that the condition failed, without telling you the values.

Some of these tests have an additional handcoded "msg" argument.

The attached patch (to the py3k branch) changes all of these assertions to use the assertIn and assertNotIn methods: when these fail, the log will indicate the repr() of the left- and right- hand sides.

If a "msg" argument was provided which isn't the left or right-hand side, I supply that as a third argument (which these methods can also accept).

I generated this patch using this pair of shell commands:

# Fixup "not in":
find Lib/test -name test_\*.py \
    | xargs sed --in-place -r -e "s|self.assertTrue\((.*) not in (.*)\)|self.assertNotIn(\1, \2)|g"

# Fixup "in":
find Lib/test -name test_\*.py \
    | xargs sed --in-place -r -e "s|self.assertTrue\((.*) in (.*)\)|self.assertIn(\1, \2)|g"

and then manually fixing the tests until they worked (the above isn't perfect, but was close enough, if I had to do it again I'd write a python script).

I edited some of the basic tests for collections that verify in/not-in semantics, so that both forms of test are present (using the assertIn variant first, to provide better logs in the event of failure.  I'm not sure that doing so is meaningful though (assertIn does a "member not in container", and assertNotIn does a "member in container" test).

I've rerun the test on my local build, and verified the code visually (however the patch is rather large so I may have missed something):
  75 files changed, 471 insertions(+), 454 deletions(-)

(suggested by http://bugs.python.org/msg97856 )

----------
components: Tests
files: py3k-use-assertIn-and-NotIn-in-tests.patch
keywords: patch
messages: 98039
nosy: dmalcolm
severity: normal
status: open
title: Patch all tests to change assertTrue(a [not] in b [, c]) -> assert[Not]In(a, b [,c])
versions: Python 3.2
Added file: http://bugs.python.org/file15942/py3k-use-assertIn-and-NotIn-in-tests.patch

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

From report at bugs.python.org  Tue Jan 19 09:30:33 2010
From: report at bugs.python.org (Kent Yip)
Date: Tue, 19 Jan 2010 08:30:33 +0000
Subject: [New-bugs-announce] [issue7738] IDLE hang when tooltip comes up in
	Linux
In-Reply-To: <1263889833.11.0.812168606755.issue7738@psf.upfronthosting.co.za>
Message-ID: <1263889833.11.0.812168606755.issue7738@psf.upfronthosting.co.za>


New submission from Kent Yip <yesk13 at gmail.com>:

IDLE will hang when a tooltip shows in a Linux system (Ubuntu).

do this:

t = (1,2,3)
len(t)

it will hang after the closing ')', when you press return nothing will happen or when you press any keys, it won't show up. 

However, you can work around this hangup by clicking on the IDLE menus on top or clicking on a different application on your desktop and return to IDLE and press Enter will work again

tested on python2.5, python2.6, python3.0 on linux machine 

however in windows vista with python3.1 the tooltip hangup doesn't exist. Only in Linux does it behave like that.

----------
components: IDLE
messages: 98048
nosy: yesk13
severity: normal
status: open
title: IDLE hang when tooltip comes up in Linux
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Jan 19 10:23:56 2010
From: report at bugs.python.org (Doron Tal)
Date: Tue, 19 Jan 2010 09:23:56 +0000
Subject: [New-bugs-announce] [issue7739] time.strftime may hung while trying
	to open	/etc/localtime but does not release GIL
In-Reply-To: <1263893036.59.0.158350465414.issue7739@psf.upfronthosting.co.za>
Message-ID: <1263893036.59.0.158350465414.issue7739@psf.upfronthosting.co.za>


New submission from Doron Tal <doron.tal.list at gmail.com>:

I've encountered a hung of python process for more than a second. It appears that the stall happens due to time.strftime call, which internally opens a file ('/etc/localtime'). I think it is best if the GIL would have been released to allow other threads to continue working.

Snippet from strace on:
-----------------------
import time
time.strftime('%Z')
-----------------------
Note the line:
open("/etc/localtime", O_RDONLY)        = 4


----=== strace output Starts here  ===---
stat("/usr/local/lib/python2.6/lib-old/time", 0x7fff871deff0) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.6/lib-old/time.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.6/lib-old/timemodule.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.6/lib-old/time.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.6/lib-old/time.pyc", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib/python2.6/lib-dynload/time", 0x7fff871deff0) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/python2.6/lib-dynload/time.so", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=46995, ...}) = 0
futex(0x393b4030ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/local/lib/python2.6/lib-dynload/time.so", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\30\0\0\0\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=46995, ...}) = 0
mmap(NULL, 2115944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x2adf26fba000
mprotect(0x2adf26fbd000, 2097152, PROT_NONE) = 0
mmap(0x2adf271bd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x3000) = 0x2adf271bd000
close(4)                                = 0
time(NULL)                              = 1263890749
open("/etc/localtime", O_RDONLY)        = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2adf271bf000
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 2197
lseek(4, -1394, SEEK_CUR)               = 803
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 1394
close(4)                                = 0
munmap(0x2adf271bf000, 4096)            = 0
close(3)                                = 0
time(NULL)                              = 1263890749
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2197, ...}) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x393b60e930}, {0x4c4730, [], SA_RESTORER, 0x393b60e930}, 8) = 0
exit_group(0)                           = ?

----------
messages: 98049
nosy: dorontal
severity: normal
status: open
title: time.strftime may hung while trying to open /etc/localtime but does not release GIL
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 19 14:34:55 2010
From: report at bugs.python.org (Gerald Thaler)
Date: Tue, 19 Jan 2010 13:34:55 +0000
Subject: [New-bugs-announce] [issue7740] Complete your registration to
	Jython tracker --	key9LzwsWHYNjTaULhZpojHxtdciVg1jFYL
In-Reply-To: <20100119122315.22FE77864A@psf.upfronthosting.co.za>
Message-ID: <9E28BD5504484D83BF8DA815A470AFFA@GeraldPC>


New submission from Gerald Thaler <gerald at netestate.de>:

----- Original Message ----- 
From: "Jython tracker" <report at bugs.jython.org>
To: <gerald at netestate.de>
Sent: Tuesday, January 19, 2010 1:23 PM
Subject: Complete your registration to Jython tracker --  
key9LzwsWHYNjTaULhZpojHxtdciVg1jFYL

To complete your registration of the user "geraldth" with
Jython tracker, please do one of the following:

- send a reply to report at bugs.jython.org and maintain the subject line as is 
(the
reply's additional "Re:" is ok),

- or visit the following URL:

http://bugs.jython.org/?@action=confrego&otk=9LzwsWHYNjTaULhZpojHxtdciVg1jFYL

----------
messages: 98052
nosy: gthaler
severity: normal
status: open
title: Complete your registration to Jython tracker -- key9LzwsWHYNjTaULhZpojHxtdciVg1jFYL

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

From report at bugs.python.org  Tue Jan 19 15:52:03 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 19 Jan 2010 14:52:03 +0000
Subject: [New-bugs-announce] [issue7741] Allow multiple statements in
	code.InteractiveConsole.push
In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za>
Message-ID: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za>


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

The code.InteractiveConsole() is useful to emulate a python console.  However, any code currently "push"ed to it must be single statements.  This is because it passes the ?single? symbol mode to the underlying compile function.
This patch allows the caller of InteractiveConsole.push to specify a different mode, e.g. ?exec?.  This is useful if one wants to paste entire code snippets into the console.  Without it, pasting the following:
'if True:\n  print 1\nprint 2' Won't run.  pushing such multiline code snippets with an additional 'exec' argument will allow it to work.
Patch included.

----------
components: Library (Lib)
files: code.patch
keywords: patch
messages: 98056
nosy: krisvale
severity: normal
status: open
title: Allow multiple statements in code.InteractiveConsole.push
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15950/code.patch

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

From report at bugs.python.org  Tue Jan 19 23:15:51 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Tue, 19 Jan 2010 22:15:51 +0000
Subject: [New-bugs-announce] [issue7742] please avoid 'which' in
	Modules/ld_so_aix
In-Reply-To: <1263939351.94.0.865840686982.issue7742@psf.upfronthosting.co.za>
Message-ID: <1263939351.94.0.865840686982.issue7742@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner <michael.haubenwallner at salomon.at>:

In Modules/ld_so_aix there is `which $CC` to search for the full compiler's path.

Unfortunately, /usr/bin/which on AIX is a csh-script and thus ~/.cshrc gets sourced before doing the path search.

Now, when the user does set some PATH in ~/.cshrc, `which` might print a wrong path for the compiler, causing the build to fail (at best).

It would be better to do the path search without launching an external program.

----------
files: ld_so_aix-which.patch
keywords: patch
messages: 98070
nosy: haubi
severity: normal
status: open
title: please avoid 'which' in Modules/ld_so_aix
versions: Python 3.2
Added file: http://bugs.python.org/file15955/ld_so_aix-which.patch

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

From report at bugs.python.org  Wed Jan 20 14:12:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2010 13:12:20 +0000
Subject: [New-bugs-announce] [issue7743] Additional potential string ->
	float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>


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

1. Another potential crash caused by Python/dtoa.c:  if the bigcomp functionality is disabled by replacing "#define STRTOD_DIGLIM 40" with "#define STRTOD_DIGLIM 4000", then the following string causes a crash:

>>> s = '5254406533529552661096610603582028195612589849649138922565278497589560452182570597137658742514361936194432482059988700016338656575174473559922258529459120166686600002102838072098506622244175047522649953606315120077538558010753730576321577387528008403025962370502479105305382500086822727836607781816280407336531214924364088126680234780012085291903592543223403975751852488447885154107229587846409265285440430901153525136408849880173424692750069991045196209464308187671479664954854065777039726878381767789934729895619590000470366389383963331466851379030183764964083197053338684769252973171365139701890736933147103189912528110505014483268752328506004517760913030437151571912928276140468769502257147431182910347804663250851413437345649151934269945872064326973371182115272789687312946393533547747886024677951678751174816604738791256853675690543663283782215866825e-1180'
[38199 refs]
>>> float(s)
cmp called with a->x[a->wds-1] == 0

I haven't yet found any examples that cause this crash without bigcomp enabled.

The crash is caused by a combination of two problems. (1) there's a buggy check for the smallest denormal in the "if ((aadj = ratio(delta, bs)) <= 2.) {" block in _Py_dg_strtod:  the check ignores the possibility that bc.scale is nonzero.  (2) The Bigint functions don't deal well with zero inputs:  in particular, d2b gives strange results, and left shifting a zero Bigint can give a non-normalized result.

2. The check:

            if (!(word1(&rv) & LSB))
                break;

in _Py_dg_strtod again doesn't take into account the possibility that bc->scale is nonzero.  It's supposed to be used in exact halfway cases to determine whether the current rv is already 'even' for the purposes of round-half-to-even.  But for subnormal scaled rv, this check will (wrongly) always succeed, potentially giving an incorrectly rounded result.

However, it seems to be difficult to trigger this bug:  the input must be a subnormal exact halfway case, which implies it must have many hundred digits.  On the first pass through the strtod correction loop, the approximation is likely to be out by a few ulps, so we almost never hit the (i == 0) branch.  The adjustment for the second pass then typically gives *exactly* the right result, as a consequence of the floating-point addition using round-half-to-even.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 98080
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Additional potential string -> float conversion issues.
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jan 20 21:19:23 2010
From: report at bugs.python.org (Chris Lasher)
Date: Wed, 20 Jan 2010 20:19:23 +0000
Subject: [New-bugs-announce] [issue7744] Allow site.addsitedir insert to
	beginning of sys.path
In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za>
Message-ID: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za>


New submission from Chris Lasher <chris.lasher at gmail.com>:

Would it be possible to add an extra option to site.addsitedir so that it left-appends (inserts at the beginning of the list rather than the end of the list) to sys.path the new path?

The use case for this is that sometimes the user has local versions of packages and modules they would prefer to use over versions installed system-wide. Since Python searches for packages and modules in the order given by sys.path, inserting the new path(s) at the beginning of sys.path. This leads to hack-ish work-arounds, such as the one given by http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

If there was an option to left-append with site.addsitedir, it would really help in cases such as these.

Note that I'm not certain at the moment how best to add additional paths that are found in .pth files, i.e., whether to insert them at the beginning as well, or insert them between the initial path and the original paths (the paths that existed before site.addsitedir is called).

----------
components: Library (Lib)
messages: 98084
nosy: gotgenes
severity: normal
status: open
title: Allow site.addsitedir insert to beginning of sys.path
type: feature request

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

From report at bugs.python.org  Thu Jan 21 00:04:10 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 20 Jan 2010 23:04:10 +0000
Subject: [New-bugs-announce] [issue7745] Remove "isatty" check when setting
	sys.std[in|out|err]	encoding to that of locale
In-Reply-To: <1264028650.99.0.196256865676.issue7745@psf.upfronthosting.co.za>
Message-ID: <1264028650.99.0.196256865676.issue7745@psf.upfronthosting.co.za>


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

Currently sys.std[in|out|err] are set to the locale encoding but only if they are directly connected to a tty (and PYTHONIOENCODING is not set in the environment to override things).

The conditionality on "isatty" leads to lots of unexpected changes when scripts are added to shell pipelines, or run from cronjobs.

For example:
[david at brick ~]$ python -c 'print u"\u03b1\u03b2\u03b3"'
???

[david at brick ~]$ python -c 'print u"\u03b1\u03b2\u03b3"' | less
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2:
ordinal not in range(128)  

("less" will respect the locale encoding).

The attached patch removes the check to see if these streams are connected to a tty, so that the encoding is always set (either to the locale value, or to the "override" value from PYTHONIOENCODING)

With this patch:
$ ./python -c 'print u"\u03b1\u03b2\u03b3"'| less

has output:
???
[17298 refs]

----------
components: Unicode
files: remove-isatty-check-from-sys-stream-encodings.patch
keywords: patch
messages: 98086
nosy: dmalcolm
severity: normal
status: open
title: Remove "isatty" check when setting sys.std[in|out|err] encoding to that of locale
versions: Python 2.7
Added file: http://bugs.python.org/file15957/remove-isatty-check-from-sys-stream-encodings.patch

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

From report at bugs.python.org  Thu Jan 21 07:01:52 2010
From: report at bugs.python.org (Justin Lebar)
Date: Thu, 21 Jan 2010 06:01:52 +0000
Subject: [New-bugs-announce] [issue7746] Nit: Extra comma in itertools doc
In-Reply-To: <1264053712.92.0.276864246454.issue7746@psf.upfronthosting.co.za>
Message-ID: <1264053712.92.0.276864246454.issue7746@psf.upfronthosting.co.za>


New submission from Justin Lebar <starwiz at gmail.com>:

At http://docs.python.org/3.1/library/itertools.html,

"For instance, SML provides a tabulation tool: tabulate(f) which produces a sequence f(0), f(1), .... But, this effect can be achieved in Python by combining map() and count() to form map(f, count())."

The second sentence should be "But this effect...", not "But, this effect".

No issue is too small, right?  :)

----------
assignee: georg.brandl
components: Documentation
messages: 98100
nosy: Justin.Lebar, georg.brandl
severity: normal
status: open
title: Nit: Extra comma in itertools doc
versions: Python 3.1

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

From report at bugs.python.org  Thu Jan 21 08:32:39 2010
From: report at bugs.python.org (Adrian May)
Date: Thu, 21 Jan 2010 07:32:39 +0000
Subject: [New-bugs-announce] [issue7747] Function variable wrongly reported
	unassigned
In-Reply-To: <1264059159.7.0.610108234991.issue7747@psf.upfronthosting.co.za>
Message-ID: <1264059159.7.0.610108234991.issue7747@psf.upfronthosting.co.za>


New submission from Adrian May <adrian.alexander.may at gmail.com>:

Hi folks,

The attached program says:

$ ./bug.py
a
None
b
Traceback (most recent call last):
  File "./bug.py", line 49, in <module>
    print number(s)
  File "./bug.py", line 34, in foo
    while eat != None:
UnboundLocalError: local variable 'eat' referenced before assignment

but I reckon it is assigned. (I haven't tried it on a newer python because the junk I want to use with python says it only works with 2.5.2.) 

Cheers, Adrian.

----------
components: Interpreter Core
files: bug.py
messages: 98101
nosy: adrianmay
severity: normal
status: open
title: Function variable wrongly reported unassigned
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file15963/bug.py

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

From report at bugs.python.org  Thu Jan 21 21:23:12 2010
From: report at bugs.python.org (dholth)
Date: Thu, 21 Jan 2010 20:23:12 +0000
Subject: [New-bugs-announce] [issue7748] unicode supported in distutils
	register but not distutils	upload
In-Reply-To: <1264105392.3.0.560672704359.issue7748@psf.upfronthosting.co.za>
Message-ID: <1264105392.3.0.560672704359.issue7748@psf.upfronthosting.co.za>


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

# -*- encoding: utf-8 -*-
# Will not 'python setup.py upload':
setup(name='acute_e', version='0.1', description=u'?')

It looks like someone fixed this for register but forgot to copy it into upload:

+        # Build up the MIME payload for the POST data
         boundary = '--------------GHSKFJDLGDS7543FJKLFHRE75642756743254'
         sep_boundary = '\n--' + boundary
         end_boundary = sep_boundary + '--'
         body = StringIO.StringIO()
         for key, value in data.items():
             # handle multiple entries for the same name
-            if type(value) not in (type([]), type( () )):
+            if type(value) != type([]):
                 value = [value]
             for value in value:
-                value = unicode(value).encode("utf-8")
+                if type(value) is tuple:
+                    fn = ';filename="%s"' % value[0]
+                    value = value[1]
+                else:
+                    fn = ""
+                value = str(value)
                 body.write(sep_boundary)
                 body.write('\nContent-Disposition: form-data; name="%s"'%key)
+                body.write(fn)
                 body.write("\n\n")
                 body.write(value)
                 if value and value[-1] == '\r':

----------
assignee: tarek
components: Distutils
messages: 98109
nosy: dholth, tarek
severity: normal
status: open
title: unicode supported in distutils register but not distutils upload
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 21 22:23:24 2010
From: report at bugs.python.org (Gib Bogle)
Date: Thu, 21 Jan 2010 21:23:24 +0000
Subject: [New-bugs-announce] [issue7749] pydoc error
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>


New submission from Gib Bogle <g.bogle at auckland.ac.nz>:

>python -m pydoc sys

gives

No module named tempfile

----------
messages: 98111
nosy: gib
severity: normal
status: open
title: pydoc error
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Jan 21 23:18:25 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 21 Jan 2010 22:18:25 +0000
Subject: [New-bugs-announce] [issue7750] IOError when launching script under
	pdb with backslash in	script path
In-Reply-To: <1264112305.65.0.888456425139.issue7750@psf.upfronthosting.co.za>
Message-ID: <1264112305.65.0.888456425139.issue7750@psf.upfronthosting.co.za>


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

Under Python 2.6.4 64-bit on Windows 7 64-bit, I found that when launching a script under the debugger, if backslashes were in the script pathname, they were not interpreted correctly by the interpreter.

For example, create a simple test script, "t-helloworld.py" with the canonical "hello-world" content. The script name must start with a backslash escape character such as 't' or 'n'. Then, from the command prompt:

> python -m pdb .\t-helloworld.py
IOError: (2, 'No such file or directory', '.\t-helloworld.py')
> <string>(1)<module>()
(Pdb)

However, using forward slashes works just fine.

> python -m pdb ./t-helloworld.py
> c:\debug\t-helloworld.py(1)<module>()
-> print "hello world"
(Pdb)

Note that launching the script from the python directly does not exhibit the error - it seems to be only when pdb is used.

Expected behavior: pdb should interpret the command-line parameters the same way Python does.

----------
components: Windows
messages: 98116
nosy: jaraco
severity: normal
status: open
title: IOError when launching script under pdb with backslash in script path
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 21 23:55:25 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 21 Jan 2010 22:55:25 +0000
Subject: [New-bugs-announce] [issue7751]
	urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno	22]
In-Reply-To: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>
Message-ID: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

On Windows 7, Python 2.6 raises an IOError when opening a valid file URL with urllib.urlopen(). A patch to the nturl2path.url2pathname function is attached. It replaces '%7C' by '|' in the url at the top of the url2pathname function.

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, urllib
>>> fname = sys.executable
>>> fname
'x:\\python26\\python.exe'
>>> fname = "file:///" + fname.replace('\\', '/').replace(':', '|')
>>> fname
'file:///x|/python26/python.exe'
>>> urllib.urlopen(fname)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "x:\python26\lib\urllib.py", line 87, in urlopen
    return opener.open(url)
  File "x:\python26\lib\urllib.py", line 206, in open
    return getattr(self, name)(url)
  File "x:\python26\lib\urllib.py", line 468, in open_file
    return self.open_local_file(url)
  File "x:\python26\lib\urllib.py", line 482, in open_local_file
    raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 22] The filename, directory name, or volume label syntax is incorrect: '\\x|\\python26\\python.exe'

----------
components: Library (Lib), Windows
files: url2pathname.patch
keywords: patch
messages: 98119
nosy: cgohlke
severity: normal
status: open
title: urllib.urlopen("///C|/foo/bar/spam.foo")  IOError: [Errno 22]
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file15965/url2pathname.patch

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

From report at bugs.python.org  Fri Jan 22 00:47:54 2010
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Thu, 21 Jan 2010 23:47:54 +0000
Subject: [New-bugs-announce] [issue7752] Add support for Digest
	authentication session (reuse	nonces)
In-Reply-To: <1264117674.74.0.518658840947.issue7752@psf.upfronthosting.co.za>
Message-ID: <1264117674.74.0.518658840947.issue7752@psf.upfronthosting.co.za>


New submission from Manuel Murad?s <mmuradas at dieresys.com.ar>:

Description:
    As described in issue [2202], for each request we make, we get a new [401|407] message with a new nonce (depending if we're talking about a proxy with digest authentication or a web server). Then we generate another authenticated request using that nonce. For Digest authentication session to be fully supported, we should be adding a [WWW|Proxy]-Authenticate header in each following request we made to the server using the last nonce sent by the server. This will reduce the amount of requests performed, improving the performance.


How common browsers behaves:
    Browsers implements authentication session by reusing the last nonce received from the web server for a given domain and Realm. When a request is made to a new URL from the same domain, the browsers doesn't know if that URL belongs to the same Realm. If the new URL is a sub-url of any other known URL on that Realm, the browsers add the Authorization header to new request. If they can't infer the Realm with this method, the Request is sent without the header. If the new URL do belongs to the Realm, the Browsers uses the nonce included in the response from the sever (with a 401 status code) to make new requests to URLs belonging to that Realm.
    Regarding proxies with Digest authentication, browsers reuse the last nonce for every request made through the proxy.

For example:
URL1 redirects to URL2 and URL2 redirects to URL3:

Notes:
-> = request
<- = response
N  = nonce
C  = client nonce
NC = nonce count

---------------------------
[1]
URL1: http://domain/1/1.htm
URL2: http://domain/2/1.htm
URL3: http://domain/1/2.htm

-> GET URL1
<- 401 N1
-> GET URL1 N1 C1 NC1
<- 301 URL2
-> GET URL2
<- 401 N2
-> GET URL2 N2 C2 NC1
<- 301 URL3
-> GET URL3 N2 C2 NC2
<- 200

---------------------------
[2]
URL1: http://domain/1.htm
URL2: http://domain/1/1.htm
URL3: http://domain/2/1.htm

-> GET URL1
<- 401 N1
-> GET URL1 N1 C1 NC1
<- 301 URL2
-> GET URL2 N1 C1 NC2
<- 301 URL3
-> GET URL3 N1 C1 NC3
<- 200


About the patch:
    I've added a 'http_request' to 'AbstractDigestAuthHandler' to add the '*-Authenticate' header before performing the requests.

    There is a known problem with this patch: we generate a new AuthenticationSession against digest proxies when we are redirected to another page (with a 30X code), instead of re-using the previous session (first we send the redirected request without the authentication handler, we receive a new 407 code, and then we send the redirected request again with the new authentication handler). This is caused because of the execution order of handlers:
- RedirectHandler generates a new request and calls to self.parent.open
- ProxyDigestAuthHandler tries to find an AuthenticationSession for that request but fails ('Request.get_host' returns the web server host)
- ProxyHandler modifies the request (now 'Request.get_host' returns the proxy host)

Comments are more than welcome!!

----------
components: Library (Lib)
files: urllib2-support_digest_sessions.diff
keywords: patch
messages: 98120
nosy: dieresys
severity: normal
status: open
title: Add support for Digest authentication session (reuse nonces)
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15966/urllib2-support_digest_sessions.diff

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

From report at bugs.python.org  Fri Jan 22 02:40:58 2010
From: report at bugs.python.org (Ross Cohen)
Date: Fri, 22 Jan 2010 01:40:58 +0000
Subject: [New-bugs-announce] [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>


New submission from Ross Cohen <rcohen at snurgle.org>:

This is a backport of the newgil work to the 2.7 branch (otherwise known as trunk.) Patch is against r77678.

Created by diffing r76193 (last in the newgil branch)
against r76189 and applying the result. Generally applied cleanly and it looked as though only 1 reject needed to be massaged in. Passes all tests except for test_command, but the unpatched source also fails that test on my machine.

Perf numbers for linux on Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
Using benchmark from here:
http://www.mail-archive.com/python-dev at python.org/msg43407.html
-j0
2.7   : 14.93s, 15.71s, 15.03s
newgil: 15.32s, 15.45s, 15.78s

-j4
2.7   : 22.44s, 22.30s, 22.19s
newgil: 18.75s, 18.80s, 18.79s

----------
components: Interpreter Core
files: newgil-2.7.diff
keywords: patch
messages: 98122
nosy: rcohen
severity: normal
status: open
title: newgil backport
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file15967/newgil-2.7.diff

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

From report at bugs.python.org  Fri Jan 22 03:20:21 2010
From: report at bugs.python.org (Mike Clark)
Date: Fri, 22 Jan 2010 02:20:21 +0000
Subject: [New-bugs-announce] [issue7754] decimal.Decimal 0.0**0.0 error
In-Reply-To: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>
Message-ID: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>


New submission from Mike Clark <undefinedspace at gmail.com>:

Good behavior:
>>> 0.0**0.0
1.0
>>>

Bad behavior:
>>> Decimal('0.0')**Decimal('0.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/decimal.py", line 2101, in __pow__
    return context._raise_error(InvalidOperation, '0 ** 0')
  File "/usr/lib/python2.6/decimal.py", line 3699, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: 0 ** 0
>>>

I'm in Python 2.6, I don't know if other versions are affected.

----------
messages: 98126
nosy: Mike.Clark
severity: normal
status: open
title: decimal.Decimal 0.0**0.0 error
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 22 11:05:54 2010
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 22 Jan 2010 10:05:54 +0000
Subject: [New-bugs-announce] [issue7755] copyright clarification for
	audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>


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

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

If the bug submitter is correct about these, it would be nice to replace these, or clarify the copyright for these files.

"the python source packages contain a non-free audio clip that is
from Monty Python's Flying Circus, which is Copyright 1969.  i doubt
that the copyright holders have put any of that material into the
public domain, and the copyright term has not yet expired.

the files are:
 ./Lib/test/audiotest.au
 ./Lib/email/test/data/audiotest.au
"

----------
components: Tests
messages: 98141
nosy: doko
severity: normal
status: open
title: copyright clarification for audiotest.au
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jan 22 15:55:42 2010
From: report at bugs.python.org (Michael Smith)
Date: Fri, 22 Jan 2010 14:55:42 +0000
Subject: [New-bugs-announce] [issue7756] Complete your registration to
	Python tracker --	key	rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf
In-Reply-To: <20100121223805.D302678659@psf.upfronthosting.co.za>
Message-ID: <4B59BC6A.4070802@cbnco.com>


New submission from Michael Smith <msmith at cbnco.com>:

Python tracker wrote:
> To complete your registration of the user "msmith at cbnco.com" with
> Python tracker, please do one of the following:
> 
> - send a reply to report at bugs.python.org and maintain the subject line as is (the
> reply's additional "Re:" is ok),
> 
> - or visit the following URL:
> 
> http://bugs.python.org/?@action=confrego&otk=rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf
>

----------
messages: 98146
nosy: msmith at cbnco.com
severity: normal
status: open
title: Complete your registration to Python tracker -- key	rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf

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

From report at bugs.python.org  Fri Jan 22 17:46:16 2010
From: report at bugs.python.org (Michael Smith)
Date: Fri, 22 Jan 2010 16:46:16 +0000
Subject: [New-bugs-announce] [issue7757] sys.path is incorrect when prefix
	is ""
In-Reply-To: <1264178776.01.0.552667161926.issue7757@psf.upfronthosting.co.za>
Message-ID: <1264178776.01.0.552667161926.issue7757@psf.upfronthosting.co.za>


New submission from Michael Smith <msmith at cbnco.com>:

I've built Python 2.6.2 with a prefix of "" for an embedded system, so it's installed into /bin/python, /lib/python2.6/, etc.

If I run a script with "python /tmp/script.py" or by putting in a #!/bin/python and executing it directly, sys.path is missing the leading slashes:

['/tmp', 'lib/python26.zip', 'lib/python2.6/', 'lib/python2.6/plat-linux2', 'lib/python2.6/lib-tk', 'lib/python2.6/lib-old', 'lib/lib-dynload']

This causes all module imports to fail. I can work around this by making /usr a symlink to / and running the script as "/usr/bin/python /tmp/script.py", or by setting PYTHONHOME=/ before starting Python.

In Modules/getpath.c, search_for_prefix() calls reduce() on argv0_path at the end of a do-while loop, so "/bin" becomes "" and the loop terminates. Then there's a call to joinpath(PREFIX, "lib/python2.6"), where PREFIX is "", and this fails (no leading slash).

calculate_path() warns:

Could not find platform independent libraries <prefix>

and falls back to joinpath(PREFIX, "lib/python2.6") again, which still fails.

I was thinking I could work around it by building with prefix="/" instead of "", but the behaviour is the same - I don't know why, yet.

----------
components: Interpreter Core
messages: 98152
nosy: msmith at cbnco.com
severity: normal
status: open
title: sys.path is incorrect when prefix is ""
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 22 20:24:15 2010
From: report at bugs.python.org (Dan Helfman)
Date: Fri, 22 Jan 2010 19:24:15 +0000
Subject: [New-bugs-announce] [issue7758] cPickle segfault on invalid data
In-Reply-To: <1264188255.93.0.523423533776.issue7758@psf.upfronthosting.co.za>
Message-ID: <1264188255.93.0.523423533776.issue7758@psf.upfronthosting.co.za>


New submission from Dan Helfman <dan.helfman at noaa.gov>:

The following code causes Python to segfault:

>>> import cPickle
>>> import cStringIO as io
>>> cPickle.load( io.StringIO( '0' ) )

Note that if the string is changed from '0' to '1', then the crash does not occur and an UnpicklingError is properly raised.

This is in MSYS on Windows XP with Python 2.6.4 from python.org:

$ gdb python
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)...
(gdb) r -c "import cPickle; import cStringIO as io;  cPickle.load( io.StringIO( '0' ) )"
Starting program: c:\python26/python.exe -c "import cPickle; import cStringIO as io;  cPickle.load( io.StringIO( '0' ) )"

Program received signal SIGSEGV, Segmentation fault.
0x1e09ada3 in ?? ()
(gdb) bt
#0  0x1e09ada3 in ?? ()
#1  0x1e0e1fd5 in ?? ()
#2  0x00a4e290 in ?? ()
#3  0x1e1d1d30 in ?? ()
Cannot access memory at address 0x3

And this is on Mac OS X 10.5 with Python 2.6.4 from python.org:

$ gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) r -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )"
Starting program: /System/Library/Frameworks/Python.framework/Versions/2.6/bin/python -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )"
Reading symbols for shared libraries +. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe01010 in __dyld__dyld_start ()
(gdb) bt
#0  0x8fe01010 in __dyld__dyld_start ()
Cannot access memory at address 0x4

The same crash occurs on the Mac when using Apple's Python 2.5.1. However, on Linux with Debian stable's Python 2.5.2, I just get an UnpicklingError (stack underflow) exception without a crash.

----------
components: None
messages: 98157
nosy: dhelfman
severity: normal
status: open
title: cPickle segfault on invalid data
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 22 23:22:14 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 22 Jan 2010 22:22:14 +0000
Subject: [New-bugs-announce] [issue7759] mhlib fails on Btrfs filesystem
	(test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

Btrfs does not maintain a link count for directories (MacOS does the same I think). That confuses mhlib.py because it uses os.stat().st_nlinks as an optimization.

The attached patch removes the optimization and make test_mhlib pass on Btrfs (and probably HFS+) filesystems.

----------
files: mhlib_nlinks.txt
messages: 98169
nosy: nascheme
priority: normal
severity: normal
status: open
title: mhlib fails on Btrfs filesystem (test_mhlib failure)
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15975/mhlib_nlinks.txt

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

From report at bugs.python.org  Sat Jan 23 01:18:57 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 23 Jan 2010 00:18:57 +0000
Subject: [New-bugs-announce] [issue7760] use_errno=True does not work
In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za>
Message-ID: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

On my system (Ubuntu Karmic, Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15), Kernel 2.6.31-17-generic, libc6 2.10.1-0ubuntu16) the attached test script produces the following output:

Traceback (most recent call last):
  File "test1.py", line 27, in <module>
    raise OSError(err, os.strerror(err), path)
OSError: [Errno 0] Success: '/does/not/exist'

So the function call failed, but the errno provided by ctypes is zero.

(There are two variants of construction the getxattr() foreign function in the script and both produce the same result).

----------
assignee: theller
components: ctypes
files: test1.py
messages: 98171
nosy: Nikratio, theller
severity: normal
status: open
title: use_errno=True does not work
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15976/test1.py

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

From report at bugs.python.org  Sat Jan 23 03:15:00 2010
From: report at bugs.python.org (Michael Newman)
Date: Sat, 23 Jan 2010 02:15:00 +0000
Subject: [New-bugs-announce] [issue7761] telnetlib Telnet.interact fails on
	Windows but not Linux
In-Reply-To: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>
Message-ID: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

Telnet.interact() is failing on Python 3.1.1 Windows, but works fine on Python 2.6.4 Windows and also works on Python 3.1.1 Linux. See 3 examples below:

--- Test #1 (fails): Telnet.interact on Python 3.1.1 Windows --- 

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> tn = Telnet("scn.org", 23)
>>> tn.interact()
Unhandled exception in thread started by <bound method Telnet.listener of <telnetlib.Telnet object at 0x00C3C3F0>>
Traceback (most recent call last):
  File "C:\python31\lib\telnetlib.py", line 566, in listener
    sys.stdout.write(data)
TypeError: must be str, not bytes
# (I press enter again):
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python31\lib\telnetlib.py", line 528, in interact
    self.mt_interact()
  File "C:\python31\lib\telnetlib.py", line 555, in mt_interact
    self.write(line)
  File "C:\python31\lib\telnetlib.py", line 277, in write
    if IAC in buffer:
TypeError: 'in <string>' requires string as left operand, not bytes

--- Test #2 (works): Telnet.interact on Python 2.6.4 Windows ---

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> tn = Telnet("scn.org", 23)
>>> tn.interact()

Seattle Community Network Sun Solaris 1.1.1.B
Please login as 'visitor' if you are a visitor


SunOS UNIX (scn)

login:

--- Test #3 (works): Telnet.interact on Python 3.1.1 Linux ---

mike at ebx2009:~$ python3.1
Python 3.1.1 (r311:74480, Oct 18 2009, 19:21:53) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> tn = Telnet("scn.org", 23)
>>> tn.interact()

Seattle Community Network Sun Solaris 1.1.1.B
Please login as 'visitor' if you are a visitor


SunOS UNIX (scn)

login:

----------
components: Library (Lib), Windows
messages: 98174
nosy: mnewman
severity: normal
status: open
title: telnetlib Telnet.interact fails on Windows but not Linux
versions: Python 3.1

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

From report at bugs.python.org  Sat Jan 23 08:36:08 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 23 Jan 2010 07:36:08 +0000
Subject: [New-bugs-announce] [issue7762] (C API) PyUnicode_Tailmatch
	documentation
In-Reply-To: <1264232168.43.0.991718973668.issue7762@psf.upfronthosting.co.za>
Message-ID: <1264232168.43.0.991718973668.issue7762@psf.upfronthosting.co.za>


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

It mentions "Return value: New reference.", but I have no idea of what it can mean in this function, since the return type is 'int'.

http://docs.python.org/dev/py3k/c-api/unicode.html#PyUnicode_Tailmatch

----------
assignee: georg.brandl
components: Documentation
messages: 98176
nosy: georg.brandl, july
severity: normal
status: open
title: (C API) PyUnicode_Tailmatch documentation
versions: Python 3.2

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

From report at bugs.python.org  Sat Jan 23 08:36:11 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 23 Jan 2010 07:36:11 +0000
Subject: [New-bugs-announce] [issue7763] (C API) PyUnicode_Tailmatch
	documentation
In-Reply-To: <1264232171.64.0.310629533976.issue7763@psf.upfronthosting.co.za>
Message-ID: <1264232171.64.0.310629533976.issue7763@psf.upfronthosting.co.za>


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

It mentions "Return value: New reference.", but I have no idea of what it can mean in this function, since the return type is 'int'.

http://docs.python.org/dev/py3k/c-api/unicode.html#PyUnicode_Tailmatch

----------
assignee: georg.brandl
components: Documentation
messages: 98177
nosy: georg.brandl, july
severity: normal
status: open
title: (C API) PyUnicode_Tailmatch documentation
versions: Python 3.2

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

From report at bugs.python.org  Sat Jan 23 14:53:01 2010
From: report at bugs.python.org (Muhammad Alkarouri)
Date: Sat, 23 Jan 2010 13:53:01 +0000
Subject: [New-bugs-announce] [issue7764] Doc for itertools recipe consume is
	complicated and less	efficient
In-Reply-To: <1264254781.04.0.3391109102.issue7764@psf.upfronthosting.co.za>
Message-ID: <1264254781.04.0.3391109102.issue7764@psf.upfronthosting.co.za>


New submission from Muhammad Alkarouri <malkarouri at gmail.com>:

Based on the discussion at:
http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/c1ae3513a31eb63e/d0701a9902732c67?hl=en#d0701a9902732c67

In the documentation of itertools, one of the functions provided in the recipes section (10.7.3) is consume:

def consume(iterator, n):
    "Advance the iterator n-steps ahead. If n is none, consume entirely."
    collections.deque(islice(iterator, n), maxlen=0)

A clearer implementation is:

def consume(n, items):
    if n == 0:
        return
    next(islice(items, n-1, None), None)

It uses no fancy tricks and is thus more suitable for a documentation. Moreover, the second implementation is actually more efficient. Some timings are provided in the thread linked above. As an example, here are the timings on my machine (Python 2.6.1, x86_64, OS X 10.6:

consume_deque #old implementation
    10: 1.2913839817
   100: 3.18093585968
  1000: 21.6316840649

consume_forloop #using a straight for loop
    10: 0.658184051514
   100: 2.85271406174
  1000: 24.6730420589

consume_islice #the suggested implementation
    10: 0.688861131668
   100: 1.15058612823
  1000: 5.52356886864

The script computing these timings is attached. Thanks to Peter Otten for coming up both with the function and the timing script.

----------
assignee: georg.brandl
components: Documentation
files: consume_timeit.py
messages: 98187
nosy: Muhammad.Alkarouri, georg.brandl
severity: normal
status: open
title: Doc for itertools recipe consume is complicated and less efficient
type: performance
Added file: http://bugs.python.org/file15978/consume_timeit.py

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

From report at bugs.python.org  Sat Jan 23 20:43:18 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 23 Jan 2010 19:43:18 +0000
Subject: [New-bugs-announce] [issue7765] 'unittest' documentation misprints
In-Reply-To: <1264275798.04.0.174559060611.issue7765@psf.upfronthosting.co.za>
Message-ID: <1264275798.04.0.174559060611.issue7765@psf.upfronthosting.co.za>


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

Errors in command line examples.

One missed space (only in py3k version), and one not so obvious misprint (in both py3k and trunk).

----------
assignee: georg.brandl
components: Documentation
files: unittest-doc-py3k.diff
keywords: patch
messages: 98196
nosy: georg.brandl, july
severity: normal
status: open
title: 'unittest' documentation misprints
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15980/unittest-doc-py3k.diff

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

From report at bugs.python.org  Sat Jan 23 20:57:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jan 2010 19:57:12 +0000
Subject: [New-bugs-announce] [issue7766] sys.getwindowsversion as
	PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>


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

I always find myself wishing sys.getwindowsversion() utilized the named tuple concept, so here it is against trunk. sys.version_info was also changed in this manner for 2.7.

Because it is a PyStructSeq/named tuple, it is still accessible like a regular old tuple, but can now be accessed by named attributes.

One thing I don't like is that this is a function, unlike sys.version_info. I think something like sys.windows_version would be better...is there sense in making that an additional API and starting to phase out the getwindowsversion function in py3k?

The patch includes doc and test changes.

----------
components: Library (Lib)
files: winver_as_structseq.diff
keywords: needs review, patch, patch
messages: 98197
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: sys.getwindowsversion as PyStructSequence
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15982/winver_as_structseq.diff

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

From report at bugs.python.org  Sun Jan 24 02:16:49 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 24 Jan 2010 01:16:49 +0000
Subject: [New-bugs-announce] [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

There are "Long" and "LongLong" variants for most of the C API functions that work with PyLong. This patch adds a "LongLong" version of PyLong_AsLongAndOverflow.

This function will be helpful on 64-bit Windows platforms to quickly get a 64-bit integer or detect the need for multiple precision (or overflow). 

I can use this functionality for gmpy.

----------
components: Extension Modules
files: patch_longlong.diff
keywords: patch
messages: 98203
nosy: casevh
severity: normal
status: open
title: Add PyLong_AsLongLongAndOverflow
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file15985/patch_longlong.diff

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

From report at bugs.python.org  Sun Jan 24 06:12:04 2010
From: report at bugs.python.org (Naoki INADA)
Date: Sun, 24 Jan 2010 05:12:04 +0000
Subject: [New-bugs-announce] [issue7768] raw_input should encode unicode
	prompt with	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>


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

raw_input and input should take unicode prompt and encode with sys.stdout.encoding like print or input in py3k.

>>> u = u"???"
>>> print u
???
>>> x = raw_input(u)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)
>>> import sys
>>> sys.stdout.encoding
'cp932'

----------
components: IO, Unicode
messages: 98208
nosy: naoki
severity: normal
status: open
title: raw_input should encode unicode prompt with std.stdout.encoding.
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Jan 24 13:48:46 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 12:48:46 +0000
Subject: [New-bugs-announce] [issue7769]
	SimpleXMLRPCServer.SimpleXMLRPCServer.register_function	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>


New submission from Johannes Sch?nberger <jls at icoost.com>:

I would suggest to make SimpleXMLRPCServer.SimpleXMLRPCServer.register_function a decorator function.
See the attached file for the solution I wrote (l.209-240), which also works with the current syntax:
@server.register_function
@server.register_function('name')
@server.register_function(name='name')
or:
server.register_function(func)
server.register_function(func, name='name')
server.register_function(function=func, name='name')

So as far as I've tested it (py2.6), it is fully backwards compatible and supports decorators in addition.

----------
components: Extension Modules
files: SimpleXMLRPCServer.py
messages: 98219
nosy: ahojnnes
severity: normal
status: open
title: SimpleXMLRPCServer.SimpleXMLRPCServer.register_function as decorator
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file15986/SimpleXMLRPCServer.py

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

From report at bugs.python.org  Sun Jan 24 14:09:51 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 13:09:51 +0000
Subject: [New-bugs-announce] [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>


New submission from Johannes Sch?nberger <jls at icoost.com>:

Unfortunately the sin/cos function in the decimal docs seems to return false results.

In [33]: sin(decimal.Decimal('75'))
Out[33]: Decimal('0.377879483645203210442266845614')

In [34]: sin(decimal.Decimal('76'))
Out[34]: Decimal('-2.08828460009724889326220807212')

In [42]: sin(decimal.Decimal('100'))
Out[42]: Decimal('-58433045378.5877442230422602000')

#####

In [37]: cos(decimal.Decimal('79'))
Out[37]: Decimal('-14.3603762068086273628189466621')

In [38]: cos(decimal.Decimal('77'))
Out[38]: Decimal('-13.6219693138941571794243404126')

In [39]: cos(decimal.Decimal('75'))
Out[39]: Decimal('1.25761570869417008177315814688')

In [40]: cos(decimal.Decimal('72'))
Out[40]: Decimal('-1.02323683857735456186757099584')

----------
assignee: georg.brandl
components: Documentation
messages: 98221
nosy: ahojnnes, georg.brandl
severity: normal
status: open
title: sin/cos function in decimal-docs
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jan 24 18:19:26 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 24 Jan 2010 17:19:26 +0000
Subject: [New-bugs-announce] [issue7771] dict view comparison methods are
	not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

Dictionary views documentation (e.g. http://docs.python.org/3.1/library/stdtypes.html#dictionary-view-objects) contains nothing about comparison (> >= < <= == !=) operations.

----------
assignee: georg.brandl
components: Documentation
messages: 98240
nosy: georg.brandl, zuo
severity: normal
status: open
title: dict view comparison methods are not documented
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan 24 19:42:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 18:42:27 +0000
Subject: [New-bugs-announce] [issue7772] test_py3kwarn fails when running
	the whole test suite
In-Reply-To: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>
Message-ID: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

"test_py3kwarn" fails when running the whole test suite

This is a known behaviour, because of extension modules loaded by previous tests (which cannot be "reloaded").

However, the warnings module store all the warnings when they appear in a dictionary attribute attached to the module which does the "import".

We may read this dictionary attribute for the purpose of this test.

----------
components: Tests
messages: 98244
nosy: flox
severity: normal
status: open
title: test_py3kwarn fails when running the whole test suite
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Jan 24 21:10:07 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Jan 2010 20:10:07 +0000
Subject: [New-bugs-announce] [issue7773] platform._parse_release_file() can
	cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>


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

When the release file doesn't contain some data, then platform._parse_release_file() causes UnboundLocalError. I'm attaching the patch to fix it.

$ python2.7 -c 'import platform; platform._parse_release_file("")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/platform.py", line 285, in _parse_release_file
    return '', version, id
UnboundLocalError: local variable 'version' referenced before assignment

----------
components: Library (Lib)
files: python-fix_platform._parse_release_file.patch
keywords: patch
messages: 98250
nosy: Arfrever
severity: normal
status: open
title: platform._parse_release_file() can cause UnboundLocalError
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15993/python-fix_platform._parse_release_file.patch

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

From report at bugs.python.org  Mon Jan 25 00:23:22 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 24 Jan 2010 23:23:22 +0000
Subject: [New-bugs-announce] [issue7774] subprocess executable option wrong
	location
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>


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

test_subprocess.test_executable now has a failure in the subprocess created (see http://www.python.org/dev/buildbot/builders/amd64%20gentoo%20trunk/builds/303/steps/test/logs/stdio)

the bbots don't get red because this is happening in the subprocess and the test just look for the return code.

This is hapenning since I've added the sysconfig module. This change revealed a bug in subprocess.

This call :

  subprocess.Popen(["somethingyoudonthave", "-c", "import sys; print sys.executable"], executable=sys.executable)   

will print a directory name for sys.executable, instead of the real value. That's fooling sysconfig, which is now called through site.py, to set a few variables.

----------
assignee: jnoller
components: Library (Lib)
messages: 98257
nosy: jnoller, tarek
priority: normal
severity: normal
status: open
title: subprocess executable option wrong location
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jan 25 05:04:38 2010
From: report at bugs.python.org (kai zhu)
Date: Mon, 25 Jan 2010 04:04:38 +0000
Subject: [New-bugs-announce] [issue7775] str.rpartition(sep) -> (tail, sep,
	head)
Message-ID: <1264392278.58.0.913306330016.issue7775@psf.upfronthosting.co.za>


Changes by kai zhu <kaizhu256 at gmail.com>:


----------
assignee: georg.brandl
components: Documentation
nosy: georg.brandl, kaizhu
severity: normal
status: open
title: str.rpartition(sep) -> (tail, sep, head)
versions: Python 3.1

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

From report at bugs.python.org  Mon Jan 25 05:34:02 2010
From: report at bugs.python.org (Cameron Simpson)
Date: Mon, 25 Jan 2010 04:34:02 +0000
Subject: [New-bugs-announce] [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>


New submission from Cameron Simpson <cs at zip.com.au>:

I'm trying to do HTTPS via a proxy in Python 2.6.4 (which is supposed to incorporate this fix from issue 1424152).

While trying to debug this starting from the suds library I've been reading httplib.py and urllib2.py to figure out what's going wrong
and found myself around line 687 of httplib.py at the _tunnel()
function.

_tunnel() is broken because _set_hostport() has side effects.

_tunnel() starts with:
  self._set_hostport(self._tunnel_host, self._tunnel_port)
to arrange that the subsequent connection is made to the proxy
host and port, and that is in itself ok.

However, _set_hostport() sets the .host and .port attributes in
the HTTPConnection object.

The next action _tunnel() takes is to send the CONNECT HTTP command,
filling in the endpoint host and port from self.host and self.port.
But these values have been overwritten by the preceeding _set_hostport()
call, and so we ask the proxy to connect to itself.

It seems to me that _tunnel() should be grabbing the original host and port before calling _set_hostport(), thus:

  ohost, oport = self.host, self.port
  self._set_hostport(self._tunnel_host, self._tunnel_port)
  self.send("CONNECT %s:%d HTTP/1.0\r\n\r\n" % (ohost, oport))

In fact the situation seems even worse: _tunnel() calls send(), send() calls connect(), and connect() calls _tunnel() in an infinite regress.
- Cameron Simpson

----------
components: Library (Lib)
messages: 98264
nosy: cameron
severity: normal
status: open
title: httplib.py: ._tunnel() broken
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 25 08:27:40 2010
From: report at bugs.python.org (Andrew Grover)
Date: Mon, 25 Jan 2010 07:27:40 +0000
Subject: [New-bugs-announce] [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>


New submission from Andrew Grover <andy.grover at gmail.com>:

RDS is a reliable datagram protocol used by Oracle clusters for inter-process communication. It is in the Linux kernel, and has a defined address family number. Its use is identical to UDP, except the address family is 21, and the type is SOCK_SEQPACKET.

So, what's this got to do with Python? :)

Apparently Modules/socketmodule.c getsockaddrarg() checks bind() args, and only allows known socket types to bind. Attempting to bind with an RDS socket fails.

It looks pretty straightforward to add support for a new family, but before doing so I wanted to check whether this was likely to be accepted, and also to ask if it wouldn't make more sense for getsockaddrarg() to not default to failing unknown families, but instead letting them through? If the params are wrong for a non-enumerated family, bind() will presumably return an error that the user will get.

----------
components: Extension Modules
messages: 98271
nosy: Andrew.Grover
severity: normal
status: open
title: Support needed for AF_RDS family
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jan 25 14:29:02 2010
From: report at bugs.python.org (=?utf-8?q?Vincent_F=C3=A9rotin?=)
Date: Mon, 25 Jan 2010 13:29:02 +0000
Subject: [New-bugs-announce] [issue7778] Typo(s) in ``itertools``
	documentation reST marker
In-Reply-To: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>
Message-ID: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>


New submission from Vincent F?rotin <vincent.ferotin at gmail.com>:

In Python 2.6 ``itertools`` library documentation is a small typo in last paragraph (``projects/python/branches/release26-maint/Doc/library/itertools.rst``, rev. [77750]), see it at http://docs.python.org/library/itertools.html#recipes .

In the note about how optimizing recipes, ``dotproduct`` example function is not outlined as a code sample. Lines 762-763 should end with double colons (instead of simple), to mark following code as such, in reST format::

   (...) For example, the
   *dotproduct* recipe can be written as::

Note that previous ``*dotproduct*`` ref. could be marked as ``inline literal`` instead of *emphasis*, and then lines become::

   (...) For example, the
   ``dotproduct`` recipe can be written as::

----------
assignee: georg.brandl
components: Documentation
messages: 98286
nosy: fero14041, georg.brandl
severity: normal
status: open
title: Typo(s) in ``itertools`` documentation reST marker
versions: Python 2.6

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

From report at bugs.python.org  Mon Jan 25 21:52:59 2010
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Surkamp?=)
Date: Mon, 25 Jan 2010 20:52:59 +0000
Subject: [New-bugs-announce] [issue7779] smtplib SASL PLAIN authentication
	error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>


New submission from S?rgio Surkamp <sergio at gruposinternet.com.br>:

There is bug in PLAIN mechanism's of smtplib. The generated base64 string fail when the password start with numbers. As long as I could find, the error occur in method encode_plain. Using the null character (\0) in hexadecimal representation (\x00) seems to fix the problem.

Origin of the problem:

        def encode_plain(user, password):
            return encode_base64("\0%s\0%s" % (user, password), eol="")

Proposed fix:

        def encode_plain(user, password):
            return encode_base64("\x00%s\x00%s" % (user, password), eol="")

Current result:
>>> from email.base64mime import encode as encode_base64
>>> import base64
>>> encode_base64("\0user\0123foo", eol="")
'AHVzZXIKM2Zvbw=='
>>> f = base64.decodestring('AHVzZXIKM2Zvbw==')
>>> f
'\x00user\n3foo'

Expected result:
>>> from email.base64mime import encode as encode_base64
>>> import base64
>>> encode_base64("\x00user\x00123foo", eol="")
'AHVzZXIAMTIzZm9v'
>>> f = base64.decodestring('AHVzZXIAMTIzZm9v')
>>> f
'\x00user\x00123foo'

----------
components: Extension Modules
messages: 98295
nosy: surkamp
severity: normal
status: open
title: smtplib SASL PLAIN authentication error
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Jan 25 23:31:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Jan 2010 22:31:29 +0000
Subject: [New-bugs-announce] [issue7780] unittest: allow an 'import_path' as
	an alternative to	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>


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

It would be nice if TestLoader.discover could take an argument that specifies the path to use to import the discovered tests, as an alternative to having to specify top_level_dir.

----------
assignee: michael.foord
components: Library (Lib)
messages: 98302
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
status: open
title: unittest: allow an 'import_path' as an alternative to 'top_level_dir' in test discover
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan 26 01:02:39 2010
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 26 Jan 2010 00:02:39 +0000
Subject: [New-bugs-announce] [issue7781] interactive pstats broken
In-Reply-To: <1264464159.48.0.243673781455.issue7781@psf.upfronthosting.co.za>
Message-ID: <1264464159.48.0.243673781455.issue7781@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I created a profile file, started up python3 -m pstats myfilename, did strip, then "stats 10" and got:

stats 10
Mon Jan 25 17:58:39 2010    cd.profile

         17529566 function calls (17528644 primitive calls) in 88.626 CPU seconds

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/runpy.py", line 128, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py", line 689, in <module>
    browser.cmdloop()
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/cmd.py", line 139, in cmdloop
    stop = self.onecmd(line)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/cmd.py", line 216, in onecmd
    return func(arg)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py", line 665, in do_stats
    return self.generic('print_stats', line)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py", line 586, in generic
    getattr(self.stats, fn)(*processed)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py", line 358, in print_stats
    width, list = self.get_print_list(amount)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py", line 331, in get_print_list
    list, msg = self.eval_print_amount(selection, list, msg)
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py", line 314, in eval_print_amount
    new_list = list[:count]
TypeError: 'dict_keys' object is not subscriptable

----------
components: Library (Lib)
messages: 98304
nosy: MLModel
severity: normal
status: open
title: interactive pstats broken
versions: Python 3.1

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

From report at bugs.python.org  Tue Jan 26 09:12:06 2010
From: report at bugs.python.org (showell)
Date: Tue, 26 Jan 2010 08:12:06 +0000
Subject: [New-bugs-announce] [issue7782] new test for test_iter.py
In-Reply-To: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>
Message-ID: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>


New submission from showell <showell30 at yahoo.com>:

I would like to submit the following test to be part of the test_iter.py test suite:

    def test_extends(self):
        # This test would break on an incomplete patch to listobject.c
        def gen():
            for i in range(500):
                yield i
        lst = [0] * 500
        for i in range(240):
            lst.pop(0)
        lst.extend(gen())

The history behind it is that I made a patch to listobject.c that obviously broke listextend(), but the tests did not catch it.  This was my failing test to improve my patch.  Regardless of what happens to the patch, I think it's a good idea to hammer on listextend() when it accepts an iterator, as it's a fairly tricky problem to extend a list when you do not know in advance how long it will be until the iterator gets exhausted.

----------
components: Tests
messages: 98320
nosy: Steve Howell
severity: normal
status: open
title: new test for test_iter.py
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jan 26 09:21:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 08:21:35 +0000
Subject: [New-bugs-announce] [issue7783] test_normalization fails when
	NormalizationTest.txt is	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

The test "test_normalization" download a file from the "unicode.org" website and keep it in the local cache "Lib/test/data/" directory for next runs.
On test setup, it verifies if the 1st line contains the right version "unicodedata.unidata_version".
It should unlink the file if it is outdated.
But it does not work as expected: it looks for the file in the wrong directory.

~ $ echo "# NormalizationTest-3.0.0.txt ~ outdated version" > Lib/test/data/NormalizationTest.txt

~ $ ./python -m test.regrtest -uall test_normalization
test_normalization
test test_normalization failed -- Traceback (most recent call last):
  File "./Lib/test/test_normalization.py", line 96, in test_main
    self.assertTrue(X == NFC(X) == NFD(X) == NFKC(X) == NFKD(X), c)
AssertionError: 160

1 test failed:
    test_normalization

~ $ cat Lib/test/data/NormalizationTest.txt
# NormalizationTest-3.0.0.txt ~ outdated version

----------
components: Tests, Unicode
messages: 98321
nosy: flox
severity: normal
status: open
title: test_normalization fails when NormalizationTest.txt is outdated
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 26 11:28:05 2010
From: report at bugs.python.org (showell)
Date: Tue, 26 Jan 2010 10:28:05 +0000
Subject: [New-bugs-announce] [issue7784] patch for making list/insert at the
	top of the list avoid	memmoves
In-Reply-To: <1264501685.22.0.657604584157.issue7784@psf.upfronthosting.co.za>
Message-ID: <1264501685.22.0.657604584157.issue7784@psf.upfronthosting.co.za>


New submission from showell <showell30 at yahoo.com>:

I am attaching a patch to improve the performance of list operations that insert or delete elements at the front of the list.  The patch has had some discussion on python-dev in the thread entitled "patch to make list.pop(0) work in O(1) time."

So far the verdict is not to touch list internals to achieve this performance gain, but I am looking to improve the patch regardless and possibly include it in a PEP that documents the decision not to incorporate the patch, with the hope that it either prevents future duplication of effort or eventually gets accepted.

At a bare minimum, the patch needs extensive code review, as it touches a lot of internals, and it needs stylistic cleanup.  But it does pass all the tests, and it has been benchmarked to show 100X speed improvement on a small test case.

----------
components: Interpreter Core
files: DIFF
messages: 98324
nosy: Steve Howell
severity: normal
status: open
title: patch for making list/insert at the top of the list avoid memmoves
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file16008/DIFF

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

From report at bugs.python.org  Tue Jan 26 14:10:12 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 26 Jan 2010 13:10:12 +0000
Subject: [New-bugs-announce] [issue7785] FileIO.write() accepts Unicode
	strings
In-Reply-To: <1264511412.59.0.542411267876.issue7785@psf.upfronthosting.co.za>
Message-ID: <1264511412.59.0.542411267876.issue7785@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

Is io.FileIO.write() supposed to accept and implicitly encode Unicode strings as illustrated by this simple example?

>>> f = open("/dev/null","wb",buffering=0)
>>> f.write("Hello World\n")
12
>>> 

Moreover, is the behavior of BufferedWriter objects supposed to be different as illustrated by this example:

>>> f = open("/dev/null","wb")
>>> f.write("Hello World\n")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: write() argument 1 must be bytes or buffer, not str
>>>

----------
components: IO
messages: 98333
nosy: dabeaz
severity: normal
status: open
title: FileIO.write() accepts Unicode strings
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Jan 26 18:42:34 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 26 Jan 2010 17:42:34 +0000
Subject: [New-bugs-announce] [issue7786] Is the BlockingIOError exception an
	aborted idea?
In-Reply-To: <1264527754.53.0.887033359111.issue7786@psf.upfronthosting.co.za>
Message-ID: <1264527754.53.0.887033359111.issue7786@psf.upfronthosting.co.za>


New submission from David Beazley <dave at dabeaz.com>:

Documentation (e.g., docstrings) for the io module make mention of a BlockingIOError exception that might be raised if operations are performed on a file that's in non-blocking mode.  However, I am unable to get this exception on any operation (instead None is returned for non-blocking).  Moreover, I can't find any reference in the C/Python source for the io module that ever raises this exception.

Perhaps someone can clarify the status of this exception?

----------
components: IO
messages: 98343
nosy: dabeaz
severity: normal
status: open
title: Is the BlockingIOError exception an aborted idea?
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Jan 26 19:41:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 18:41:11 +0000
Subject: [New-bugs-announce] [issue7787] Add an argument to
	test_support.open_urlresource to	invalidate the cache
In-Reply-To: <1264531271.23.0.207015207456.issue7787@psf.upfronthosting.co.za>
Message-ID: <1264531271.23.0.207015207456.issue7787@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

The function "open_urlresource" never invalidates its cache.
If a file with same name is available in "Lib/test/data/", it is returned.

There's a snippet in test_normalization which tries to invalidate the cache, but it fails because it looks in the wrong location. (#7783)

----------
components: Tests
messages: 98345
nosy: flox
severity: normal
status: open
title: Add an argument to test_support.open_urlresource to invalidate the cache
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jan 26 19:47:12 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 26 Jan 2010 18:47:12 +0000
Subject: [New-bugs-announce] [issue7788] segfault when deleting from a list
	using slice with very	big `step' value
In-Reply-To: <1264531632.85.0.040390960633.issue7788@psf.upfronthosting.co.za>
Message-ID: <1264531632.85.0.040390960633.issue7788@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:

del list_instance([start : stop : very_big_step]) causes segfaults...

The boundary values seem to be:
* start -- near length of the list
* stop -- near (-length) of the list
* very_big_step -- near sys.maxint

Let examples speak...

>>> from sys import maxint
>>> del range(10)[::maxint]
Segmentation fault

>>> from sys import maxint
>>> del range(10)[13::maxint]
>>> del range(10)[12::maxint]
>>> del range(10)[11::maxint]
>>> del range(10)[10::maxint]
>>> del range(10)[9::maxint]
Segmentation fault

>>> from sys import maxint
>>> del range(10)[:-13:maxint]
>>> del range(10)[:-12:maxint]
>>> del range(10)[:-11:maxint]
>>> del range(10)[:-10:maxint]
>>> del range(10)[:-9:maxint]
Segmentation fault

>>> from sys import maxint
>>> del range(10)[-8:8:maxint-5]
>>> del range(10)[-8:8:maxint-4]
>>> del range(10)[-8:8:maxint-3]
>>> del range(10)[-8:8:maxint-2]
Segmentation fault

System Info:
* Python 2.5.4 (r254:67916, Apr  4 2009, 17:55:16) 
* [GCC 4.3.3] on linux2
* sys.maxint == 2147483647, sys.byteorder == 'little'
* Processor: Pentium 4
* libc version: 2.9 (2.9-4ubuntu6)

----------
components: Interpreter Core
messages: 98348
nosy: zuo
severity: normal
status: open
title: segfault when deleting from a list using slice with very big `step' value
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Tue Jan 26 20:21:57 2010
From: report at bugs.python.org (JordanS)
Date: Tue, 26 Jan 2010 19:21:57 +0000
Subject: [New-bugs-announce] [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>


New submission from JordanS <jps126 at mun.ca>:

format() cannot handle datetime.DateTime objects, returns the format_spec instead, without applying formatting to it, perhaps default behaviour in case of unknown type. Different modifications, ie: using str.format() syntax produce same behaviour.

Sample code: 

import datetime

#data
row = {0: 1, 'BeamId': 218, 2: 0.0, 3: 0.0, 4: datetime.datetime(2006, 7, 18, 0, 12), 5: datetime.datetime(2007, 2, 23, 18, 26, 55, 450000), 6: 32637.774406455803, 1: 218, 'DateAndTime': datetime.datetime(2007, 2, 23, 18, 26, 55, 450000), 'AvgFlexuralStrengthDown': 32637.774406455803, 'WarmUpTime': datetime.datetime(2006, 7, 18, 0, 12), 'AvgFlexuralStrengthUp': 15916.5463146028, 'IceSheetId': 1, 'Y': 0.0, 'X': 0.0, 7: 15916.5463146028}

titles = ['BeamId', 'DateAndTime', 'AvgFlexuralStrengthDown', 'WarmUpTime', 'AvgFlexuralStrengthUp', 'IceSheetId', 'Y', 'X']

#attempt to print datetime: ignores formatting, doesn't print datetime value, prints format_spec instead
for key in titles:
    asLine = "{0:*<30}".format(row[key])
    print(asLine),
print '\n'

#prints a repr of datetime
for key in titles:
    asLine = "{0!r:*<30}".format(row[key])
    print(asLine),
print '\n'

#prints datetime as string
for key in titles:
    asLine = "{0!s:*<30}".format(row[key])
    print(asLine),
print '\n'

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 98358
nosy: JordanS
severity: normal
status: open
title: Issue using datetime with format()
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Jan 26 21:38:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jan 2010 20:38:34 +0000
Subject: [New-bugs-announce] [issue7790] struct_time documentation entry
	should point to the table	defining the tuple
In-Reply-To: <1264538314.16.0.129243655657.issue7790@psf.upfronthosting.co.za>
Message-ID: <1264538314.16.0.129243655657.issue7790@psf.upfronthosting.co.za>


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

In the beginning of 16.3 (time module documentation) the fields of a time tuple are defined, and it mentions that struct_time returns a named tuple version.  The entry for struct_time, which is what you get sent to by the entries for the functions that return it if you click on struct_time in their descriptions, does not mention the table of values.  It would be helpful (and clearer) if the struct_time entry had a link to the table describing the tuple.

----------
assignee: georg.brandl
components: Documentation
messages: 98379
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
status: open
title: struct_time documentation entry should point to the table defining the tuple
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/issue7790>
_______________________________________

From report at bugs.python.org  Tue Jan 26 23:03:14 2010
From: report at bugs.python.org (dholth)
Date: Tue, 26 Jan 2010 22:03:14 +0000
Subject: [New-bugs-announce] [issue7791] Python 2.6 standard library "sees
	also" something not in	the standard library
In-Reply-To: <1264543394.81.0.208086670233.issue7791@psf.upfronthosting.co.za>
Message-ID: <1264543394.81.0.208086670233.issue7791@psf.upfronthosting.co.za>


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

I thought it was really odd that the standard library documentation references ipaddr, a module from pypi, not something else in the standard library.

The documentation should explain that the referenced package is not a standard part of Python.

http://docs.python.org/library/socket.html#socket.inet_pton

See also

ipaddr.BaseIP.packed()
    Platform-independent conversion to a packed, binary format.

----------
assignee: georg.brandl
components: Documentation
messages: 98384
nosy: dholth, georg.brandl
severity: normal
status: open
title: Python 2.6 standard library "sees also" something not in the standard library
versions: Python 2.6

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

From report at bugs.python.org  Tue Jan 26 23:53:30 2010
From: report at bugs.python.org (andrew cooke)
Date: Tue, 26 Jan 2010 22:53:30 +0000
Subject: [New-bugs-announce] [issue7792] Errors registering non-classes with
	ABCs
In-Reply-To: <1264546410.38.0.169010295944.issue7792@psf.upfronthosting.co.za>
Message-ID: <1264546410.38.0.169010295944.issue7792@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

There are two related issues here.  The first is, I think, a simple bug:

When I try to register a function as a subclass of an ABC I get the error:
  TypeError: issubclass() arg 2 must be a class or tuple of classes

Looking at the code - http://svn.python.org/view/python/trunk/Lib/abc.py?annotate=72278 - it seems that instead the test at line 99 should have triggered a better error: TypeError("Can only register classes") 

In other words, line 99 should read:
  if not isinstance(subclass, type): 
(currently the code tests the "self class", cls, which is pointless).


My second issue is that this shouldn't raise an error at all.  It should be possible for functions to be registered as subclasses of ABCs.  This would simplify some code of mine that uses functions and classes interchangeably, and I can see no "real" reason why it shouldn't work.  From the user's point of view, my library provides a bunch of "things" that all look the same (they are provided with arguments and do stuff).  Whether these are constructors or functions is irrelevant...  and yet my code has to handle constructors and functions differently simply because of the errors here.

What I suspect I will do is have my own hash table, and forget ABCs, but that is a pity because these functions really do work as constructors (they are factories) and so the idea of them being subclasses of an ABC helps clarify my code.

----------
components: Library (Lib)
messages: 98387
nosy: acooke
severity: normal
status: open
title: Errors registering non-classes with ABCs
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jan 27 01:15:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 27 Jan 2010 00:15:37 +0000
Subject: [New-bugs-announce] [issue7793] regrtest fails with "RuntimeError:
	maximum recursion	depth exceeded" in some cases
In-Reply-To: <1264551337.94.0.106347277141.issue7793@psf.upfronthosting.co.za>
Message-ID: <1264551337.94.0.106347277141.issue7793@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

~ $ ./python -m test.regrtest -R 1:0: test_multibytecodec_support test_codecencodings_tw test_codecencodings_jp

test_multibytecodec_support
test_codecencodings_tw
test test_codecencodings_tw failed -- Traceback (most recent call last):
  File "./Lib/test/test_multibytecodec_support.py", line 88, in test_customreplace_encode
    "test.xmlcharnamereplace")[0], sout)
  File "./Lib/test/test_multibytecodec_support.py", line 74, in xmlcharnamereplace
    if ord(c) in codepoint2name:
  File "./Lib/test/test_multibytecodec_support.py", line 260, in ord
    return _ord(c)
  File "./Lib/test/test_multibytecodec_support.py", line 260, in ord
    return _ord(c)
  File "./Lib/test/test_multibytecodec_support.py", line 260, in ord
    return _ord(c)
(...)
RuntimeError: maximum recursion depth exceeded

test_codecencodings_jp
test test_codecencodings_jp failed -- multiple errors occurred; run in verbose mode for details
1 test OK.
2 tests failed:
    test_codecencodings_jp test_codecencodings_tw

----------
components: Tests
messages: 98392
nosy: flox
priority: normal
severity: normal
stage: test needed
status: open
title: regrtest fails with "RuntimeError: maximum recursion depth exceeded" in some cases
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Jan 27 14:12:55 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Jan 2010 13:12:55 +0000
Subject: [New-bugs-announce] [issue7794] Document zipfile and directory
	execution in What's New	for 2.6/3.1
In-Reply-To: <1264597975.95.0.291487626688.issue7794@psf.upfronthosting.co.za>
Message-ID: <1264597975.95.0.291487626688.issue7794@psf.upfronthosting.co.za>


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

As discussed recently on python-dev, issue 1739468 deserves a mention in the What's New for the relevant Python releases.

----------
assignee: ncoghlan
components: Documentation
keywords: easy
messages: 98420
nosy: akuchling, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document zipfile and directory execution in What's New for 2.6/3.1
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jan 27 14:58:32 2010
From: report at bugs.python.org (=?utf-8?q?Jonas_Weism=C3=BCller?=)
Date: Wed, 27 Jan 2010 13:58:32 +0000
Subject: [New-bugs-announce] [issue7795] BaseManager of multiprocessing
	module throws an exception	if socket.setdefaulttimeout is set
In-Reply-To: <1264600712.2.0.672123017218.issue7795@psf.upfronthosting.co.za>
Message-ID: <1264600712.2.0.672123017218.issue7795@psf.upfronthosting.co.za>


New submission from Jonas Weism?ller <jonas.weismueller at gmail.com>:

If socket.setdefaulttimeout is set to any value (except None), the BaseManager raises an exception and the execution of the remote object fails:
Traceback (most recent call last):
  File "client.py", line 16, in <module>
    m = Manager()
  File "client.py", line 12, in __init__
    self.connect()
  File "/usr/lib/python2.6/multiprocessing/managers.py", line 474, in connect
    conn = Client(self._address, authkey=self._authkey)
  File "/usr/lib/python2.6/multiprocessing/connection.py", line 140, in Client
    answer_challenge(c, authkey)
  File "/usr/lib/python2.6/multiprocessing/connection.py", line 371, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message

See the attached client.py (uploading soon) and server.py file to reproduce the error.

Python version used:
Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2

Same behaviour with python version:
Python 2.6 (r26:66714, Nov  3 2009, 17:33:38)
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2

The operating system is Fedora 11.

----------
components: Library (Lib)
files: server.py
messages: 98427
nosy: MrRagga
severity: normal
status: open
title: BaseManager of multiprocessing module throws an exception if socket.setdefaulttimeout is set
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file16025/server.py

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

From report at bugs.python.org  Wed Jan 27 17:11:09 2010
From: report at bugs.python.org (Peter Waller)
Date: Wed, 27 Jan 2010 16:11:09 +0000
Subject: [New-bugs-announce] [issue7796] No way to find out if an object is
	an instance of a	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>


New submission from Peter Waller <peter.waller at gmail.com>:

Apologies if there is a way of doing this, but I haven't been able to find anything.

I need to be able to do the following:

my_tuple = namedtuple("my_tuple", "a b c")
obj = my_tuple(1,2,3)

if isinstance(obj, namedtuple):
    .. do stuff ..

The best I could come up with for the moment is:

if isinstance(obj, tuple) and type(obj) is not tuple:
    .. do stuff ..

----------
messages: 98437
nosy: pwaller
severity: normal
status: open
title: No way to find out if an object is an instance of a namedtuple
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 28 06:40:34 2010
From: report at bugs.python.org (Justin Lebar)
Date: Thu, 28 Jan 2010 05:40:34 +0000
Subject: [New-bugs-announce] [issue7797] base64 module docs should indicate
	that encode methods	return bytes, not strings
In-Reply-To: <1264657234.88.0.361902382991.issue7797@psf.upfronthosting.co.za>
Message-ID: <1264657234.88.0.361902382991.issue7797@psf.upfronthosting.co.za>


New submission from Justin Lebar <starwiz at gmail.com>:

It's not at all clear from the documentation that base64.base64encode() and its kin return bytes, rather than strings.  Since this matters now, the docs should be clear on this point.

http://docs.python.org/3.1/library/base64.html

----------
assignee: georg.brandl
components: Documentation
messages: 98458
nosy: Justin.Lebar, georg.brandl
severity: normal
status: open
title: base64 module docs should indicate that encode methods return bytes,  not strings
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Thu Jan 28 16:26:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 28 Jan 2010 15:26:41 +0000
Subject: [New-bugs-announce] [issue7798] document pydoc methods
In-Reply-To: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za>
Message-ID: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za>


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

pydoc contains some useful methods like "pager()" that could be reused in many python application, and it would be handy to have a documentation for them in Python manual http://docs.python.org/library/pydoc

----------
assignee: georg.brandl
components: Documentation
messages: 98463
nosy: georg.brandl, techtonik
severity: normal
status: open
title: document pydoc methods
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu Jan 28 19:17:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jan 2010 18:17:26 +0000
Subject: [New-bugs-announce] [issue7799] unittest returning standard_tests
	from load_tests in	module fails
In-Reply-To: <1264702646.96.0.224010366293.issue7799@psf.upfronthosting.co.za>
Message-ID: <1264702646.96.0.224010366293.issue7799@psf.upfronthosting.co.za>


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

Working from the example in the docs, I wrote a test suite like this:

def load_tests(loader, standard_tests, pattern):
    for case in email.test.emailtestdb.populated_test_cases(globals()):
        standard_tests.addTests(loader.loadFromTestCase(case))
    return standard_test

This resulted in the exception:

Traceback (most recent call last):
  File "/home/rdmurray/python/bzr/email6-local/Lib/test/regrtest.py", line 857, in runtest_inner
    indirect_test()
  File "/home/rdmurray/python/bzr/email6-local/Lib/test/test_email.py", line 10, in test_main
    tests = unittest.defaultTestLoader.discover(testdir, top_level_dir=libdir)
  File "/home/rdmurray/python/bzr/email6-local/Lib/unittest/loader.py", line 179, in discover
    return self.suiteClass(tests)
  File "/home/rdmurray/python/bzr/email6-local/Lib/unittest/suite.py", line 18, in __init__
    self.addTests(tests)
  File "/home/rdmurray/python/bzr/email6-local/Lib/unittest/suite.py", line 54, in addTests
    self.addTest(test)
  File "/home/rdmurray/python/bzr/email6-local/Lib/unittest/suite.py", line 43, in addTest
    raise TypeError("{} is not callable".format(test))
TypeError: [<unittest.suite.TestSuite tests=[]>, <unittest.suite.TestSuite tests=[]>, <unittest.suite.TestSuite tests=[]>] is not callable

(Well, that's after I enhanced the normal error message, which just says that 'test must be a callable')

I see that loadTestsFromModule wraps what is passes as standard_tests in self.suiteClass before returning it, whereas it returns whatever load_tests returns directly.  Perhaps the wrapping needs to be done in both cases, or perhaps standard_tests should be wrapped before being passed to the module's load_tests?

My load_tests is a function in a test module, not a package __init__.

----------
components: Library (Lib)
keywords: easy
messages: 98469
nosy: r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: unittest returning standard_tests from load_tests in module fails
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jan 29 00:58:38 2010
From: report at bugs.python.org (Chris Carter)
Date: Thu, 28 Jan 2010 23:58:38 +0000
Subject: [New-bugs-announce] [issue7800] Attributes of type list are static
In-Reply-To: <1264723118.05.0.241315324434.issue7800@psf.upfronthosting.co.za>
Message-ID: <1264723118.05.0.241315324434.issue7800@psf.upfronthosting.co.za>


New submission from Chris Carter <jesdisciple at gmail.com>:

The test case at the end of this message seems to indicate that the list is being initialized only once for all wrapper instances.  I've tried to find anything about static members in Python and came up empty.  I also found no relevant existing bugs.

Expected output:
0 [0]
1 [1]
2 [2]
3 [3]

Actual output:
0 [0]
1 [0, 1]
2 [0, 1, 2]
3 [0, 1, 2, 3]

Test case:
i = 0
class Lister:

        list = []
        string = ""
        def __init__(self):
            global i
            self.list.append(i)
            self.string += str(i)
            i += 1
        def __str__(self):
            return "%s %s" % (self.string, self.list)

print Lister()
print Lister()
print Lister()
print Lister()

----------
components: Interpreter Core
messages: 98483
nosy: Chris.Carter
severity: normal
status: open
title: Attributes of type list are static
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 29 01:21:16 2010
From: report at bugs.python.org (Michael Newman)
Date: Fri, 29 Jan 2010 00:21:16 +0000
Subject: [New-bugs-announce] [issue7801] xmlrpc.client binary object
	examples needs to use binary	mode
In-Reply-To: <1264724476.48.0.691584161894.issue7801@psf.upfronthosting.co.za>
Message-ID: <1264724476.48.0.691584161894.issue7801@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

In Section 20.23.3 Binary Objects of:
http://docs.python.org/3.1/library/xmlrpc.client.html

The server AND client examples fail because the read and write methods are not set to binary mode.

Example of what the client portion shows if you use the examples "as is" with Python 3.1.1 (r311:74483) on win32:

C:\Python31\python.exe example3_binary_obj_client.py
Traceback (most recent call last):
  File "example3_binary_obj_client.py", line 10, in <module>
    handle.write(proxy.python_logo().data)
  File "C:\python31\lib\xmlrpc\client.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "C:\python31\lib\xmlrpc\client.py", line 1271, in __request
    verbose=self.__verbose
  File "C:\python31\lib\xmlrpc\client.py", line 1070, in request
    return self.parse_response(resp)
  File "C:\python31\lib\xmlrpc\client.py", line 1169, in parse_response
    return u.close()
  File "C:\python31\lib\xmlrpc\client.py", line 673, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault 1: "<class 'UnicodeDecodeError'>:'charmap' codec can't decode byte 0x81 in position 297: character maps to <undefined>">

To fix it, the server example should have:

handle = open("python_logo.jpg", "rb")

and the client example should have:

handle = open("fetched_python_logo.jpg", "wb")

----------
assignee: georg.brandl
components: Documentation
messages: 98488
nosy: georg.brandl, mnewman
severity: normal
status: open
title: xmlrpc.client binary object examples needs to use binary mode
versions: Python 3.1

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

From report at bugs.python.org  Fri Jan 29 02:18:21 2010
From: report at bugs.python.org (Michael Newman)
Date: Fri, 29 Jan 2010 01:18:21 +0000
Subject: [New-bugs-announce] [issue7802] socket.gaierror before
	ProtocolError for xmlrpc.client
In-Reply-To: <1264727901.97.0.79188131386.issue7802@psf.upfronthosting.co.za>
Message-ID: <1264727901.97.0.79188131386.issue7802@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

Following the example in Section 20.23.5. ProtocolError Objects of:
http://docs.python.org/3.1/library/xmlrpc.client.html
It implies that an invalid URL will give raise an xmlrpc.client.ProtocolError. Instead I'm getting a socket.gaierror instead. (I also tried using the google address to show tat ProtocolError is working correctly if a real URL is used, but doesn't offer XML-RPC services.) This similarly is happening for xmlrpclib on Python 2.6.

Is this a bug or documentation mistake?

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpc.client
>>> proxy = xmlrpc.client.ServerProxy("http://invalidaddress/")
>>> proxy.some_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python31\lib\xmlrpc\client.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "C:\python31\lib\xmlrpc\client.py", line 1271, in __request
    verbose=self.__verbose
  File "C:\python31\lib\xmlrpc\client.py", line 1058, in request
    http_conn = self.send_request(host, handler, request_body, verbose)
  File "C:\python31\lib\xmlrpc\client.py", line 1144, in send_request
    connection.request("POST", handler, request_body, headers)
  File "C:\python31\lib\http\client.py", line 918, in request
    self._send_request(method, url, body, headers)
  File "C:\python31\lib\http\client.py", line 956, in _send_request
    self.endheaders(body)
  File "C:\python31\lib\http\client.py", line 914, in endheaders
    self._send_output(message_body)
  File "C:\python31\lib\http\client.py", line 768, in _send_output
    self.send(msg)
  File "C:\python31\lib\http\client.py", line 716, in send
    self.connect()
  File "C:\python31\lib\http\client.py", line 698, in connect
    self.timeout)
  File "C:\python31\lib\socket.py", line 292, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno 11001] getaddrinfo failed
>>> proxy = xmlrpc.client.ServerProxy("http://www.google.com/")
>>> proxy.some_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python31\lib\xmlrpc\client.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "C:\python31\lib\xmlrpc\client.py", line 1271, in __request
    verbose=self.__verbose
  File "C:\python31\lib\xmlrpc\client.py", line 1065, in request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for www.google.com/: 405 Method Not Allowed>
>>>

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib
>>> proxy = xmlrpclib.ServerProxy("http://invalidaddress/")
>>> proxy.some_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python26\lib\xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "C:\python26\lib\xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "C:\python26\lib\xmlrpclib.py", line 1235, in request
    self.send_content(h, request_body)
  File "C:\python26\lib\xmlrpclib.py", line 1349, in send_content
    connection.endheaders()
  File "C:\python26\lib\httplib.py", line 892, in endheaders
    self._send_output()
  File "C:\python26\lib\httplib.py", line 764, in _send_output
    self.send(msg)
  File "C:\python26\lib\httplib.py", line 723, in send
    self.connect()
  File "C:\python26\lib\httplib.py", line 704, in connect
    self.timeout)
  File "C:\python26\lib\socket.py", line 500, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno 11001] getaddrinfo failed
>>> proxy = xmlrpclib.ServerProxy("http://www.google.com/")
>>> proxy.some_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python26\lib\xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "C:\python26\lib\xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "C:\python26\lib\xmlrpclib.py", line 1243, in request
    headers
xmlrpclib.ProtocolError: <ProtocolError for www.google.com/: 405 Method Not Allowed>

I also checked Python 3.1 on Linux:

Python 3.1.1 (r311:74480, Oct 18 2009, 19:21:53) [GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpc.client
>>> proxy = xmlrpc.client.ServerProxy("http://invalidaddress/")
>>> proxy.some_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1271, in __request
    verbose=self.__verbose
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1058, in request
    http_conn = self.send_request(host, handler, request_body, verbose)
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1144, in send_request
    connection.request("POST", handler, request_body, headers)
  File "/usr/local/lib/python3.1/http/client.py", line 918, in request
    self._send_request(method, url, body, headers)
  File "/usr/local/lib/python3.1/http/client.py", line 956, in _send_request
    self.endheaders(body)
  File "/usr/local/lib/python3.1/http/client.py", line 914, in endheaders
    self._send_output(message_body)
  File "/usr/local/lib/python3.1/http/client.py", line 768, in _send_output
    self.send(msg)
  File "/usr/local/lib/python3.1/http/client.py", line 716, in send
    self.connect()
  File "/usr/local/lib/python3.1/http/client.py", line 698, in connect
    self.timeout)
  File "/usr/local/lib/python3.1/socket.py", line 292, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno -2] Name or service not known
>>> proxy = xmlrpc.client.ServerProxy("http://www.google.com/")
>>> proxy.some_method()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1271, in __request
    verbose=self.__verbose
  File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1065, in request
    dict(resp.getheaders())
xmlrpc.client.ProtocolError: <ProtocolError for www.google.com/: 405 Method Not Allowed>

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 98493
nosy: georg.brandl, mnewman
severity: normal
status: open
title: socket.gaierror before ProtocolError for xmlrpc.client
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Jan 29 11:42:45 2010
From: report at bugs.python.org (Dan Simmons)
Date: Fri, 29 Jan 2010 10:42:45 +0000
Subject: [New-bugs-announce] [issue7803] setup hangs on disk space
	requirements
In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>
Message-ID: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>


New submission from Dan Simmons <sentai360 at yahoo.com>:

I tried to install windows binary and the setup hanged up on 'determining disk space requirements' I waited over two hours for this to finish, and the light blinked in a syncrinised pattern that led me to believe something was wrong. So I have since restarted it and the light is blinking differently this time. Hope it works.

----------
messages: 98503
nosy: abilify
severity: normal
status: open
title: setup hangs on disk space requirements
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 29 15:01:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2010 14:01:37 +0000
Subject: [New-bugs-announce] [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>


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

This is a fresh py3k checkout on a fresh Debian Lenny install:

======================================================================
ERROR: testHistoryUpdates (test.test_readline.TestHistoryManipulation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/py3k/Lib/test/test_readline.py", line 16, in testHistoryUpdates
    readline.clear_history()
AttributeError: 'module' object has no attribute 'clear_history'

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

----------
components: Library (Lib)
messages: 98508
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_readline failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jan 29 15:02:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2010 14:02:40 +0000
Subject: [New-bugs-announce] [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>


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

This is a fresh py3k checkout on a fresh Debian Lenny install:

======================================================================
ERROR: test_pool_worker_lifetime (test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/py3k/Lib/test/test_multiprocessing.py", line 1076, in test_pool_worker_lifetime
    self.assertNotEqual(sorted(origworkerpids), sorted(finalworkerpids))
TypeError: unorderable types: NoneType() < int()

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

----------
components: Library (Lib)
messages: 98509
nosy: jnoller, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jan 29 16:01:51 2010
From: report at bugs.python.org (Robert Buchholz)
Date: Fri, 29 Jan 2010 15:01:51 +0000
Subject: [New-bugs-announce] [issue7806] httplib.HTTPConnection.getresponse
	closes socket which	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>


New submission from Robert Buchholz <rbu at freitagsrunde.org>:

Calling getresponse() on an httplib.HTTPConnection object returns a response object. Internally, the self.sock is handed over to the HTTPResponse object which transforms it into a file-like object. The response object is returned to the caller. If one calls response.read() later on, no or incomplete content will be returned because the underlying socket has been closed.

The code path, simplified:

class HTTPConnection:

    def getresponse(self):
            response = self.response_class(self.sock, ...)
            ...
            if response.will_close:
                # this effectively passes the connection to the response
                self.close()

    def close(self):
        if self.sock:
            self.sock.close()
        ...

class HTTPResponse:
    def __init__(self, sock, debuglevel=0, strict=0, method=None):
        self.fp = sock.makefile('rb', 0)
        ...

----------
components: Library (Lib)
messages: 98513
nosy: Robert.Buchholz
severity: normal
status: open
title: httplib.HTTPConnection.getresponse closes socket which destroys the response
versions: Python 2.6

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

From report at bugs.python.org  Fri Jan 29 18:57:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 17:57:45 +0000
Subject: [New-bugs-announce] [issue7807] test_macostools fails on OS X 10.6:
	no attribute 'FSSpec'
In-Reply-To: <1264787865.0.0.0322335198663.issue7807@psf.upfronthosting.co.za>
Message-ID: <1264787865.0.0.0322335198663.issue7807@psf.upfronthosting.co.za>


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

I've been seeing the following test failure for trunk and release26-maint for a while, on OS X 10.6, on a relatively recent Macbook Pro (clean installation of Snow Leopard).  This is from a non-framework debug build (i.e., a simple ./configure && make).


Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ ./python.exe Lib/test/test_macostools.py
test_copy (__main__.TestMacostools) ... ERROR
test_mkalias (__main__.TestMacostools) ... ERROR
test_mkalias_relative (__main__.TestMacostools) ... ERROR
test_touched (__main__.TestMacostools) ... ok

======================================================================
ERROR: test_copy (__main__.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_macostools.py", line 67, in test_copy
    macostools.copy(test_support.TESTFN, TESTFN2)
  File "/Users/dickinsm/python/svn/trunk/Lib/plat-mac/macostools.py", line 114, in copy
    srcfss = File.FSSpec(src)
AttributeError: 'module' object has no attribute 'FSSpec'

======================================================================
ERROR: test_mkalias (__main__.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_macostools.py", line 75, in test_mkalias
    macostools.mkalias(test_support.TESTFN, TESTFN2)
  File "/Users/dickinsm/python/svn/trunk/Lib/plat-mac/macostools.py", line 46, in mkalias
    dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'

======================================================================
ERROR: test_mkalias_relative (__main__.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_macostools.py", line 90, in test_mkalias_relative
    macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix)
  File "/Users/dickinsm/python/svn/trunk/Lib/plat-mac/macostools.py", line 46, in mkalias
    dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'

----------------------------------------------------------------------
Ran 4 tests in 0.026s

FAILED (errors=3)
Traceback (most recent call last):
  File "Lib/test/test_macostools.py", line 103, in <module>
    test_main()
  File "Lib/test/test_macostools.py", line 99, in test_main
    test_support.run_unittest(TestMacostools)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 901, in run_unittest
    _run_suite(suite)
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_support.py", line 884, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred
[31769 refs]


There's nothing glaringly obviously wrong in the build log.

----------
assignee: ronaldoussoren
components: Macintosh, Tests
messages: 98520
nosy: mark.dickinson, ronaldoussoren
severity: normal
status: open
title: test_macostools fails on OS X 10.6: no attribute 'FSSpec'
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jan 29 19:42:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 18:42:57 +0000
Subject: [New-bugs-announce] [issue7808] test_bsddb3 leaks references
Message-ID: <1264790577.47.0.195517886287.issue7808@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: Extension Modules
nosy: flox
priority: normal
severity: normal
status: open
title: test_bsddb3 leaks references
type: performance
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Jan 30 07:05:55 2010
From: report at bugs.python.org (Justin Lebar)
Date: Sat, 30 Jan 2010 06:05:55 +0000
Subject: [New-bugs-announce] [issue7809] Documentation for random module
	should indicate that a	call to seed() is not required
In-Reply-To: <1264831555.46.0.0569271351012.issue7809@psf.upfronthosting.co.za>
Message-ID: <1264831555.46.0.0569271351012.issue7809@psf.upfronthosting.co.za>


New submission from Justin Lebar <starwiz at gmail.com>:

Many programmers are used to languages where the RNG is deterministic unless it's explicitly seeded.  This does not appear to be the case in Python.

The documentation for random should indicate that Random objects are seeded on construction, and that the global random object is seeded when the random package is first imported.

http://docs.python.org/3.1/library/random.html

----------
assignee: georg.brandl
components: Documentation
messages: 98551
nosy: Justin.Lebar, georg.brandl
severity: normal
status: open
title: Documentation for random module should indicate that a call to seed() is not required

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

From report at bugs.python.org  Sat Jan 30 13:53:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Jan 2010 12:53:43 +0000
Subject: [New-bugs-announce] [issue7810] fix_callable breakage
In-Reply-To: <1264856023.16.0.865675766394.issue7810@psf.upfronthosting.co.za>
Message-ID: <1264856023.16.0.865675766394.issue7810@psf.upfronthosting.co.za>


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

For the attached script, 2to3 reports  
File "/tmp/lib/python3.1/lib2to3/pytree.py", line 135, in replace
    assert self.parent is not None, str(self)
AssertionError: def a(self):
        pass

This was originally discovered for twisted/trial/test/test_pyunitcompat.py.

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: a.py
messages: 98561
nosy: loewis
severity: normal
status: open
title: fix_callable breakage
versions: Python 3.1
Added file: http://bugs.python.org/file16056/a.py

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

From report at bugs.python.org  Sat Jan 30 15:16:18 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 30 Jan 2010 14:16:18 +0000
Subject: [New-bugs-announce] [issue7811] [decimal] ValueError -> TypeError
	in from_tuple
In-Reply-To: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>
Message-ID: <1264860978.2.0.856934311743.issue7811@psf.upfronthosting.co.za>


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

As discussed privately, the following test cases should raise TypeError
(currently ValueError):

self.assertRaises(TypeError, Decimal, (0., (4, 3, 4, 9, 1), 2) )
self.assertRaises(TypeError, Decimal, (Decimal(1), (4, 3, 4, 9, 1), 2))
self.assertRaises(TypeError, Decimal, (1, (4, 3, 4, 9, 1), 0.) )
self.assertRaises(TypeError, Decimal, (1, (4, 3, 4, None, 1), 2) )
self.assertRaises(TypeError, Decimal, (1, (4, 3, 4, 'a', 1), 2) )

----------
messages: 98564
nosy: mark.dickinson, skrah
severity: normal
status: open
title: [decimal] ValueError -> TypeError in from_tuple

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

From report at bugs.python.org  Sat Jan 30 16:54:28 2010
From: report at bugs.python.org (Peter Hansen)
Date: Sat, 30 Jan 2010 15:54:28 +0000
Subject: [New-bugs-announce] [issue7812] Call to gestalt('sysu') on
Message-ID: <1264866868.57.0.410323231268.issue7812@psf.upfronthosting.co.za>


Changes by Peter Hansen <peter at engcorp.com>:


----------
nosy: phansen
severity: normal
status: open
title: Call to gestalt('sysu') on
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jan 30 16:59:14 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 30 Jan 2010 15:59:14 +0000
Subject: [New-bugs-announce] [issue7813] Bug of command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>


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

I have a weird behaviour of the interpreter on my python2.6 win32 install : if I launch as __main__ the file joined below, like "python test_rsFileLocking.py", all works fine.
But if I put it in my PYTHONPATH (or current working directory), and launch it via the "-m" option of python.exe, I get this unexplanatory traceback below.
How comes the syntax analyser is not the same in both cases ? I don't what what, in this file, could give syntax errors in the latter case...


C:\Users\Pakal\Desktop\release26-maint\PCbuild>python.exe -m rstest.test_rsFileLocking
Traceback (most recent call last):
  File "C:\Users\Pakal\Desktop\release26-maint\lib\runpy.py", line 104, in _run_module_as_main
    loader, code, fname = _get_module_details(mod_name)
  File "C:\Users\Pakal\Desktop\release26-maint\lib\runpy.py", line 85, in _get_module_details
    code = loader.get_code(mod_name)
  File "C:\Users\Pakal\Desktop\release26-maint\lib\pkgutil.py", line 275, in get_code
    self.code = compile(source, self.filename, 'exec')
  File "C:\Users\Pakal\Desktop\RockSolidTools\rstest\test_rsFileLocking.py", line 391

SyntaxError: invalid syntax

----------
components: Interpreter Core
files: test_rsFileLocking.py
messages: 98566
nosy: pakal
severity: normal
status: open
title: Bug of command-line module launcher
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file16057/test_rsFileLocking.py

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

From report at bugs.python.org  Sat Jan 30 17:23:40 2010
From: report at bugs.python.org (Michael Newman)
Date: Sat, 30 Jan 2010 16:23:40 +0000
Subject: [New-bugs-announce] [issue7814] SimpleXMLRPCServer Example uses
	"mul" instead of "div" in	client portion
In-Reply-To: <1264868620.27.0.112538070165.issue7814@psf.upfronthosting.co.za>
Message-ID: <1264868620.27.0.112538070165.issue7814@psf.upfronthosting.co.za>


New submission from Michael Newman <michael.b.newman at gmail.com>:

In "20.24.1.1. SimpleXMLRPCServer Example":
http://docs.python.org/3.1/library/xmlrpc.server.html

The client portion of the example uses "mul", which does not exist in the server portion. The easiest fix to change the client to use "div" instead of "mul".

# Attempt to use client code exactly as provided:
# Python 3.1.1 (r311:74483) on win32
E:\notes\Programming\python3\lib\xmlrpc.server>py31 example1_xmlrpc_client.py
8
5
Traceback (most recent call last):
  File "example1_xmlrpc_client.py", line 11, in <module>
    print(s.mul(5,2))  # Returns 5*2 = 10
  File "C:\python31\lib\xmlrpc\client.py", line 1029, in __call__
    return self.__send(self.__name, args)
  File "C:\python31\lib\xmlrpc\client.py", line 1271, in __request
    verbose=self.__verbose
  File "C:\python31\lib\xmlrpc\client.py", line 1070, in request
    return self.parse_response(resp)
  File "C:\python31\lib\xmlrpc\client.py", line 1169, in parse_response
    return u.close()
  File "C:\python31\lib\xmlrpc\client.py", line 673, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault 1: '<class \'Exception\'>:method "mul" is not supported'>

To fix it, I changed this line in the client code:

print(s.mul(5,2))  # Returns 5*2 = 10

to:

print(s.div(8,2))  # Returns 8/2 = 4

# Here's how it now looks after the suggested fix:
E:\notes\Programming\python3\lib\xmlrpc.server>py31 example1_xmlrpc_client_rev1.
py
8
5
4
['add', 'div', 'pow', 'system.listMethods', 'system.methodHelp', 'system.methodSignature']

----------
assignee: georg.brandl
components: Documentation
messages: 98567
nosy: georg.brandl, mnewman
severity: normal
status: open
title: SimpleXMLRPCServer Example uses "mul" instead of "div" in client portion
versions: Python 3.1

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

From report at bugs.python.org  Sat Jan 30 19:00:50 2010
From: report at bugs.python.org (Martin)
Date: Sat, 30 Jan 2010 18:00:50 +0000
Subject: [New-bugs-announce] [issue7815] Regression in unittest traceback
	formating extensibility
In-Reply-To: <1264874450.07.0.188014948494.issue7815@psf.upfronthosting.co.za>
Message-ID: <1264874450.07.0.188014948494.issue7815@psf.upfronthosting.co.za>


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

Prior to being split up into a package, unittest had an extensible method of trimming uninteresting, testing-framework related parts from tracebacks. As an unintended side effect, this is no longer the case, only modules actually named "unittest" are excluded. Code depending on the old method exists in a number of different projects, and there is no benefit to breaking them.

More details and discussion of this issue on python-dev can be read at:
<http://mail.python.org/pipermail/python-dev/2009-December/094734.html>

Reverting this change is trivial, something along the lines of:

--- old/Lib/unittest/case.py
+++ new/Lib/unittest/case.py
@@ -9,7 +9,9 @@
 
 from . import result, util
 
+__unittest = True
 
+
 class SkipTest(Exception):
     """
     Raise this exception in a test to skip it.
--- old/Lib/unittest/result.py
+++ new/Lib/unittest/result.py
@@ -94,11 +94,7 @@
         return ''.join(traceback.format_exception(exctype, value, tb))
 
     def _is_relevant_tb_level(self, tb):
-        globs = tb.tb_frame.f_globals
-        is_relevant =  '__name__' in globs and \
-            globs["__name__"].startswith("unittest")
-        del globs
-        return is_relevant
+        return tb.tb_frame.f_globals.has_key('__unittest')
 
     def _count_relevant_tb_levels(self, tb):
         length = 0

----------
components: Library (Lib)
messages: 98573
nosy: gz
severity: normal
status: open
title: Regression in unittest traceback formating extensibility
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jan 31 00:20:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 23:20:05 +0000
Subject: [New-bugs-announce] [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

test test_capi crashed -- <class 'AssertionError'>: PyDateTime_CAPI somehow initialized
1 test failed:


It was introduced in r76824.
It may be fixed with something like r72357.

----------
components: Tests
messages: 98579
nosy: benjamin.peterson, flox
priority: normal
severity: normal
status: open
title: test_capi crashes when run with "-R"
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan 31 02:44:57 2010
From: report at bugs.python.org (Dan)
Date: Sun, 31 Jan 2010 01:44:57 +0000
Subject: [New-bugs-announce] [issue7817] Pythonw.exe fails to start
In-Reply-To: <1264902297.56.0.0341617742607.issue7817@psf.upfronthosting.co.za>
Message-ID: <1264902297.56.0.0341617742607.issue7817@psf.upfronthosting.co.za>


New submission from Dan <10equals8 at gmail.com>:

Pythonw.exe refuses to start on my Windows 7 x64 computer.  I don't get any kind of error message (i.e. "pythonw.exe has stopped working"), it simply doesn't open.  python.exe works fine.

Attached is a Windows Debugger analysis log, I can also provide a Process Monitor log if it would be helpful (shows all the file registry access attempts by the program).

----------
components: Build
files: windbg-python.txt
messages: 98587
nosy: ZDan
severity: normal
status: open
title: Pythonw.exe fails to start
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file16062/windbg-python.txt

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

From report at bugs.python.org  Sun Jan 31 04:12:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:12:22 +0000
Subject: [New-bugs-announce] [issue7818] Improve set().test_c_api(): don't
	expect a set("abc"), modify the content
In-Reply-To: <1264907542.03.0.152611089844.issue7818@psf.upfronthosting.co.za>
Message-ID: <1264907542.03.0.152611089844.issue7818@psf.upfronthosting.co.za>


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

test_c_api() method of a set() (only defined in pydebug mode) suppose that the set content is "abc". It causes assertion error if the method is called in a set different than set("abc").

My patch modifies the set content at the beginning of the test.

----------
files: set_test_c_api.patch
keywords: patch
messages: 98596
nosy: haypo
severity: normal
status: open
title: Improve set().test_c_api(): don't expect a set("abc"), modify the content
Added file: http://bugs.python.org/file16064/set_test_c_api.patch

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

From report at bugs.python.org  Sun Jan 31 04:16:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:16:50 +0000
Subject: [New-bugs-announce] [issue7819] sys.call_tracing(): check arguments
	type
In-Reply-To: <1264907810.16.0.644202807752.issue7819@psf.upfronthosting.co.za>
Message-ID: <1264907810.16.0.644202807752.issue7819@psf.upfronthosting.co.za>


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

Ensure that "args" argument is a tuple. Fix the following crash:

        $ python -c "import sys; sys.call_tracing(open, u'a')"
        SystemError: ../Python/getargs.c:1413: bad argument to internal function

----------
components: Interpreter Core
files: sys_call_tracing.patch
keywords: patch
messages: 98598
nosy: haypo
severity: normal
status: open
title: sys.call_tracing(): check arguments type
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16066/sys_call_tracing.patch

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

From report at bugs.python.org  Sun Jan 31 04:24:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:24:23 +0000
Subject: [New-bugs-announce] [issue7820] parser: restores all bytes in the
	right order if	check_bom() fails
In-Reply-To: <1264908263.1.0.898518004348.issue7820@psf.upfronthosting.co.za>
Message-ID: <1264908263.1.0.898518004348.issue7820@psf.upfronthosting.co.za>


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

My patch fixes check_bom() to restore all bytes in the right order if there is no BOM to leave the stream unchanged and to fix an assertion error in buf_ungetc() (raised in pydebug mode).

The current code only unget one byte (0xFF), even if two or three bytes are read. I suppose that check_bom() writes any non-ASCII byte, because such byte will raise a SyntaxError.

----------
files: parser_restore_bom.patch
keywords: patch
messages: 98599
nosy: haypo
severity: normal
status: open
title: parser: restores all bytes in the right order if check_bom() fails
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file16067/parser_restore_bom.patch

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

From report at bugs.python.org  Sun Jan 31 07:31:30 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 31 Jan 2010 06:31:30 +0000
Subject: [New-bugs-announce] [issue7821] Command line option -U not
	documented
In-Reply-To: <1264919490.48.0.0177386547442.issue7821@psf.upfronthosting.co.za>
Message-ID: <1264919490.48.0.0177386547442.issue7821@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve at pearwood.info>:

There is a command line switch -U (uppercase U) which is mentioned in PEP 3147 http://www.python.org/dev/peps/pep-3147/ but doesn't appear to be documented anywhere.

It is listed here, but not described:

http://docs.python.org/using/cmdline.html

Nor does it appear in the output of pythonX --help for X in 2.5, 2.6 and 3.1.

----------
assignee: georg.brandl
components: Documentation
messages: 98607
nosy: georg.brandl, stevenjd
severity: normal
status: open
title: Command line option -U not documented
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Sun Jan 31 18:00:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 31 Jan 2010 17:00:18 +0000
Subject: [New-bugs-announce] [issue7822] 2to3 does not convert output lines
	in doctests
In-Reply-To: <1264957218.46.0.892120848573.issue7822@psf.upfronthosting.co.za>
Message-ID: <1264957218.46.0.892120848573.issue7822@psf.upfronthosting.co.za>


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

Howdy

I think there is a bug with 2to3?s doctest conversion:

$ echo ">>> u'?ric'" > test
$ echo "u'?ric'" >> test
$ 2to3 -d test -f unicode
--- test (original)
+++ test (refactored)
@@ -1,3 +1,3 @@
->>> u'?ric'
+>>> '?ric'
 u'?ric'
 
RefactoringTool: Files that need to be modified:
RefactoringTool: test


The output should be converted too.

Tested with 2.6.4+ (Debian?s), 2.7a2+ and 3.2a0.

Kind regards

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 98620
nosy: Merwok
severity: normal
status: open
title: 2to3 does not convert output lines in doctests
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jan 31 22:18:27 2010
From: report at bugs.python.org (Andrew Hays)
Date: Sun, 31 Jan 2010 21:18:27 +0000
Subject: [New-bugs-announce] [issue7823] multiplying a list of dictionaries
In-Reply-To: <1264972707.42.0.603624170105.issue7823@psf.upfronthosting.co.za>
Message-ID: <1264972707.42.0.603624170105.issue7823@psf.upfronthosting.co.za>


New submission from Andrew Hays <me at andrewhays.net>:

[{}]*3 should produce a list of dictionaries that are 3 length long, which it does.  However, one would expect that if you assign something to the keyword 'abc' in the first dicitonary (e.g., x[0]['abc'] = 'def') that the other dictionaries would remain blank (e.g.,  x = [{'abc': 'def'}, {}, {}].  However, it appears that each dictionary is filled (e.g., x = [{'abc':'def'}, {'abc':'def'}, {'abc':'def'}]).

Creating a list of dictionaries like this [{}, {}, {}] or appending a dictionary to a list like this list.append({}) does NOT produce this same effect, it produces the desired effect.

----------
components: Build
messages: 98628
nosy: Andrew.Hays
severity: normal
status: open
title: multiplying a list of dictionaries
versions: Python 2.7, Python 3.1

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