From report at bugs.python.org  Fri Jan  1 03:57:00 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 01 Jan 2010 02:57:00 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1262314620.46.0.122470605402.issue6943@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The previous patches don't work with Python 3, in which os.popen()
internally uses subprocess.Popen(), and also don't work during
crosscompilation, so I'm attaching the new patch.

----------
Added file: http://bugs.python.org/file15715/python-fix_search_for_libffi_headers.patch

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

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: [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:04:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Jan 2010 05:04:30 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262322270.03.0.168748143195.issue7615@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Fri Jan  1 06:38:08 2010
From: report at bugs.python.org (ivank)
Date: Fri, 01 Jan 2010 05:38:08 +0000
Subject: [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: [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 14:43:18 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 01 Jan 2010 13:43:18 +0000
Subject: [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: <1262353398.0.0.751525687395.issue7617@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

This bug tracker removes parts of splitted, long lines when the
previous line was ending with '-' :( .

There should be:

"but it doesn't recognize "${configuration_name}-gcc"
(e.g. "x86_64-pc-linux-gnu-gcc") or
"${configuration_name}-gcc-${version}"
(e.g. "x86_64-pc-linux-gnu-gcc-4.4.2")."

The second URL has 2 parts:
http://www.gnu.org/software/autoconf/manual/html_node/
Specifying-Target-Triplets.html

----------

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

From report at bugs.python.org  Fri Jan  1 15:08:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jan 2010 14:08:37 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262354917.68.0.94175010044.issue7615@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Jan  1 16:16:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Jan 2010 15:16:53 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1262359013.09.0.219308175639.issue6943@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77212.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Jan  1 17:12:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Jan 2010 16:12:36 +0000
Subject: [issue6491] Improve --with-dbmliborder option
In-Reply-To: <1247678287.04.0.431591668248.issue6491@psf.upfronthosting.co.za>
Message-ID: <1262362356.46.0.579441233942.issue6491@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Applied in r77215.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Fri Jan  1 18:29:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Jan 2010 17:29:51 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1262366991.7.0.584961476623.issue5080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied to trunk in r77218.  The DeprecationWarning for the 'L' format 
needs to be merged to py3k.

----------
versions: +Python 3.2

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

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: [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 20:30:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Jan 2010 19:30:05 +0000
Subject: [issue5080] PyArg_Parse* should raise TypeError for float parsed with
	integer format
In-Reply-To: <1233059037.74.0.384834765102.issue5080@psf.upfronthosting.co.za>
Message-ID: <1262374205.99.0.352589929323.issue5080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged relevant bits to py3k in r77220.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

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: [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  Fri Jan  1 23:43:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 01 Jan 2010 22:43:27 +0000
Subject: [issue7564] test_ioctl fails when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1262385807.68.0.0928739561358.issue7564@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It fails if the test is run in background, and there's another process
in foreground.

Example 1:

~ $ (./python Lib/test/regrtest.py test_ioctl &) && tail -f /dev/null
test_ioctl
test test_ioctl failed -- multiple errors occurred; run in verbose mode
for details
1 test failed:
    test_ioctl


Example 2 (a shell script):

~ $ cat run_ioctl.sh
#!/bin/sh
./python Lib/test/regrtest.py -v test_ioctl > test_ioctl.log &
tail -f test_ioctl.log

----------
priority:  -> low
title: test_ioctl fails sometimes -> test_ioctl fails when run in background
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jan  1 23:43:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 01 Jan 2010 22:43:47 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1262385827.7.0.697277951549.issue7564@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: test_ioctl fails when run in background -> test_ioctl may fail when run in background

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

From report at bugs.python.org  Sat Jan  2 00:28:08 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Jan 2010 23:28:08 +0000
Subject: [issue7578] Behavior of operations on a closed file object is not
	documented correctly
In-Reply-To: <1261860516.82.0.572008344206.issue7578@psf.upfronthosting.co.za>
Message-ID: <1262388488.93.0.18943969561.issue7578@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that one of the reasons for the slightly wishy-washy phrasing in
the docs is to give other implementations a bit more freedom in the way
way they handle these error cases.

Agreed that the main reason is the one Antoine gave though - the
ValueError is looking at things from the point of view that the program
passed in a closed file object when an open one was needed.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Sat Jan  2 03:43:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Jan 2010 02:43:40 +0000
Subject: [issue7619] imaplib shouldn't use cause DeprecationWarnings in 2.6
In-Reply-To: <1262384572.13.0.48856105393.issue7619@psf.upfronthosting.co.za>
Message-ID: <1262400220.23.0.420341714791.issue7619@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77222.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Jan  2 05:18:11 2010
From: report at bugs.python.org (cadf)
Date: Sat, 02 Jan 2010 04:18:11 +0000
Subject: [issue7611] shlex not posix compliant when parsing "foo#bar"
In-Reply-To: <1262248963.08.0.673944744724.issue7611@psf.upfronthosting.co.za>
Message-ID: <1262405891.78.0.597464076698.issue7611@psf.upfronthosting.co.za>


cadf <chargoddard at gmail.com> added the comment:

Here's a patch addressing the behavior described.

----------
keywords: +patch
nosy: +cadf
Added file: http://bugs.python.org/file15718/shlex_posix.diff

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

From report at bugs.python.org  Sat Jan  2 10:05:09 2010
From: report at bugs.python.org (djc)
Date: Sat, 02 Jan 2010 09:05:09 +0000
Subject: [issue7619] imaplib shouldn't use cause DeprecationWarnings in 2.6
In-Reply-To: <1262384572.13.0.48856105393.issue7619@psf.upfronthosting.co.za>
Message-ID: <1262423109.45.0.267640249395.issue7619@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

Awesome, thanks! Will this be ported to the 2.6.x branch?

----------

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

From report at bugs.python.org  Sat Jan  2 11:55:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Jan 2010 10:55:10 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1262429710.58.0.75519157631.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The last two functions to consider adding are exp2 and log2.  Does anyone 
care about these?

----------

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

From report at bugs.python.org  Sat Jan  2 15:21:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Jan 2010 14:21:06 +0000
Subject: [issue7619] imaplib shouldn't use cause DeprecationWarnings in 2.6
In-Reply-To: <1262423109.45.0.267640249395.issue7619@psf.upfronthosting.co.za>
Message-ID: <1afaf6161001020621i25e4a2e2g8d843b911c65d1b1@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/1/2 djc <report at bugs.python.org>:
>
> djc <dirkjan at ochtman.nl> added the comment:
>
> Awesome, thanks! Will this be ported to the 2.6.x branch?

It already is.

----------

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

From report at bugs.python.org  Sat Jan  2 15:28:35 2010
From: report at bugs.python.org (anders musikka)
Date: Sat, 02 Jan 2010 14:28:35 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1262442515.52.0.313147881556.issue1759169@psf.upfronthosting.co.za>


anders musikka <anders.musikka at gmail.com> added the comment:

Just wanted to chip in my $.02: 

Defining _XOPEN_SOURCE in the python headers causes problems for
Solaris. It also causes problems for Ubuntu Linux.

Because _XOPEN_SOURCE is defined, Python.h must included first in any
program under Ubuntu.

Perhaps the right fix is to just not define _XOPEN_SOURCE at all? Which
platforms disable important features when you don't define _XOPEN_SOURCE?

Sometimes there are standards which nobody follows. In such cases it can
be advantageous to "just do what everyone expects".

----------
nosy: +avl

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

From report at bugs.python.org  Sat Jan  2 15:46:44 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 02 Jan 2010 14:46:44 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <4B3F5C50.2010607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Richard Hansen wrote:
> 
> 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

Indeed. Python only uses the decoder of that codec internally.

> 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.

If we change this, the encoder should quote both single and double
quotes - simply because it is not known whether the literal
will use single or double quotes.

The raw_unicode_escape codec would have to be fixed as well.

----------

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

From report at bugs.python.org  Sat Jan  2 15:48:16 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 02 Jan 2010 14:48:16 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1262443696.42.0.868341806014.issue3366@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Any time I've ever needed log2(x), log(x)/log(2) was sufficient.

In Python, exp2(x) can be spelled 2.0**x.  What would exp2(x) gain us?

----------

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

From report at bugs.python.org  Sat Jan  2 15:51:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jan 2010 14:51:30 +0000
Subject: [issue7592] ssl module documentation: SSLSocket.unwrap description
	shown twice
In-Reply-To: <1262044524.74.0.400601888714.issue7592@psf.upfronthosting.co.za>
Message-ID: <1262443890.92.0.546734877463.issue7592@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r77236.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Jan  2 15:58:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Jan 2010 14:58:59 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1262444339.73.0.832266824422.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> In Python, exp2(x) can be spelled 2.0**x.  What would exp2(x) gain us?

Not much, I suspect.  :)

I'd expect (but am mostly guessing) exp2(x) to have better accuracy than 
pow(2.0, x) for some math libraries;  I'd further guess that it's somewhat 
more likely to give exact results for (small) integral x.

Similarly for log2:  log2(n) should be a touch more accurate than 
log(n)/log(2), and the time you're most likely to notice the difference is 
when n is an exact power of 2.

But we've already got the 'bit_length' method for integers, which fills 
some of the potential uses for log2.  So unless there's a feeling that 
these functions are needed, I'd rather leave them out.

----------

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

From report at bugs.python.org  Sat Jan  2 16:10:15 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 02 Jan 2010 15:10:15 +0000
Subject: [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 16:18:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jan 2010 15:18:55 +0000
Subject: [issue1619] Test
In-Reply-To: <1262445535.56.0.411742352473.issue1619@psf.upfronthosting.co.za>
Message-ID: <1262445535.56.0.411742352473.issue1619@psf.upfronthosting.co.za>


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

Testing submission of long lines:
http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Target-Triplets.html

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-
Target-Triplets.html

http://www.gnu.org/software/autoconf/manual/html_node/Specifyin
g-Target-Triplets.html

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Jan  2 16:35:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Jan 2010 15:35:56 +0000
Subject: [issue5576] Don't use PyLong_SHIFT with _PyLong_AsScaledDouble()
In-Reply-To: <1238113402.96.0.541162373186.issue5576@psf.upfronthosting.co.za>
Message-ID: <1262446556.62.0.820652345997.issue5576@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r77234 (trunk), r77237 (py3k).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.1

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

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: [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  Sat Jan  2 17:49:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jan 2010 16:49:14 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262450954.41.0.635589652188.issue7621@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Jan  2 17:52:31 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 02 Jan 2010 16:52:31 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262451151.33.0.180868023124.issue7621@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Target-Triplets.html

----------
nosy: +Arfrever

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

From report at bugs.python.org  Sat Jan  2 17:53:15 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 02 Jan 2010 16:53:15 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262451195.55.0.518322484615.issue7621@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-

----------

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

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


Georg Brandl <georg at python.org> added the comment:

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Target-

----------

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

From report at bugs.python.org  Sat Jan  2 17:57:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Jan 2010 16:57:41 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262451461.15.0.301546074883.issue7621@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Target-

---

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Target-

---

http://www.gnu.org/software/autoconf/manual/html_node/Specifying-Target-

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Jan  2 17:59:43 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Jan 2010 16:59:43 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262451583.02.0.273682332066.issue7621@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

'aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggggghh

----------

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

From report at bugs.python.org  Sat Jan  2 19:41:54 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 02 Jan 2010 18:41:54 +0000
Subject: [issue7618] optparse library documentation has an insignificant
	formatting issue
In-Reply-To: <1262371550.06.0.14749743487.issue7618@psf.upfronthosting.co.za>
Message-ID: <1262457714.67.0.968740230078.issue7618@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

Also, I found 4 similar problems in this text (seach 'usage:' to find 
them).

These are resolved in this patch.

----------
keywords: +patch
nosy: +July
Added file: http://bugs.python.org/file15720/doc-library-optparse.diff

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

From report at bugs.python.org  Sat Jan  2 19:48:01 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jan 2010 18:48:01 +0000
Subject: [issue7618] optparse library documentation has an insignificant
	formatting issue
In-Reply-To: <1262371550.06.0.14749743487.issue7618@psf.upfronthosting.co.za>
Message-ID: <1262458081.41.0.328032927314.issue7618@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Jan  2 20:05:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Jan 2010 19:05:47 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262451583.02.0.273682332066.issue7621@psf.upfronthosting.co.za>
Message-ID: <4B3F987F.2030906@gmail.com>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

More testing:
'aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggggghhhhhhhhhhiiiiiiiiiijjjjjjjjjjkkkkkkkkkk'

----------

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

From report at bugs.python.org  Sat Jan  2 20:13:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Jan 2010 19:13:10 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1262459590.22.0.449009499267.issue7621@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

http://psf.upfronthosting.co.za/roundup/meta/issue309

----------

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

From report at bugs.python.org  Sat Jan  2 21:41:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Jan 2010 20:41:44 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262464904.72.0.854898260548.issue7462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've added a version number to stringbench and committed the changes in r77240.

----------

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

From report at bugs.python.org  Sat Jan  2 22:27:53 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 02 Jan 2010 21:27:53 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1262467673.51.0.467131986558.issue7620@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

Reuploaded (some syntax groups fixed).

----------
Added file: http://bugs.python.org/file15721/misc-vim-syntax.diff

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

From report at bugs.python.org  Sat Jan  2 22:27:58 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 02 Jan 2010 21:27:58 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1262467678.75.0.721039921778.issue7620@psf.upfronthosting.co.za>


Changes by July Tikhonov <july.tikh at gmail.com>:


Removed 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 22:39:57 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 02 Jan 2010 21:39:57 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1262468397.87.0.0599633285659.issue7620@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon
priority:  -> low
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  2 22:40:07 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 02 Jan 2010 21:40:07 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1262468407.35.0.822763015988.issue7620@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.2 -3rd party

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

From report at bugs.python.org  Sat Jan  2 22:42:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Jan 2010 21:42:28 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262468548.68.0.719783509105.issue7462@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The main patch has been committed in r77241 (trunk) and r77246 (py3k).
I've ommitted the tests you had added for issue7458.
Thank you!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jan  2 22:44:42 2010
From: report at bugs.python.org (djc)
Date: Sat, 02 Jan 2010 21:44:42 +0000
Subject: [issue7619] imaplib shouldn't use cause DeprecationWarnings in 2.6
In-Reply-To: <1262384572.13.0.48856105393.issue7619@psf.upfronthosting.co.za>
Message-ID: <1262468682.43.0.084455992387.issue7619@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

Perfect.

----------

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

From report at bugs.python.org  Sat Jan  2 22:56:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Jan 2010 21:56:00 +0000
Subject: [issue7458] crash in str.rfind() with an invalid start value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1262469360.59.0.0563671877657.issue7458@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've committed the tests after the patch for issue7462 removed the offending code. Thanks!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Jan  2 23:33:32 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Jan 2010 22:33:32 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1262471612.74.0.920510477097.issue3745@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

trunk r77252 switches python 2.7 to use 's*' for argument parsing.  unicodes can be hashed (encoded to the system default encoding by s*) again.

This change has been blocked from being merged into py3k unless someone decides we actually want this magic unicode encoding behavior to exist there as well.

setup.py has also been updated to compile all versions of the hash algorithm modules when Py_DEBUG is defined.  I'll update tests run on all implementations next so that it is easier for developers to maintain identical behavior across all implementations without needing to explicitly remember to reconfigure their setup and test those.

----------

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

From report at bugs.python.org  Sat Jan  2 23:38:54 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Jan 2010 22:38:54 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1262471934.81.0.102422134164.issue3745@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

In order to get a -3 PyErr_WarnPy3k warning for unicode being passed to hashlib objects (a nice idea) I suggest creating an additonal 's*' like thing ('s3' perhaps?) in Python/getargs.c for that purpose rather than modifying all of the hashlib modules to accept an O, type check it and warn, and then re-parse it as a s* (that'd be a lot of tedious code duplication).

----------

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

From report at bugs.python.org  Sun Jan  3 01:48:12 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Jan 2010 00:48:12 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1220261226.32.0.128110321757.issue3745@psf.upfronthosting.co.za>
Message-ID: <1262479692.24.0.167273096414.issue3745@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I believe everything in here has been addressed.  Please open new issues with details for anything that doesn't quite right.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Jan  3 03:07:08 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Jan 2010 02:07:08 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262484428.01.0.882304653727.issue3972@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

trunk r77263 and r77264 add this feature, including documentation and tests.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Jan  3 05:46:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Jan 2010 04:46:33 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262493993.95.0.90868322753.issue1755841@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is the corrected patch for caching the 301 redirections.

* It caches only the redirection not the response.
* It retains cacheable=True kwarg for http_error_301 method. ( I feel, it should be useful)
* Have made the cached dict as private.

I have updated the tests. The existing tests for 301 see no changes too.

If you have any review comments, please pitch in. (I shall add the docs and news entry before commit)

Thanks!

----------
Added file: http://bugs.python.org/file15722/urllib2-301-redirection-CORRECTED.diff

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

From report at bugs.python.org  Sun Jan  3 05:46:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Jan 2010 04:46:56 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262494016.33.0.785974145964.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file15677/urllib2-301-redirection.diff

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

From report at bugs.python.org  Sun Jan  3 10:14:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Jan 2010 09:14:42 +0000
Subject: [issue7618] optparse library documentation has an insignificant
	formatting issue
In-Reply-To: <1262371550.06.0.14749743487.issue7618@psf.upfronthosting.co.za>
Message-ID: <1262510082.83.0.706452277517.issue7618@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77267 (trunk), r77268 (release26-maint), r77269 (py3k), r77270 (release31-maint), thanks!

----------
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jan  3 10:57:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 Jan 2010 09:57:43 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1262512663.71.0.435101196773.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as won't fix.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Jan  3 11:34:07 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 03 Jan 2010 10:34:07 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262514847.45.0.155557079694.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I uploaded a possible patch for Python 2.7.

The patch converts ZipExtFile into subclass of io.BufferedIOBase and drops most of the original implementation.

However, the patch breaks current newline behavior of ZipExtFile. I figured this was reasonable because zipfile newline behavior:
a) was introduced in Python 2.6
b) was incompatible with behavior of io module files.
c) was not documented.

Reading zip content as text with newline functionality may be done with io.TextIOWrapper.

A bonus of sub classing io.BufferedIOBase is significantly better read performance.

----------
keywords: +patch
Added file: http://bugs.python.org/file15723/zipfile_7610_py27.diff

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

From report at bugs.python.org  Sun Jan  3 12:24:42 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 03 Jan 2010 11:24:42 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1262517882.51.0.119333881517.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
versions: +Python 2.7
Added file: http://bugs.python.org/file15724/python-trunk-20100103-CROSS.patch

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

From report at bugs.python.org  Sun Jan  3 12:25:54 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 03 Jan 2010 11:25:54 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1262517954.42.0.289598604757.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file15725/python-trunk-20100103-MINGW.patch

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

From report at bugs.python.org  Sun Jan  3 13:34:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 Jan 2010 12:34:38 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1262522078.77.0.549239099631.issue4294@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this.  I like the PyLong_IS_NEGATIVE and PyLong_IS_ZERO macros, but I can't find anywhere outside longobject.c where they'd actually be useful (with the possible exception of marshal.c, but that currently depends on knowing lots about the long implementation anyway).  And I don't really see much benefit from doing a mass replacement of uses of 'Py_SIZE(a) < 0', etc. in Objects/longobject.c;  I think it's the code is readable enough as it stands.

----------
resolution:  -> rejected
status: open -> pending

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

From report at bugs.python.org  Sun Jan  3 13:42:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 Jan 2010 12:42:48 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1262522568.38.0.574334912197.issue3366@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Will close this unless there's an outcry of support for exp2 and log2.
nirinA,  if you're still interested in adding the euler constant, please open another issue.

----------
status: open -> pending

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

From report at bugs.python.org  Sun Jan  3 13:45:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 12:45:47 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262522747.09.0.716477375201.issue1755841@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here is the corrected patch for caching the 301 redirections.
> 
> * It caches only the redirection not the response.
> * It retains cacheable=True kwarg for http_error_301 method. ( I feel, it should be useful)
> * Have made the cached dict as private.

I'm still not sure what this patch is trying to do. It seems you are using the cached URL *after* getting the 301 response. But the whole point of caching redirections is to avoid emitting the initial request at all.

----------

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

From report at bugs.python.org  Sun Jan  3 13:57:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 12:57:27 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1262484428.01.0.882304653727.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262523500.3330.8.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems to break at least one buildbot:

======================================================================
ERROR: testSourceAddress (test.test_socket.NetworkConnectionAttributesTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/trunk.murray-gentoo-wide/build/Lib/test/test_socket.py", line 120, in _tearDown
    self.fail(msg)
AssertionError: Tuples differ: ('199.125.120.107', 40732) != ('127.0.0.1', 40732)

First differing element 0:
199.125.120.107
127.0.0.1

- ('199.125.120.107', 40732)
+ ('127.0.0.1', 40732)

----------------------------------------------------------------------
Ran 100 tests in 11.505s

By the way, does the new "source_address" parameter have to be of the
same family as the target address?  That is, if I pass e.g. "127.0.0.1"
as source address, what happens if the target host resolves to an IPv6
address?

----------

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

From report at bugs.python.org  Sun Jan  3 14:08:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 03 Jan 2010 13:08:18 +0000
Subject: [issue7607] stringlib fastsearch could be improved on 64-bit builds
In-Reply-To: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
Message-ID: <1262524098.49.0.987745907411.issue7607@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Sun Jan  3 14:47:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 13:47:37 +0000
Subject: [issue7607] stringlib fastsearch could be improved on 64-bit builds
In-Reply-To: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
Message-ID: <1262526457.05.0.473222253764.issue7607@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Another place where this optimization will apply:
 "Objects/unicodeobject.c" for the bloom filters:

#define BLOOM(mask, ch) ((mask & (1 << ((ch) & 0x1F))))

----------

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

From report at bugs.python.org  Sun Jan  3 15:07:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 03 Jan 2010 14:07:45 +0000
Subject: [issue3451] Asymptotically faster divmod and str(long)
In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za>
Message-ID: <1262527665.2.0.754677645435.issue3451@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions:  -Python 3.1

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

From report at bugs.python.org  Sun Jan  3 16:00:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 15:00:32 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262530832.71.0.0410094935104.issue7585@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is there any reason why you changed some of the examples in the docstrings (e.g. 'Sat Jan 26 23:30:50 1991' -> '1991-01-26 23:30:50')?

----------
nosy: +pitrou

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

From report at bugs.python.org  Sun Jan  3 16:01:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 15:01:58 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262530918.01.0.66468505846.issue7585@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tim_one
priority:  -> normal
stage:  -> patch review
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Sun Jan  3 16:10:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 15:10:12 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262531412.64.0.593480369453.issue7610@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think we can remove the "U" option from 2.6/2.7; it was certainly introduced for a reason and isn't inconsistent with the "U" option to the built-in open().

On 3.x, behaviour is indeed inconsistent with the standard IO library, so maybe we can either wrap the object in a TextIOWrapper, or remove support for "U".

----------
nosy: +pitrou
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 2.6

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

From report at bugs.python.org  Sun Jan  3 16:10:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 03 Jan 2010 15:10:29 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1262531429.49.0.260503828245.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is the same reason as for removing recommendation from docstring to generate timestamps in the format returned by time.ctime(). See issue #7582

----------

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

From report at bugs.python.org  Sun Jan  3 16:41:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Jan 2010 15:41:23 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262533283.75.0.588613327783.issue3972@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, and I was even the one that suggested the bind to 127.0.0.1 strategy for the test :(

My buildbots run in linux-vserver virtual hosts, and they way they handle localhost (127.0.0.1) is to alias it to the IP address assigned to the virthost (otherwise multiple virthosts opening ports on 127.0.0.1 would potentially conflict with each other).

I'd consider this a bug in the virthost software (lack of feature?).  Not sure what the best workaround is, but if all else fails we could put in some special case skip code.

Would be good enough to have the test check that the returned IP address is *not* 0.0.0.0?  Or perhaps issue a warning if the address is not 0.0.0.0 but isn't 127.0.0.1.

----------

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

From report at bugs.python.org  Sun Jan  3 18:09:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 17:09:47 +0000
Subject: [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: [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 18:37:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 Jan 2010 17:37:02 +0000
Subject: [issue7623] PropertyType missing in Lib/types.py
In-Reply-To: <1262539758.51.0.472094594886.issue7623@psf.upfronthosting.co.za>
Message-ID: <1262540222.54.0.760208495492.issue7623@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We are not adding new types to types.py. See #1605

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jan  3 18:50:10 2010
From: report at bugs.python.org (=?utf-8?b?VmFsZW50w61u?=)
Date: Sun, 03 Jan 2010 17:50:10 +0000
Subject: [issue1545] shutil fails when copying to NTFS in Linux
In-Reply-To: <1196665730.42.0.657784597912.issue1545@psf.upfronthosting.co.za>
Message-ID: <1262541010.98.0.558759620999.issue1545@psf.upfronthosting.co.za>


Valent?n <valentin.depablo at gmail.com> added the comment:

I think this one is solved now. I recommend just to put as solved and kill it from the list ;)

----------
nosy: +Val

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

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


Antoine Pitrou <pitrou at free.fr> added the comment:

The "split.h" file is missing from your patch.

----------
nosy: +pitrou

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

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


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed 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 19:00:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 18:00:41 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262541641.46.0.756876635888.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

You're right. Oups.

----------
Added file: http://bugs.python.org/file15727/stringlib_split_replace_v2.diff

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

From report at bugs.python.org  Sun Jan  3 19:13:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 18:13:44 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262542424.06.0.984064940302.issue7622@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks wrong for bytearrays. They are mutable, so you shouldn't return the original object as an optimization. Here is the current (unpatched) behaviour:

>>> a = bytearray(b"abc")
>>> b, = a.split()
>>> b is a
False

On the other hand, you aren't doing this optimization at all in the general case of stringlib_split() and stringlib_rsplit(), while it could be done.

----------

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

From report at bugs.python.org  Sun Jan  3 19:30:45 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 Jan 2010 18:30:45 +0000
Subject: [issue1545] shutil fails when copying to NTFS in Linux
In-Reply-To: <1196665730.42.0.657784597912.issue1545@psf.upfronthosting.co.za>
Message-ID: <1262543445.16.0.56017963561.issue1545@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

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

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: [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: [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:30 2010
From: report at bugs.python.org (Stefan Schweizer)
Date: Sun, 03 Jan 2010 20:13:30 +0000
Subject: [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  Sun Jan  3 21:28:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 20:28:47 +0000
Subject: [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: <1262550527.99.0.392603050294.issue7625@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

And each test comes with a new bug :)

>>> x = bytearray('abc')
>>> x.partition('.')[0] is x
True
>>> x.rpartition('.')[2] is x
True

----------
priority: low -> normal

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

From report at bugs.python.org  Sun Jan  3 21:36:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 20:36:37 +0000
Subject: [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: <1262550997.22.0.620171104607.issue7625@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Interpreter Core
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan  3 22:14:35 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Jan 2010 21:14:35 +0000
Subject: [issue3972] Add Option to Bind to a Local IP Address in httplib.py
In-Reply-To: <1222423132.09.0.32780438264.issue3972@psf.upfronthosting.co.za>
Message-ID: <1262553275.51.0.877868466975.issue3972@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I took the easy route and remove the test of the hostname all together.  The fact that the source port was used is sufficient indication that the bind call was made.

----------

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

From report at bugs.python.org  Sun Jan  3 22:47:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Jan 2010 21:47:39 +0000
Subject: [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: <1262555259.14.0.139137633098.issue7625@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Jan  3 22:51:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Jan 2010 21:51:59 +0000
Subject: [issue7626] Entity references without semicolon in HTMLParser
In-Reply-To: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>
Message-ID: <1262555519.33.0.890974090757.issue7626@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Jan  3 22:53:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Jan 2010 21:53:46 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262555626.83.0.758331206583.issue7622@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Sun Jan  3 23:01:26 2010
From: report at bugs.python.org (Salman Haq)
Date: Sun, 03 Jan 2010 22:01:26 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1262556086.97.0.384454951604.issue7559@psf.upfronthosting.co.za>


Salman Haq <salman.haq at gmail.com> added the comment:

Hope everyone had a good new year's. I've attached an updated patch which adds a new unittest, test_loadTestsFromNames__badimport. 

Both the new unittests can use better documentation, hopefully one of you can help me with that.

----------
Added file: http://bugs.python.org/file15728/issuee7559_trunk_patch.diff

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

From report at bugs.python.org  Sun Jan  3 23:04:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Jan 2010 22:04:51 +0000
Subject: [issue4635] no reference for optparse methods
In-Reply-To: <1229016349.77.0.360903812636.issue4635@psf.upfronthosting.co.za>
Message-ID: <1262556291.92.0.242362838302.issue4635@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #3340.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jan  3 23:40:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jan 2010 22:40:05 +0000
Subject: [issue7471] GZipFile.readline too slow
In-Reply-To: <1260461485.52.0.614015732019.issue7471@psf.upfronthosting.co.za>
Message-ID: <1262558405.91.0.772892449661.issue7471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patches have been committed. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan  4 00:13:07 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 03 Jan 2010 23:13:07 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262560387.27.0.249041630869.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

> If we change this, the encoder should quote both single and double 
> quotes - simply because it is not known whether the literal 
> will use single or double quotes.

Or document that single quotes are always escaped so that the user knows he/she can safely use u''.  I'm not sure if there is a use case where both would *need* to be escaped, and escaping both has a size penalty.

I've attached an untested patch that escapes both.

If both are escaped, then the behavior of the string_escape codec should also be changed for consistency (it only escapes single quotes).

> The raw_unicode_escape codec would have to be fixed as well.

I'm not sure there's anything to fix.  Adding backslashes to quotes in raw strings changes the value of the string -- the backslashes prevent the quotes from ending the string literal, but they are not removed when the raw literal is evaluated.

Perhaps raw_unicode_escape should be "fixed" by raising an exception when it contains any quotes.

----------
Added file: http://bugs.python.org/file15729/unicode_escape_single_and_double_quotes.patch

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

From report at bugs.python.org  Mon Jan  4 00:47:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 23:47:17 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262562437.61.0.800904572411.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Mutable methods split() splitlines() and partition() fixed.
And added optimization for all immutables methods.

----------
Added file: http://bugs.python.org/file15730/stringlib_split_replace_v3.diff

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

From report at bugs.python.org  Mon Jan  4 00:48:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jan 2010 23:48:00 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262562480.63.0.00999787362374.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15727/stringlib_split_replace_v2.diff

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

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: [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:26 2010
From: report at bugs.python.org (bkovt)
Date: Mon, 04 Jan 2010 01:59:26 +0000
Subject: [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: [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 03:30:23 2010
From: report at bugs.python.org (Markus)
Date: Mon, 04 Jan 2010 02:30:23 +0000
Subject: [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: <1262572223.19.0.685966578037.issue7629@psf.upfronthosting.co.za>


Markus <hardcorevenom at gmx.de> added the comment:

Sorry, my fault.
"/MT" was given in "setup.py" of "pylzma". I didn't search properly.
Please close.

----------

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

From report at bugs.python.org  Mon Jan  4 03:47:57 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Jan 2010 02:47:57 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262573277.79.0.456552722396.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

New patch that includes proposed doc changes.

----------
Added file: http://bugs.python.org/file15731/silence_deprecations.diff

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

From report at bugs.python.org  Mon Jan  4 03:48:06 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 04 Jan 2010 02:48:06 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262573286.56.0.088338440695.issue7319@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file15326/silence_deprecations.diff

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

From report at bugs.python.org  Mon Jan  4 03:50:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Jan 2010 02:50:06 +0000
Subject: [issue7628] round() doesn't work correctly in 3.1.1
In-Reply-To: <1262570365.97.0.975021093737.issue7628@psf.upfronthosting.co.za>
Message-ID: <1262573406.33.0.803066505.issue7628@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Mon Jan  4 03:51:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Jan 2010 02:51:19 +0000
Subject: [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: <1262573479.67.0.198724396106.issue7629@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Jan  4 03:58:17 2010
From: report at bugs.python.org (Tim Peters)
Date: Mon, 04 Jan 2010 02:58:17 +0000
Subject: [issue7628] round() doesn't work correctly in 3.1.1
In-Reply-To: <1262570365.97.0.975021093737.issue7628@psf.upfronthosting.co.za>
Message-ID: <1262573897.14.0.591660415271.issue7628@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Note that round() is implemented much more carefully in Python 3.x than in Python 2.x, and 120 is actually the correct result under nearest/even rounding (125 is exactly halfway between representable values when rounded to the closest 10, and nearest/even rounding resolves the ambiguity by picking the closest value whose last relevant digit is even).

----------
nosy: +tim_one

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

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


bkovt <bkovt-python at yahoo.com> added the comment:

All right, round() in 3.1 uses 'Round half to even' instead of 'Round half up'. In fact, now I can see this clearly explained in 3.1 documentation. Thanks for the quick reply and sorry for the erroneous bug entry!

----------

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

From report at bugs.python.org  Mon Jan  4 04:31:45 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Jan 2010 03:31:45 +0000
Subject: [issue7628] round() doesn't work correctly in 3.1.1
In-Reply-To: <1262570365.97.0.975021093737.issue7628@psf.upfronthosting.co.za>
Message-ID: <1262575905.21.0.0664856511431.issue7628@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

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

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: [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 08:02:53 2010
From: report at bugs.python.org (ivank)
Date: Mon, 04 Jan 2010 07:02:53 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1262588573.9.0.545721139586.issue6071@psf.upfronthosting.co.za>


ivank <ivan at ludios.org> added the comment:

I believe this was fixed in r77252, which was fixing http://bugs.python.org/issue3745

----------

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

From report at bugs.python.org  Mon Jan  4 08:36:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 07:36:07 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262590567.33.0.534819425402.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

added "Makefile.pre.in".

----------
Added file: http://bugs.python.org/file15732/stringlib_split_replace_v3b.diff

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

From report at bugs.python.org  Mon Jan  4 08:36:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 07:36:18 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262590578.33.0.376410152843.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15730/stringlib_split_replace_v3.diff

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

From report at bugs.python.org  Mon Jan  4 09:01:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 08:01:28 +0000
Subject: [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: <1262592088.76.0.951529457144.issue7625@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch for some additional test cases attached.

The bug "b.partition('.')[0] is b" is fixed with the patch proposed on issue7622.

----------
keywords: +patch
Added file: http://bugs.python.org/file15733/issue7625_tests.diff

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

From report at bugs.python.org  Mon Jan  4 09:58:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Jan 2010 08:58:29 +0000
Subject: [issue7630] Strange behaviour of decimal.Decimal
In-Reply-To: <1262583718.55.0.703932214446.issue7630@psf.upfronthosting.co.za>
Message-ID: <1262595509.91.0.0451679362115.issue7630@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

You don't say what behaviour you were expecting!   :)

By design, almost all Decimal operations (but not creation of a Decimal from an integer or string) round to the precision given by the current context.  By default that precision is 28 significant digits.  See the documentation, particularly the quick-start tutorial,

http://docs.python.org/library/decimal.html#quick-start-tutorial

for more information, including how to change the default precision.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Mon Jan  4 09:59:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 08:59:16 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262595556.4.0.462992470252.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

There's some reference leaking somewhere...
Will investigate.

~ $ ./python Lib/test/regrtest.py -R 2:3: test_unicode
test_unicode leaked [7, 7, 7] references, sum=21

----------

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

From report at bugs.python.org  Mon Jan  4 10:08:46 2010
From: report at bugs.python.org (Daniel)
Date: Mon, 04 Jan 2010 09:08:46 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1262596126.88.0.522897720808.issue2698@psf.upfronthosting.co.za>


Daniel <daniel.mondon at free.fr> added the comment:

Thanks for your response!
I'm back after holidays :)

Yappy new year everybody!!!

Conserning our problem:
.../...
adding base module named weakref
running build
running build_py
running build_ext
Traceback (most recent call last):
  File "setup.py", line 240, in <module>
    license = "Python Software Foundation License")
  File "c:\python31\lib\distutils\core.py", line 149, in setup dist.run_commands()
  File "c:\python31\lib\distutils\dist.py", line 919, in run_commands self.run_command(cmd)
  File "c:\python31\lib\distutils\dist.py", line 938, in run_command cmd_obj.run()
  File "c:\python31\lib\distutils\command\build.py", line 128, in run self.run_command(cmd_name)
  File "c:\python31\lib\distutils\cmd.py", line 315, in run_command self.distribution.run_command(command)
  File "c:\python31\lib\distutils\dist.py", line 938, in run_command cmd_obj.run()
  File "c:\python31\lib\distutils\command\build_ext.py", line 358, in run force=self.force)
  File "c:\python31\lib\distutils\ccompiler.py", line 1106, in new_compiler return klass(None, dry_run, force)
  File "c:\python31\lib\distutils\cygwinccompiler.py", line 280, in __init__ CygwinCCompiler.__init__ (self, verbose, dry_run, force)
  File "c:\python31\lib\distutils\cygwinccompiler.py", line 124, in __init__ if self.ld_version >= "2.10.90": TypeError: unorderable types: NoneType() >= str()

I will also analyse and look at a solution.


Daniel.

----------

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

From report at bugs.python.org  Mon Jan  4 10:09:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Jan 2010 09:09:13 +0000
Subject: [issue7630] Strange behaviour of decimal.Decimal
In-Reply-To: <1262583718.55.0.703932214446.issue7630@psf.upfronthosting.co.za>
Message-ID: <1262596153.67.0.804274821527.issue7630@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It might also help to note that, with decimal, what you see (from repr() of a Decimal instance) is *exactly* what you get.  So when you see

>>> dec
Decimal('1.797693134862315907729305191E+308')

that number really is exactly what's stored in dec:  there are no 'hidden'  digits waiting to appear.

----------

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

From report at bugs.python.org  Mon Jan  4 10:20:23 2010
From: report at bugs.python.org (Fredrik Lundh)
Date: Mon, 04 Jan 2010 09:20:23 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262596823.62.0.567422490981.issue7462@psf.upfronthosting.co.za>


Fredrik Lundh <fredrik at effbot.org> added the comment:

Thanks Florent!

> Are there any simple, common cases that are made slower by this patch? 

The original fastsearch implementation has a couple of special cases to make sure it's faster than the original code in all cases.  The reason it wasn't implemented for reverse search was more a question of developer time constraints; reverse search isn't nearly as common as forward search, and we had other low-hanging fruit to deal with.

(btw, while it's great that someone finally got around to fix this, it wouldn't surprise me if replacing the KMP implementation in SRE with a fastsearch would save as many CPU cycles worldwide as this patch :)

----------

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

From report at bugs.python.org  Mon Jan  4 10:26:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Jan 2010 09:26:26 +0000
Subject: [issue7462] Implement fastsearch algorithm for rfind/rindex
In-Reply-To: <1260312404.76.0.460437630614.issue7462@psf.upfronthosting.co.za>
Message-ID: <1262597186.72.0.0457215027714.issue7462@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

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: [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 11:03:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Jan 2010 10:03:23 +0000
Subject: [issue7631] undefined label: bltin-file-objects
In-Reply-To: <1262599138.12.0.461032308241.issue7631@psf.upfronthosting.co.za>
Message-ID: <1262599403.78.0.118287223158.issue7631@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> pitrou

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

From report at bugs.python.org  Mon Jan  4 12:43:59 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Jan 2010 11:43:59 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1262471612.74.0.920510477097.issue3745@psf.upfronthosting.co.za>
Message-ID: <4B41D47C.9040508@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Gregory P. Smith wrote:
> 
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
> trunk r77252 switches python 2.7 to use 's*' for argument parsing.  unicodes can be hashed (encoded to the system default encoding by s*) again.
> 
> This change has been blocked from being merged into py3k unless someone decides we actually want this magic unicode encoding behavior to exist there as well.

Thanks for updating the implementation.

----------

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

From report at bugs.python.org  Mon Jan  4 12:49:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Jan 2010 11:49:28 +0000
Subject: [issue3745] _sha256 et al. encode to UTF-8 by default
In-Reply-To: <1262471934.81.0.102422134164.issue3745@psf.upfronthosting.co.za>
Message-ID: <4B41D5C5.2060206@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Gregory P. Smith wrote:
> 
> Gregory P. Smith <greg at krypto.org> added the comment:
> 
> In order to get a -3 PyErr_WarnPy3k warning for unicode being passed to hashlib objects (a nice idea) I suggest creating an additonal 's*' like thing ('s3' perhaps?) in Python/getargs.c for that purpose rather than modifying all of the hashlib modules to accept an O, type check it and warn, and then re-parse it as a s* (that'd be a lot of tedious code duplication).

Good idea. We're likely going to need this in more places, so I'm +1 on
adding an "s3" parser marker.

----------

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

From report at bugs.python.org  Mon Jan  4 13:21:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 12:21:57 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262607717.51.0.920310654575.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Refleak fixed in PyUnicode_Splitlines.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file15734/stringlib_split_replace_v3c.diff

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

From report at bugs.python.org  Mon Jan  4 13:22:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 12:22:03 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262607723.73.0.355758906856.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15732/stringlib_split_replace_v3b.diff

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

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: [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 13:57:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Jan 2010 12:57:17 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262609837.21.0.632960565348.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice catch!  I'll take a look.  We should find out whether this is something that happens with Gay's original code, or whether it was introduced in the process of adapting that code for Python.

----------
assignee:  -> mark.dickinson
priority:  -> critical
versions: +Python 2.7

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

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


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Interpreter Core
stage:  -> needs patch
type:  -> crash

_______________________________________
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: [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  Mon Jan  4 14:03:03 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Jan 2010 13:03:03 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262610183.83.0.772564987223.issue7622@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

A few comments on coding style:

 * please keep the existing argument formats as they are, e.g.

    count = countstring(self_s, self_len,
                        from_s, from_len,
                        0, self_len, FORWARD, maxcount);

   or

  /* helper macro to fixup start/end slice values */
  -#define FIX_START_END(obj)                      \
  -    if (start < 0)                              \
  -        start += (obj)->length;                 \
  -    if (start < 0)                              \
  -        start = 0;                              \
  -    if (end > (obj)->length)                    \
  -        end = (obj)->length;                    \
  -    if (end < 0)                                \
  -        end += (obj)->length;                   \
  -    if (end < 0)                                \
  -        end = 0;
  +#define ADJUST_INDICES(start, end, len)                         \
  +    if (end > len) end = len;                                   \
  +    else if (end < 0) { end += len; if (end < 0) end = 0; }     \
  +    if (start < 0) { start += len; if (start < 0) start = 0; }



   and use similar formatting for the replacement function
   calls/macros

 * make sure that the name of a symbol matches the value, e.g.

   #define LONG_BITMASK (LONG_BIT-1)
   #define BLOOM(mask, ch) ((mask & (1 << ((ch) & LONG_BITMASK))))

   LONG_BITMASK has a value of 0x1f (31) - that's a single byte, not
   a long value. In this case, 0x1f is an implementation detail of
   the simplified Bloom filter used for set membership tests in the
   Unicode implementation.

   When adjusting the value to be platform dependent, please check
   that the implementation does work for platforms that have
   more than 31 bits available for (signed) longs.

   Note that you don't need to expose that value separately if
   you stick to using BLOOM() directly.

 * use BLOOM() macro in fastsearch.c

 * when declaring variables with initial values, keep these on separate lines, e.g. don't use this style:

    Py_ssize_t i, j, count=0;
    PyObject *list = PyList_New(PREALLOC_SIZE(maxcount)), *sub;

   instead, write:

    Py_ssize_t i, j;
    Py_ssize_t count=0;
    PyObject *list = PyList_New(PREALLOC_SIZE(maxcount))
    PyObject *sub;

 * always place variable declarations at the top of a function, not into the function body:

  +stringlib_split(
  +    PyObject* str_obj, const STRINGLIB_CHAR* str, Py_ssize_t str_len,
  +    const STRINGLIB_CHAR* sep, Py_ssize_t sep_len, Py_ssize_t  maxcount
  +    )
  +{
  +    if (sep_len == 0) {
  +        PyErr_SetString(PyExc_ValueError, "empty separator");
  +        return NULL;
  +    }
  +    else if (sep_len == 1)
  +        return stringlib_split_char(str_obj, str, str_len, sep[0],   maxcount);
  +
  +    Py_ssize_t i, j, pos, count=0;
  +    PyObject *list = PyList_New(PREALLOC_SIZE(maxcount)), *sub;
  +    if (list == NULL)
  +        return NULL;
   
 * function declarations should not put parameters on new lines:

  +stringlib_splitlines(
  +    PyObject* str_obj, const STRINGLIB_CHAR* str, Py_ssize_t str_len,
  +    int keepends
  +    )
  +{

 instead use this style:

  -static
  -PyObject *rsplit_substring(PyUnicodeObject *self,
  -                           PyObject *list,
  -                           PyUnicodeObject *substring,
  -                           Py_ssize_t maxcount)
  -{

----------
components: +Unicode
nosy: +lemburg

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

From report at bugs.python.org  Mon Jan  4 14:14:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 Jan 2010 13:14:37 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262610877.07.0.0270390719845.issue7622@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon Jan  4 14:23:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Jan 2010 13:23:18 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262611398.72.0.660041917997.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I can reproduce this on OS X 10.6 (64-bit), both in py3k and trunk debug builds.  In non-debug builds it appears to return the correct result (0.0), so the oversize b appears to have no ill effects.  So this may just be an overeager assert;  it may be a symptom of a deeper problem, though.

----------
priority: critical -> high

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

From report at bugs.python.org  Mon Jan  4 14:37:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 Jan 2010 13:37:59 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262612279.48.0.0850637166928.issue7632@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm testing on a Fedora Core 6 i386 box and an Intel Mac 32-bit 10.5 box. I only see this on debug builds. I've tested trunk, py3k, release31-maint, and release26-maint (just for giggles).

The error shows up in debug builds of trunk, py3k, and release31-maint on both machines, and does not show up in non-debug builds.

----------
versions: +Python 3.1

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

From report at bugs.python.org  Mon Jan  4 14:54:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 13:54:53 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262613293.61.0.409210565654.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

> A few comments on coding style:

Thank you for your remarks. I will update the patch accordingly.

> * make sure that the name of a symbol matches the value, e.g.
>
>   #define LONG_BITMASK (LONG_BIT-1)
>   #define BLOOM(mask, ch) ((mask & (1 << ((ch) & LONG_BITMASK))))
>
>   LONG_BITMASK has a value of 0x1f (31) - that's a single byte, not
>   a long value. In this case, 0x1f is an implementation detail of
>   the simplified Bloom filter used for set membership tests in the
>   Unicode implementation.
>
>   When adjusting the value to be platform dependent, please check
>   that the implementation does work for platforms that have
>   more than 31 bits available for (signed) longs.
>
>   Note that you don't need to expose that value separately if
>   you stick to using BLOOM() directly.

Since the same value is used to build the mask, I assume it's better to keep the value around (or use (LONG_BIT-1) directly?).
    mask |= (1 << (ptr[i] & LONG_BITMASK));

s/LONG_BITMASK/BLOOM_BITMASK/ is not confusing?

----------

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

From report at bugs.python.org  Mon Jan  4 15:46:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 14:46:03 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262616363.46.0.402050985113.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

> * function declarations should not put parameters on new lines:
>
>  +stringlib_splitlines(
>  +    PyObject* str_obj, const STRINGLIB_CHAR* str, Py_ssize_t str_len,
>  +    int keepends
>  +    )
>  +{

I copied the style of "stringlib/partition.h" for this part.
Should I update style of "partition.h" too?

----------

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

From report at bugs.python.org  Mon Jan  4 15:54:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 14:54:37 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262616877.73.0.703213232386.issue7622@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I copied the style of "stringlib/partition.h" for this part.
> Should I update style of "partition.h" too?

No, it's ok for stringlib to have its own consistent style and there's no reason to change it IMO.

More interesting would be benchmark results showing how much this improves the various methods :-)

----------

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

From report at bugs.python.org  Mon Jan  4 16:15:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 15:15:29 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262618129.51.0.729868083812.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch updated:
 * coding style
 * added macros BLOOM_ADD to unicodeobject.c and fastsearch.h
   (and removed LONG_BITMASK)

----------
Added file: http://bugs.python.org/file15735/stringlib_split_replace_v4.diff

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

From report at bugs.python.org  Mon Jan  4 16:15:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 15:15:50 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262618150.34.0.87408429713.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15734/stringlib_split_replace_v3c.diff

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

From report at bugs.python.org  Mon Jan  4 16:25:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 15:25:52 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262618752.6.0.0388266575654.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

And now, the figures.

There's no gain for the string methods.
Some unicode methods are faster: split/rsplit/replace:


Most significant results:

--- bench_slow.log  Trunk
+++ bench_fast.log  Patched

 string unicode
 (ms)   (ms)    comment

 ========== late match, 100 characters
-13.30  20.51   s="ABC"*33; ("E"+s+("D"+s)*500).rsplit("E"+s, 1) (*100)
-16.12  29.88   s="ABC"*33; ((s+"D")*500+s+"E").split(s+"E", 1) (*100)
+13.27  14.38   s="ABC"*33; ("E"+s+("D"+s)*500).rsplit("E"+s, 1) (*100)
+16.19  17.61   s="ABC"*33; ((s+"D")*500+s+"E").split(s+"E", 1) (*100)

 ========== quick replace multiple character match
-4.51   159.78  ("A" + ("Z"*128*1024)).replace("AZZ", "BBZZ", 1) (*100)
+3.67   7.30    ("A" + ("Z"*128*1024)).replace("AZZ", "BBZZ", 1) (*100)

 ========== quick replace single character match
-3.73   50.61   ("A" + ("Z"*128*1024)).replace("A", "BB", 1) (*100)
+3.72   7.18    ("A" + ("Z"*128*1024)).replace("A", "BB", 1) (*100)

(full benchmark diff is attached)

And we save 1000 lines of code cumulated
(stringobject.c/unicodeobject.c/bytearrayobject.c)

----------
Added file: http://bugs.python.org/file15736/benchmark_split_replace.diff

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

From report at bugs.python.org  Mon Jan  4 16:41:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 15:41:35 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262619695.83.0.852807799128.issue7622@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think you should remove such blocks:

-/*
-  Local variables:
-  c-basic-offset: 4
-  indent-tabs-mode: nil
-  End:
-*/

There probably are people relying on them :-)

----------

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

From report at bugs.python.org  Mon Jan  4 16:47:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 15:47:36 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262620056.09.0.139599800352.issue7319@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just FYI, there are tabs in your spaces in _warnings.c.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Jan  4 16:55:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Jan 2010 15:55:30 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262620530.61.0.165974076432.issue7622@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> > 
> > Florent Xicluna <laxyf at yahoo.fr> added the comment:
> > 
>> >> * function declarations should not put parameters on new lines:
>> >>
>> >>  +stringlib_splitlines(
>> >>  +    PyObject* str_obj, const STRINGLIB_CHAR* str, Py_ssize_t str_len,
>> >>  +    int keepends
>> >>  +    )
>> >>  +{
> > 
> > I copied the style of "stringlib/partition.h" for this part.
> > Should I update style of "partition.h" too?

I'd prefer if you change the coding style to what we use elsewhere
in Python C code.

See http://www.python.org/dev/peps/pep-0007/ for more C coding
style suggestions.

----------

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

From report at bugs.python.org  Mon Jan  4 17:25:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 Jan 2010 16:25:59 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262622359.84.0.526643338829.issue7622@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think we should use whatever style is currently being used in the code. If we want to go back through this code (or any other code) and PEP7-ify it, that should be a separate task.

Alternately, we could PEP7-ify it first, then apply these changes.

----------

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

From report at bugs.python.org  Mon Jan  4 17:53:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Jan 2010 16:53:26 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262624006.35.0.336945473935.issue7622@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Eric Smith wrote:
> > 
> > Eric Smith <eric at trueblade.com> added the comment:
> > 
> > I think we should use whatever style is currently being used in the code. If we want to go back through this code (or any other code) and PEP7-ify it, that should be a separate task.
> > 
> > Alternately, we could PEP7-ify it first, then apply these changes.

For any new files added, PEP 7 should always be used.

For PEP7-ifying the existing code, we could open a separate ticket or just apply the change as separate patch.

----------

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

From report at bugs.python.org  Mon Jan  4 18:03:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 17:03:54 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262624634.88.0.654410094411.issue7092@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: deferred blocker -> release blocker

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

From report at bugs.python.org  Mon Jan  4 19:14:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 18:14:17 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262628857.45.0.779686982764.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In issue7092_lib_many_fixes.diff: why did you change some of the warning messages?

In issue7092_pprint.diff: I'm not sure these changes are right, because they could modify existing behaviour. Raymond, what do you think?

----------
nosy: +rhettinger

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

From report at bugs.python.org  Mon Jan  4 19:51:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 18:51:19 +0000
Subject: [issue7631] undefined label: bltin-file-objects
In-Reply-To: <1262599138.12.0.461032308241.issue7631@psf.upfronthosting.co.za>
Message-ID: <1262631079.19.0.880309369331.issue7631@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r77300.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Jan  4 22:18:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Jan 2010 21:18:54 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1262639934.1.0.222815333053.issue6071@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Even if it's fixed a patch with tests should be submitted before closing this issue.

----------
nosy: +ezio.melotti
priority: deferred blocker -> normal
stage: needs patch -> test needed

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

From report at bugs.python.org  Mon Jan  4 22:52:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 21:52:46 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262641966.39.0.980067942411.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Fixed a problem with the splitlines optimization: use PyList_Append instead of PyList_SET_ITEM because there's no preallocated list
in this case.

----------
Added file: http://bugs.python.org/file15737/stringlib_split_replace_v4b.diff

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

From report at bugs.python.org  Mon Jan  4 23:00:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Jan 2010 22:00:15 +0000
Subject: [issue3340] optparse print_usage(),.. methods are not documented
In-Reply-To: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za>
Message-ID: <1262642415.65.0.18031087493.issue3340@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77306 (trunk), r77307 (release26-maint), r77308 (py3k) and r77309 (release31-maint).

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Mon Jan  4 23:14:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Jan 2010 22:14:51 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262643291.27.0.817130014862.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The bug is present in the current version of dtoa.c from http://www.netlib.org/fp, so I'll report it upstream.  As far as I can tell, though, it's benign, in the sense that if the check is disabled then nothing bad happens, and the correct result is eventually returned (albeit after some unnecessary computation).

I suspect that the problem is in the if block around lines 1531--1543 of Python/dtoa.c:  a subnormal rv isn't being handled correctly here---it should end up being set to 0.0, but is instead set to 2**-968.

----------

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

From report at bugs.python.org  Mon Jan  4 23:22:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Jan 2010 22:22:53 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262643773.56.0.259483568408.issue7319@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The second paragraph ("There is also the issue...") is IMO redundant, especially the third sentence ("But because Python is an interpreted language...").

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Jan  4 23:24:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 22:24:02 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262643842.73.0.634481946654.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15735/stringlib_split_replace_v4.diff

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

From report at bugs.python.org  Mon Jan  4 23:33:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 22:33:02 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262644382.3.0.150624247243.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Updated "lib_many_fixes" patch:
 * added filterwarning for pprint
 * added fixes for Lib/sunau.py and Lib/unittest/case.py

Ready for review and merge:
 * issue7092_lib_many_fixes_v2.diff
 * issue7092_compiler.diff

----------
Added file: http://bugs.python.org/file15738/issue7092_lib_many_fixes_v2.diff

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

From report at bugs.python.org  Mon Jan  4 23:33:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 22:33:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262644388.49.0.215543733178.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15627/issue7092_lib_many_fixes.diff

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

From report at bugs.python.org  Mon Jan  4 23:34:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 22:34:23 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262644463.12.0.331947671803.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15629/issue7092_pprint.diff

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

From report at bugs.python.org  Mon Jan  4 23:38:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 22:38:44 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1262644382.3.0.150624247243.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262644776.3397.14.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

One thing: "lambda k: k in selfdata" can be replaced with
"selfdata.__contains__". It may have better performance characteristics
too.

----------

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

From report at bugs.python.org  Mon Jan  4 23:39:34 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 04 Jan 2010 22:39:34 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262644774.25.0.861390590237.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Right, I was reading the 3.1 docs by mistake.

I updated the patch. This time universal newlines are supported.

On my dataset (75MB 650K lines log file) the readline() speedup is x40 for 'r' mode and x8 for 'rU' mode, and you can get an extra bump by using the io module wrappers.

I added tests for interleaved use of readline() and read() (which add ~2 seconds to running time)

----------
Added file: http://bugs.python.org/file15739/zipfile_7610_py27.diff

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

From report at bugs.python.org  Mon Jan  4 23:52:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 22:52:49 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262645569.07.0.930453169486.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15738/issue7092_lib_many_fixes_v2.diff

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

From report at bugs.python.org  Mon Jan  4 23:53:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 22:53:15 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262645595.55.0.290130619503.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I learned something.

----------
Added file: http://bugs.python.org/file15740/issue7092_lib_many_fixes_v3.diff

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

From report at bugs.python.org  Tue Jan  5 00:12:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Jan 2010 23:12:21 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262646741.58.0.305666911891.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The test case for the previous issue.

----------
Added file: http://bugs.python.org/file15741/issue7622_test_splitlines.diff

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

From report at bugs.python.org  Tue Jan  5 00:16:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 23:16:21 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262646981.85.0.397564661993.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good, thank you.

----------
resolution:  -> accepted
stage:  -> commit review

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

From report at bugs.python.org  Tue Jan  5 00:23:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 23:23:41 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262647421.39.0.8390399287.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Both patches have been committed in r77310.

----------
stage: commit review -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Tue Jan  5 00:43:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 23:43:59 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262644774.25.0.861390590237.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262648693.3397.15.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I updated the patch. This time universal newlines are supported.

Thank you. Are you sure the "Shortcut common case" in readline() is
useful? BufferedIOBase.readline() in itself should be rather fast.

----------

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

From report at bugs.python.org  Tue Jan  5 00:49:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jan 2010 23:49:39 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262648693.3397.15.camel@localhost>
Message-ID: <1262649034.3397.18.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also, I'm not sure what happens in readline() in universal mode when the
chunk ends with a '\r' and there's a '\n' in the following chunk (see
the "ugly check" that your patch removes). Is there a test for that?

----------

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

From report at bugs.python.org  Tue Jan  5 00:56:33 2010
From: report at bugs.python.org (Richard Hansen)
Date: Mon, 04 Jan 2010 23:56:33 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262649393.34.0.802612836062.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

I thought about raw_unicode_escape more, and there's a way to escape quotes:  use unicode escape sequences (e.g., ur'\u0027').  I've attached a new patch that does the following:

 * backslash-escapes single quotes when encoding with the unicode_escape codec (the original subject of this bug)
 * replaces single quotes with \u0027 when encoding with the raw_unicode_escape codec (a separate bug not related to the original report, but brought up in comments)
 * replaces backslashes with \u005c when encoding with the raw_unicode_escape codec (a separate bug not related to the original report)
 * fixes a corner-case bug where the UTF-16 surrogate pair decoding logic could read past the end of the provided Py_UNICODE character array (a separate bug not related to the original report)
 * eliminates redundant code in PyUnicode_EncodeRawUnicodeEscape() and unicodeescape_string()
 * general cleanup in unicodeescape_string()

The changes in the patch are non-trivial and have only been lightly tested.

----------
Added file: http://bugs.python.org/file15742/unicode_escape_reorg.patch

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

From report at bugs.python.org  Tue Jan  5 01:05:04 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Jan 2010 00:05:04 +0000
Subject: [issue6071] no longer possible to hash arrays
In-Reply-To: <1242839835.2.0.379423337964.issue6071@psf.upfronthosting.co.za>
Message-ID: <1262649904.34.0.511368482894.issue6071@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Done in r77313.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

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: [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: [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:08:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Jan 2010 02:08:25 +0000
Subject: [issue1495229] W3C <-> Python DOM type mapping docs need updating
Message-ID: <1262657305.74.0.624584896083.issue1495229@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'IntType' refers to the 2.x alias types.IntType for int.
Such aliases were removed in the 3.x types module, so 'IntType' is a meaningless term in 3.x docs and should be changed to 'int' therein.

If the Python type for IDL boolean cannot be changed to 'bool', then please make it 'bool or int' so that people will know that they might get either and so that the doc and minidom will agree with each other.

----------
nosy: +tjreedy
versions: +Python 3.1, Python 3.2 -Python 2.6, Python 3.0

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

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: [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:27:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Jan 2010 02:27:13 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262658433.98.0.425679935783.issue7319@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

warnings_rst_reword.diff proposes slightly different wording on the "Updating Code..." section of documentation.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file15743/warnings_rst_reword.diff

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

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: [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: [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 04:02:38 2010
From: report at bugs.python.org (David)
Date: Tue, 05 Jan 2010 03:02:38 +0000
Subject: [issue7638] Counterintuitive str.splitlines() inconsistency.
In-Reply-To: <1262660119.0.0.105485577843.issue7638@psf.upfronthosting.co.za>
Message-ID: <1262660558.76.0.245110235467.issue7638@psf.upfronthosting.co.za>


David <vencabot_teppoo at hotmail.com> added the comment:

I typoed when copying my second snippet.

while request_buffer.splitlines[-1] != "" or request_buffer == "":


It should be:

while request_buffer.splitlines()[-1] != "" or request_buffer == "":


This code has the problem that I'm complaining of. I only failed at copying by-hand into the form.

----------

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

From report at bugs.python.org  Tue Jan  5 05:00:52 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 05 Jan 2010 04:00:52 +0000
Subject: [issue1495229] W3C <-> Python DOM type mapping docs need updating
In-Reply-To: <1262657305.74.0.624584896083.issue1495229@psf.upfronthosting.co.za>
Message-ID: <9cee7ab81001042000u46c34a23ya2eb052a7495daf1@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I presume you're referring to the documentation for the xml.dom
package (as found at
http://docs.python.org/library/xml.dom.html#type-mapping) rather than
the Python <--> OMG IDL mapping (the link for which appears to have
gone stale).

I'd support the changes you recommend for the xml.dom documentation.

----------

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

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


R. David Murray <rdmurray at bitdance.com> added the comment:

No apologies needed, but you probably aren't going to like the answer :)

First of all, a change like you propose would be unlikely to be accepted since it would create considerable backward-compatibility pain.

That aside, however, splitlines and split are not meant to be parallel.  They do two very different jobs.  splitlines is *line* oriented, and lines are understood to end with line ends.  The file equivalent of "" has length zero, and the unix 'wc' command reports it has having 0 lines.  A file containing "derp\n' is reported by wc to have one line, not two.  Files without a final line end are arguably broken, but all good tools accept that final line as a line, though some complain about it.  (And other tools break in various odd ways.)

If you want something parallel to split that handles line ends 'universally', try re.split with an appropriate regex.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

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


David <vencabot_teppoo at hotmail.com> added the comment:

Thank you for the clarification, David. I thought that it might have been a calculated decision beyond my understanding, and I can rest easy knowing that this behavior isn't accidental. I was thinking that I might have to do something like a regular expression, and I probably will. Thanks for the advice.

Have a good one!

----------

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

From report at bugs.python.org  Tue Jan  5 06:42:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Jan 2010 05:42:14 +0000
Subject: [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262670134.6.0.301132749473.issue7636@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The name should probably be "add" rather than "update", sticking with the name of the action being done on the underlying set (as update takes an iterable). Agree/disagree?

I need to add tests and docs to the patch I wrote up - I'll put it up here tomorrow.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Jan  5 08:10:39 2010
From: report at bugs.python.org (Nir Aides)
Date: Tue, 05 Jan 2010 07:10:39 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262675439.34.0.299587289481.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> Thank you. Are you sure the "Shortcut common case" in readline() 
> is useful? BufferedIOBase.readline() in itself should be rather fast.

On my dataset the shortcut speeds up readline() 400% on top of the default C implementation. 

I can take a look to why the C implementation is slow (although it is documented as "slowish").

> Also, I'm not sure what happens in readline() in universal mode when 
> the chunk ends with a '\r' and there's a '\n' in the following chunk 
> (see the "ugly check" that your patch removes). Is there a test for that?

The regular pattern returns either a line chunk or a newline (sequence) but not both. To read a line there is therefore a minimum of two peek() calls. One for the line content and the last for the newline. Since the peek is called with a value of 2, the newline sequence \r\n should be retrieved as is. There is no test for that.

----------

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

From report at bugs.python.org  Tue Jan  5 08:34:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 07:34:00 +0000
Subject: [issue7638] Counterintuitive str.splitlines() inconsistency.
In-Reply-To: <1262660119.0.0.105485577843.issue7638@psf.upfronthosting.co.za>
Message-ID: <1262676840.96.0.766563460791.issue7638@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

IMHO this code will do the trick:

while not request_buffer.endswith(('\r', '\n')):
    request_buffer += self.conn.recv(1024)
    print("Got a line!")

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

----------
nosy: +flox

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

From report at bugs.python.org  Tue Jan  5 08:35:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 07:35:39 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262676939.66.0.393480784019.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15741/issue7622_test_splitlines.diff

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

From report at bugs.python.org  Tue Jan  5 08:36:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 07:36:09 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262676969.01.0.455597729098.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15744/issue7622_test_splitlines.diff

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

From report at bugs.python.org  Tue Jan  5 08:44:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Jan 2010 07:44:09 +0000
Subject: [issue7634] next/previous links in documentation skip some sections
In-Reply-To: <1262650791.24.0.247088120925.issue7634@psf.upfronthosting.co.za>
Message-ID: <1262677449.17.0.973194741796.issue7634@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the purpose of the 'next' and 'previous' is to move to the next/previous page (i.e. file) and not another section in the same page. If you read a page till the end and then you press 'next' you probably want to go to the next page, not to next section that is in the middle of the page that you just read.
I agree that sometimes it looks weird though, especially in the index.
The only thing that IMHO could be "fixed" is limiting the number of sections in a page to 1, otherwise I'd just close this as "won't fix".

----------
nosy: +ezio.melotti
priority:  -> normal
status: open -> pending

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

From report at bugs.python.org  Tue Jan  5 09:40:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Jan 2010 08:40:16 +0000
Subject: [issue7432] Py3k doc: "from __future__ import division" not necessary
In-Reply-To: <1259879433.31.0.759735104554.issue7432@psf.upfronthosting.co.za>
Message-ID: <1262680816.38.0.855209031097.issue7432@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77314 (py3k) and r77315 (release31-maint), thanks!

----------
assignee: georg.brandl -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

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


steven Michalske <smichalske at gmail.com> added the comment:

Agreed, add is the correct word,  I used update because i created a set from the list that optarg created with append.

----------

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

From report at bugs.python.org  Tue Jan  5 11:09:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Jan 2010 10:09:57 +0000
Subject: [issue7634] next/previous links in documentation skip some sections
In-Reply-To: <1262650791.24.0.247088120925.issue7634@psf.upfronthosting.co.za>
Message-ID: <1262686197.86.0.500242103206.issue7634@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ezio is right.  The "next" links are meant to take you to the next logical file, and if one file contains multiple top-level sections, that is going to be several chapters away.

----------
resolution:  -> works for me
status: pending -> closed

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

From report at bugs.python.org  Tue Jan  5 11:50:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jan 2010 10:50:37 +0000
Subject: [issue1495229] W3C <-> Python DOM type mapping docs need updating
Message-ID: <1262688637.62.0.605652094922.issue1495229@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree that "IntegerType" makes no sense as a "Python Type" (which is how it is referred to here).

Also, the next sentence is a bit obsolete as well:

?Additionally, the DOMString defined in the recommendation is mapped to a Python string or Unicode string. Applications should be able to handle Unicode whenever a string is returned from the DOM.?

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Jan  5 11:58:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jan 2010 10:58:28 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1262689108.14.0.740823736638.issue7610@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since the peek is called with a value of 2, the newline sequence \r\n
> should be retrieved as is.

No, it doesn't follow. The \r can still appear at the end of a readahead, in which case your algorithm will not eliminate the following \n.

That is, if the sequence of readaheads is ['a\r', '\nb\n'], readlines() will return ['a\n', '\n', 'b\n'] while it should return ['a\n', 'b\n'].

It should be possible to construct a statistically valid test case for this, for example by creating an archived file containing 'a\r\n'*10000 and reading back from it.

----------

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

From report at bugs.python.org  Tue Jan  5 12:22:03 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Tue, 05 Jan 2010 11:22:03 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262690523.25.0.746579726432.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gnu.org> added the comment:

The same happens with other Context methods, like divide:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> c = getcontext()
>>> c.divide
<bound method Context.divide of Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-999999999, Emax=999999999, capitals=1, flags=[], traps=[Overflow, InvalidOperation, DivisionByZero])>
>>> c.divide(2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/decimal.py", line 3966, in divide
    return a.__div__(b, context=self)
TypeError: wrapper __div__ doesn't take keyword arguments
>>> c.divide(Decimal(2),3)
Decimal('0.6666666666666666666666666667')
>>> c.divide(6,Decimal(2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/decimal.py", line 3966, in divide
    return a.__div__(b, context=self)
TypeError: wrapper __div__ doesn't take keyword arguments

----------
nosy: +jjconti

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

From report at bugs.python.org  Tue Jan  5 13:53:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Jan 2010 12:53:36 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262696016.35.0.772543131788.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree that this would be desirable.  And yes, c.add(9, 8) should be allowed, too.

Anyone interested in producing a patch?

----------
components: +Library (Lib)
keywords: +easy
nosy: +facundobatista, rhettinger
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jan  5 15:01:07 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Tue, 05 Jan 2010 14:01:07 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262700067.15.0.257523440122.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gmail.com> added the comment:

I've been reading http://speleotrove.com/decimal and seems not to be an explicit definition about this. I'm thinking in a patch I could supply tomorrow.
What about the idea of changing the implementation from:

        return a.__add__(b, context=self)

to

        return Decimal(a+b,context=self)
?

----------
type: feature request -> 

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

From report at bugs.python.org  Tue Jan  5 15:32:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 05 Jan 2010 14:32:09 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262701929.27.0.137993003992.issue1755841@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Antoine: I got your point. Yes, I was missing the purpose of the redirection itself and the patch was wrong.

If the 301 is to be cached, the cache map should be maintained at the higher level in order for the further requests to refer to.
I have created a redirect_map at OpenerDirector level, and this will be populated by the RedirectHandler and will be referred to at time of creation of Request. This is along the correct lines, I could verify it with simple scripts and check the fetches from cache map for repeated redirects.

Your comments please.

----------
Added file: http://bugs.python.org/file15745/urllib2-301-redirection-proper.diff

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

From report at bugs.python.org  Tue Jan  5 16:42:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 15:42:08 +0000
Subject: [issue7626] Entity references without semicolon in HTMLParser
In-Reply-To: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>
Message-ID: <1262706128.71.0.108835347149.issue7626@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It is a documented behavior.
http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi

Quoted from issue500073:
"If you want to process such a document in a specific way, I
recommend to subclass HTMLParser, overriding unknown_entityref."

----------
nosy: +flox
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan  5 16:54:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jan 2010 15:54:23 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262706863.37.0.161386816375.issue1755841@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, first it would be better with some tests.

Second, what does it do for chained redirects? E.g. let's say that there's a chain of 301 redirects: A --> B --> C. Does it cache the whole A --> C mapping, or only A --> B? If the latter, will the chaining occur when looking up the redirected url from the cache (it doesn't seem to)?

Third, it seems to use a global OpenerDirector object. Are there situations where it should rather use a request-specific object?

Fourth, you shouldn't need to define a separate http_error_301 method. Just add the `cacheable` argument to `http_error_302`. Also, the `_cache_301_redirect` attribute seems useless.

----------

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

From report at bugs.python.org  Tue Jan  5 17:57:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 05 Jan 2010 16:57:52 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262710672.44.0.544394367949.issue1755841@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the comments.
Shall come with the tests. 

Yes,it currently does not handle chained redirects via cache. I dont know RFC's stance on it. RFC does not say anything about 301 chained redirects and there are tricker issues of caching anything other than 301. Basically, 302 and other require the client to check and comply with the Cache-Control and Expires header. The feature request was reasonably for caching only 301 redirs and I also feel a good one to have. This is the reason for the separate http_error_301 method.

The global opener seems to be a straight forward way to for this
activity and not a harmful too.  I can't think of request-specific
object for this one.

----------

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

From report at bugs.python.org  Tue Jan  5 18:16:17 2010
From: report at bugs.python.org (Stefan Schweizer)
Date: Tue, 05 Jan 2010 17:16:17 +0000
Subject: [issue7626] Entity references without semicolon in HTMLParser
In-Reply-To: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>
Message-ID: <1262711777.29.0.694620592198.issue7626@psf.upfronthosting.co.za>


Stefan Schweizer <steve.schweizer at gmail.com> added the comment:

I do not think that the semicolon can be omitted here, because it is not at a line break or immediately before a tag, it is in the middle of a paragraph. Anyway, I guess I have to live with the decision in issue500073.

Also I could not find an 'unknown_entityref' method in the HTMLParser module, only the now deprecated parser in htmllib had one.

----------

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

From report at bugs.python.org  Tue Jan  5 18:26:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jan 2010 17:26:24 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262712384.99.0.966164172632.issue7622@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks generally good. Can you produce a separate patch for py3k? stringobject.c has been replaced with bytesobject.c there.

----------

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

From report at bugs.python.org  Tue Jan  5 18:49:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Jan 2010 17:49:24 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262713764.93.0.9242048644.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> What about the idea of changing the implementation from:
>
>        return a.__add__(b, context=self)
>
> to
>
>         return Decimal(a+b,context=self)
> ?

I think it would be better to convert the arguments a and b to Decimal before doing the addition.  In the case of addition, it doesn't make much difference:  for integers a and b, Decimal(a+b) rounded to the current context should be the same as Decimal(a) + Decimal(b).  But for e.g., division, Decimal(a/b) is potentially different from Decimal(a)/Decimal(b).

There's also the issue that the context methods can return 'NotImplemented'.  For example:

Python 2.7a1+ (trunk:77217:77234, Jan  2 2010, 15:45:27) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> C = getcontext()
>>> C.add(Decimal(3), 'not a number')
NotImplemented

It's possible that a TypeError would make more sense here:  NotImplemented should really only be returned by direct invocation of the double underscore magic methods (__add__, etc.).

Any patch should include tests in Lib/test/test_decimal.py, of course!

----------

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

From report at bugs.python.org  Tue Jan  5 18:51:54 2010
From: report at bugs.python.org (Richard Hansen)
Date: Tue, 05 Jan 2010 17:51:54 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262713914.68.0.319424692839.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attached is a patch to the unicode unit tests.  It adds tests for the following:
  * unicode_escape escapes single quotes
  * raw_unicode_escape escapes single quotes
  * raw_unicode_escape escapes backslashes

----------
Added file: http://bugs.python.org/file15746/unicode_escape_tests.patch

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

From report at bugs.python.org  Tue Jan  5 19:02:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 18:02:43 +0000
Subject: [issue7626] Entity references without semicolon in HTMLParser
In-Reply-To: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>
Message-ID: <1262714563.92.0.219621893502.issue7626@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

For the record, this is valid HTML 4.01 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Sample</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
</head>
<body>
<p>La cl&eacute</p>
<p>La cl&eacute des champs</p>
<p>La cl&eacute; des champs</p>
</body>
</html>


Tested with http://validator.w3.org/check and Mozilla Firefox 3.5.6
Reference: http://www.is-thought.co.uk/book/sgml-6.htm#General

But HTML5 should prohibit such ambiguous syntax:
http://dev.w3.org/html5/spec/Overview.html#syntax-ambiguous-ampersand

----------

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

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: [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:17:26 2010
From: report at bugs.python.org (Steven Rumbalski)
Date: Tue, 05 Jan 2010 19:17:26 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1262719046.96.0.761403540449.issue7582@psf.upfronthosting.co.za>


Steven Rumbalski <Steven.Rumbalski at Fiserv.com> added the comment:

I think this is incorrect during daylight savings time:
tzoffset = -time.timezone // 60 

This should do it:
isdst = time.localtime().tm_isdst
tzoffset = -(time.altzone if isdst else time.timezone)//60

----------
nosy: +srumbalski

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

From report at bugs.python.org  Tue Jan  5 20:27:11 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 05 Jan 2010 19:27:11 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262719631.62.0.41357445446.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hello

I'm currently finalizing the API of my raw io file implementation, but I still have trouble with the trunk implementation of IOBase.truncate().

If I remember well, in the mailing list topic on this subject, GvR noted that this change of behaviour compared to python 2.x was not intended, and that it would be better to get back to the expected behaviour - not touching the file pointer - and to document the method in this way.

Are there new elements, advocating a status quo on this matter ?
Or shouldn't we add the portable_lseek() call in fileio.c to fix that ?

On a separate note, I'm confused about the "at most" phrase in the current documentation :
---
truncate(size=None)
    Truncate the file to at most size bytes. size defaults to the current file position, as returned by tell()
---
According to what I've read so far, a succesful truncate() call will always extend/reduce the file until teh desired size, isn't that so on all platforms ?

Regards 
Pascal

----------

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

From report at bugs.python.org  Tue Jan  5 20:36:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jan 2010 19:36:03 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1262719631.62.0.41357445446.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262720218.3289.16.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are there new elements, advocating a status quo on this matter ?

Nothing, it's just lacking a patch from someone interested in the
matter.

> On a separate note, I'm confused about the "at most" phrase in the
> current documentation :
> ---
> truncate(size=None)
>     Truncate the file to at most size bytes. size defaults to the
> current file position, as returned by tell()
> ---
> According to what I've read so far, a succesful truncate() call will
> always extend/reduce the file until teh desired size, isn't that so on
> all platforms ?

I suppose it was worded that way because some platforms may not support
extending a file when a parameter larger than the current size is given.
I don't know if such systems are widespread.

----------

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

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: [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  Tue Jan  5 20:47:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jan 2010 19:47:00 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262720820.4.0.830894705661.issue7640@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you construct a test case?
(it's even better if you fix the offending code as well of course)

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Jan  5 20:54:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Tue, 05 Jan 2010 19:54:36 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262721276.59.0.459199067643.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, I'll try to work on it as soon as I manage to gather a decent compilation environment on windows...

----------

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

From report at bugs.python.org  Tue Jan  5 21:13:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Jan 2010 20:13:32 +0000
Subject: [issue7626] Entity references without semicolon in HTMLParser
In-Reply-To: <1262549609.89.0.245956516405.issue7626@psf.upfronthosting.co.za>
Message-ID: <1262722412.63.0.419740189183.issue7626@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

w3m (a text mode browser) does not treat the &eacute without the ; as an entity ref (it puts &eacute literally into the display), while firefox does turn it into an eacute with or without the ;.  I'm sure somebody somewhere has a table listing which browsers have what behavior. 

Firefox does render, eg, &test without a trailing semi as &test.  If you want to mirror that result in code using HTMLParser, you can implement the behavior in your entityref handler.

However, this brings up an interesting issue.  Firefox also renders "&test;" literally.  You can't implement that full behavior using HTMLParser, as far as I can see, since you loose the information as to whether the entity ref was terminated by a semicolon or not. So there may be a legitimate feature request with respect to that issue.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Jan  5 21:46:47 2010
From: report at bugs.python.org (Richard Hansen)
Date: Tue, 05 Jan 2010 20:46:47 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262724407.41.0.837895481261.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15742/unicode_escape_reorg.patch

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

From report at bugs.python.org  Tue Jan  5 22:28:09 2010
From: report at bugs.python.org (Richard Hansen)
Date: Tue, 05 Jan 2010 21:28:09 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262726889.06.0.416477347254.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching updated unicode_escape_reorg.patch.  This fixes two additional issues:
  * don't call _PyString_Resize() on an empty string because there is only one empty string instance, and that instance is returned when creating an empty string
  * make sure the size parameter is nonnegative

----------
Added file: http://bugs.python.org/file15748/unicode_escape_reorg.patch

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

From report at bugs.python.org  Tue Jan  5 22:40:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 21:40:13 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262727613.19.0.521639104657.issue7622@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15737/stringlib_split_replace_v4b.diff

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

From report at bugs.python.org  Tue Jan  5 22:44:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 21:44:08 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262727848.52.0.97814814207.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Slight update:
 * Objects/unicodeobject.c
   - moved STRINGLIB_ISLINEBREAK to unicodedefs.h
   - removed FROM_UNICODE: use STRINGLIB_IS_UNICODE instead
 * Objects/stringlib/find.h
   - use STRINGLIB_WANT_CONTAINS_OBJ in find.h
     (similar to current py3k impl.)

----------
Added file: http://bugs.python.org/file15749/stringlib_split_replace_v4c.diff

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

From report at bugs.python.org  Tue Jan  5 22:50:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Jan 2010 21:50:58 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1262728258.58.0.685956346388.issue7622@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

And the Py3k patch.

(note: previous update v4b -> v4c minimize the differences
       between Py2 and Py3 implementations)

----------
versions: +Python 3.2
Added file: http://bugs.python.org/file15750/stringlib_split_replace_py3k.diff

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

From report at bugs.python.org  Wed Jan  6 00:29:12 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 05 Jan 2010 23:29:12 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262734152.37.0.356114561116.issue1755841@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

To make sure I understood something Antoine said:  By "per-request", I assume you mean the same kind of thing as the current use of .redirect_dict -- the multiple urllib2.Request instances that may result from a single request passed by the user to .open()/urlopen all sharing the same cache state.

In addition to what Antoine said:

 0. patch reports that your latest patch is malformed (see below).
 1. I'm afraid I think any 301 caching that's not per-request should be off by default.  Defaulting to on would be a significant change in behaviour, because urllib2.urlopen (and OpenerDirector.open) currently retains no state between calls (unless you add a handler that keeps state, such as HTTPCookieProcessor, but no such handlers are added by default).
 2. I imagine the code changes should be entirely (or almost entirely) confined to RedirectHandler and/or AbstractHTTPHandler.  Is there any justification for changing OpenerDirector?  Certainly no need to add any globals!
 3. http_error_30x is a documented interface, but it's not frequently used.  The argument(s) used to control caching should be somewhere else (see questions below).
 4. Please do post the doc changes for review once the implementation is decided on.


Some questions to consider:

 a. How should POST requests be handled when there is a cached permanent redirect URI?
 b. How useful is per-request caching, in the sense defined above (as opposed to per-user agent caching -- i.e. per-handler in our case)?  Best answered with data from the web.
 c. Should URIs be normalised before being used as a cache key?
 d. Might the cache get big?

For all #a, #b, #c, #d: What do existing implementations (e.g. Firefox) do?


$ patch -p0 < urllib2-301-redirection-proper.diff
patching file Lib/urllib2.py
Hunk #3 succeeded at 549 with fuzz 2 (offset 18 lines).
Hunk #4 succeeded at 562 (offset 18 lines).
patch: **** malformed patch at line 55: @@ -604,8 +618,12 @@

$ patch --version
patch 2.5.9
Copyright (C) 1988 Larry Wall
Copyright (C) 2003 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert

----------

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

From report at bugs.python.org  Wed Jan  6 00:54:10 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 05 Jan 2010 23:54:10 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262735650.7.0.819186805836.issue1755841@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

> Yes,it currently does not handle chained redirects via cache. I dont know RFC's stance on it. RFC does not say anything about 301 chained redirects

I don't see anything in the RFC that prevents us caching chained 301 redirections.  Caching the chained redirections is better, because it reduces the number of requests, which is the purpose of the cache.

> there are tricker issues of caching anything other than 301.

Antoine wasn't suggesting caching URLs from non-301 responses, just that you don't need to add a new method named "http_redirect_301".  Just delete it and test "if code == 301" in http_error_302.

> Basically, 302 and other require the client to check and comply with the Cache-Control and Expires header.

I don't think references to caching in the descriptions of the 30* response codes are relevant, because urllib2 doesn't implement response caching.  I think the part that's relevant is this: "The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs."

> The global opener seems to be a straight forward way to for this activity and not a harmful too.  I can't think of request-specific object for this one.

No.  The global OpenerDirector instance is a convenience to allow having a global urlopen() function.  Having a handler pick a random opener object (the global one) would be insane.

----------

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

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: [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 01:58:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 06 Jan 2010 00:58:39 +0000
Subject: [issue7641] Built-in Formatter accepts undocumented presentation type
In-Reply-To: <1262737962.32.0.137160455092.issue7641@psf.upfronthosting.co.za>
Message-ID: <1262739519.28.0.280472711357.issue7641@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Wed Jan  6 02:00:17 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 06 Jan 2010 01:00:17 +0000
Subject: [issue7641] Built-in Formatter accepts undocumented presentation type
In-Reply-To: <1262737962.32.0.137160455092.issue7641@psf.upfronthosting.co.za>
Message-ID: <1262739617.23.0.174810113439.issue7641@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is a duplicate of issue 5965.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Jan  6 02:21:31 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Rekucki?=)
Date: Wed, 06 Jan 2010 01:21:31 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1262740891.44.0.0623090639656.issue5965@psf.upfronthosting.co.za>


?ukasz Rekucki <lrekucki at gmail.com> added the comment:

I see a problem with silently converting types without __format__() using str(). The user may write `"{:10s}".format(some_obj)`, which will work as long as some_obj doesn't have a formatter of it's own. If I later on, decide I want to add some custom formating to that object, there is a large chance I'll break a lot of code, 'cause doing it in backward-compatible way seems very difficult.

----------
nosy: +lrekucki

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

From report at bugs.python.org  Wed Jan  6 02:41:02 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Jan 2010 01:41:02 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262742062.81.0.133693031731.issue7640@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem seems to be fixed in trunk (the future 2.7).
BufferedRandom.seek() contains a block labelled "# Undo read ahead." which does not exists in 2.6.

I reproduce the problem with a file opened with mode "rb+"

from io import open
open("tmpfile", "wb").write("abcdefgh" * 1024 + "X")
f = open("tmpfile", "rb+")
print f.read(1) # "a"
f.seek(0, 1)
print f.read(1) # should be "b", 2.6 returns "X"

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Wed Jan  6 02:47:23 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Wed, 06 Jan 2010 01:47:23 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262742443.81.0.614687243749.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gmail.com> added the comment:

The attached patch solves this issue.

Finally, only operand 'a' needs to be converted to Decimal if it's not. I discover this after writing my tests and start the implementation.

A Context.method is modified if it has more than one operand (for example a and b) and Decimal.method uses _convert_other

26 Context's methods were modified.

26 unit tets were added to ContextAPItests TestCase.

docstring was added to Context.divmod

----------
keywords: +patch
type:  -> behavior
Added file: http://bugs.python.org/file15751/issue7633_jjconti.patch

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

From report at bugs.python.org  Wed Jan  6 02:56:13 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Wed, 06 Jan 2010 01:56:13 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1262742973.78.0.760901867459.issue6484@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

Attached is a new file for testing the mailcap module in Python 2.7.

Writing the test was a little tricky because the existence and contents of the .mailcap file(s) will vary depending on the system or user. Therefore, the test mostly uses its own version of .mailcap, which I will also submit to this issue.

This is the first patch I've ever submitted to Python Core Development. Any feedback is appreciated.

----------
Added file: http://bugs.python.org/file15752/test_mailcap.py

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

From report at bugs.python.org  Wed Jan  6 03:00:44 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Wed, 06 Jan 2010 02:00:44 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1262743244.44.0.00424779162243.issue6484@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

This is a sample .mailcap I created for the test. It should also go in the Lib/test directory.

It begins with a period due to a mailcap file naming convention (see RFC 1524). Is it OK that the file will be semi-hidden?

----------
Added file: http://bugs.python.org/file15753/.mailcap

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

From report at bugs.python.org  Wed Jan  6 03:03:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Jan 2010 02:03:42 +0000
Subject: [issue1495229] W3C <-> Python DOM type mapping docs need updating
Message-ID: <1262743422.69.0.302957470475.issue1495229@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Fred: yes, specifically the 3.x versions.

I just noticed that the currently specification is 'IntegerType", which was never used in Python, rather than IntType, which was.

The dead link you refer to is this at the top:
"Python Language Mapping Specification
    This specifies the mapping from OMG IDL to Python."
The current non-working link is
http://www.omg.org/docs/formal/02-11-05.pdf
The new link, which works, is
http://www.omg.org/cgi-bin/doc?formal/02-11-05.pdf
I found this on
http://www.omg.org/cgi-bin/apps/doclist.pl

This should be fixed in all versions.

Antoine: the 3.x version is "Additionally, the DOMString defined in the recommendation is mapped to a bytes or string object. Applications should be able to handle Unicode whenever a string is returned from the DOM." Assuming the first sentence is true, I would just delete the second (for 3.x) as just about every 3.x app must deal with 3.x (unicode) strings.

Summary of recommendations:

1. Replace dead link with new version.

2. Replace 'IntegerType' with 'int' except that entry for IDL boolean should be 'bool or int'.

3a. Could not first sentence referred to above be replaced by a line in the table mapping 'DOMString' to 'string or bytes'? Or is DOMString not an IDL type? Even so, I would put it in the table with a footnote.

3b. Delete obsolete second sentence.

4. Should not the final sentence "The IDL null value is mapped to None, which may be accepted or provided by the implementation whenever null is allowed by the API." be replaced by an additional line in the table
(IDL Type) null .... (Python Type) None
I do not see that rest of sentence adds anything.

Once a set of changes is agreed on, this issue could be reassigned to doc maintainer Georg Brandl to make changes and close this.

Note: my personal concern is with 3.x docs, except that bad link should be fixed for 2.6,7 also.

----------

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

From report at bugs.python.org  Wed Jan  6 03:13:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Jan 2010 02:13:11 +0000
Subject: [issue1495229] W3C <-> Python DOM type mapping docs need updating
Message-ID: <1262743991.52.0.605010091767.issue1495229@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Addendum. Table 1-2 Basic Data Type Mappings in the referenced OMG document, which maps 'OMG IDL' to 'Python' has 'Integer (<type 'int'>)', later shortened to 'Integer'. (It also has 'Long integer(<type 'long int'>)' and 'Floating Point Number (<type 'float'>)' with similar abbreviations.) So 'IntegerType', possibly mashing together 'Integer' with 'IntType', appears to be an erroneous term from the beginning.

----------

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

From report at bugs.python.org  Wed Jan  6 03:22:05 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jan 2010 02:22:05 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262744525.62.0.955211643736.issue1755841@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Attaching a non-malformed patch. I had incomplete tests in previous ones and I removed it by-hand before submitting for review. Something went wrong, I see.

Okay, I get the points you are making. Specifically a request specific object and then maintaining a map at AbstractHTTPHandler/HTTPRedirectHandler. Shall come up with such a method.

----------
Added file: http://bugs.python.org/file15754/urllib2-301-patch.diff

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

From report at bugs.python.org  Wed Jan  6 03:22:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jan 2010 02:22:17 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262744537.18.0.173828256653.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file15745/urllib2-301-redirection-proper.diff

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

From report at bugs.python.org  Wed Jan  6 03:22:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jan 2010 02:22:25 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262744545.75.0.672473759363.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file15722/urllib2-301-redirection-CORRECTED.diff

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

From report at bugs.python.org  Wed Jan  6 03:22:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jan 2010 02:22:36 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262744556.74.0.793671869567.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file8117/liburllib2.patch

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

From report at bugs.python.org  Wed Jan  6 03:22:42 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jan 2010 02:22:42 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262744562.64.0.215818340661.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file8116/test_urllib2-cache.patch

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

From report at bugs.python.org  Wed Jan  6 03:22:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jan 2010 02:22:54 +0000
Subject: [issue1755841] Patch for [ 735515 ] urllib2 should cache 301 redir
Message-ID: <1262744574.9.0.620859907685.issue1755841@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file8115/urllib2-301-cache.patch

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

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: [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 06:14:52 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Jan 2010 05:14:52 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two
	corrupted	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1262754892.48.0.22797495702.issue7437@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I've built an installer image to test this consisting of 2.6.4 plus r76715.  If you're still willing to test this on 10.3, I'll contact you via email with the download details.

----------

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

From report at bugs.python.org  Wed Jan  6 06:28:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jan 2010 05:28:58 +0000
Subject: [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262755738.08.0.594009003339.issue7636@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

After looking into it, I'm thinking this may be better off as a custom option inherited from optparse.Option. I already wrote the patch since it was small and a way to poke around optparse some more, so we'll see if anyone else likes the idea.

----------
keywords: +patch
Added file: http://bugs.python.org/file15756/issue7636.diff

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

From report at bugs.python.org  Wed Jan  6 06:32:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jan 2010 05:32:18 +0000
Subject: [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262755938.27.0.984936936051.issue7636@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

custom_add.py gives an example of how you could complete this on your own without a change to optparse. Running "custom_add.py -a foo -a bar -a foo" should print out "set(['foo', 'bar'])" - ultimately the same thing.

----------
Added file: http://bugs.python.org/file15757/custom_add.py

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

From report at bugs.python.org  Wed Jan  6 07:57:02 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Jan 2010 06:57:02 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262761022.39.0.314557500297.issue7319@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

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

From report at bugs.python.org  Wed Jan  6 08:48:05 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Jan 2010 07:48:05 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262764085.87.0.641220677396.issue7319@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file15731/silence_deprecations.diff

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

From report at bugs.python.org  Wed Jan  6 08:50:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Jan 2010 07:50:23 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262764223.51.0.258871085315.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the feedback, everyone. The tabs have been fixed in the source. As for the docs, I moved the explanation as to why the warnings are silenced to the end of the section and chopped the "compilation" reasoning as it is not the critical reason for the silencing.

----------
keywords: +needs review
stage:  -> patch review
Added file: http://bugs.python.org/file15758/silence_deprecations.diff

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

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: [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 10:14:10 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 06 Jan 2010 09:14:10 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <4B44545E.6090805@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> 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']

Unicode has more line break characters defined than ASCII, which
only has a single line break character \n, but also uses the
conventions \r and \r\n for meaning "start a new line,
go to position 1".

See e.g. http://en.wikipedia.org/wiki/Ascii#ASCII_control_characters

The three extra code points Unicode defines for line breaks are
group separators that are not in common use.

----------
nosy: +lemburg

_______________________________________
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: [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 11:35:39 2010
From: report at bugs.python.org (Michael Mullins)
Date: Wed, 06 Jan 2010 10:35:39 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1262774139.36.0.63522357181.issue7644@psf.upfronthosting.co.za>


Changes by Michael Mullins <pabloonbreak at gmail.com>:


----------
components: +Library (Lib)
type:  -> crash

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

From report at bugs.python.org  Wed Jan  6 11:47:48 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 10:47:48 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262774868.26.0.747505339124.issue7640@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

My bad, I had looked at _buffered_raw_seek, not buffered_seek >_<
Indeed, the code is OK in both trunk _io an _pyio modules.
And the SEEK_CUR flag (value : 1) seems more than sufficiently tested in test_io actually, for example in the function write_ops() :
http://svn.python.org/view/python/trunk/Lib/test/test_io.py?view=markup

So concerning python2.6, isn't that just possible to backport _pyio (and its test suite) to it (renamed as io.py) ? They seem to offer the same functionality, except that _pyio is much more robust than io.py (the code around seek(), in particular, is much more complete).
Just tell me, else I'll gather a patch for the seek() problem.

----------

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

From report at bugs.python.org  Wed Jan  6 11:53:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Jan 2010 10:53:35 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262774868.26.0.747505339124.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262775272.3525.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So concerning python2.6, isn't that just possible to backport _pyio
> (and its test suite) to it (renamed as io.py) ?

I would not be against it, but someone has to provide a patch.
The current _pyio.py might rely on other new behaviour of 2.7, so
perhaps it won't be that easy.

----------

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

From report at bugs.python.org  Wed Jan  6 11:53:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Jan 2010 10:53:41 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262775221.37.0.670383214962.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch!

Rather than using the Decimal constructor, I think you should convert use _convert_other(..., raiseit=True):  the Decimal constructor converts strings and tuples, as well as ints and longs, while _convert_other only converts ints and longs.  Note also that the conversion shouldn't depend on the current context;  only the operation itself needs that.

Maybe it would be worth adding some tests to ensure that e.g.,

MyContext.add('4.5', 123)

raises TypeError as expected?

I agree with the observation that it's usually only necessary to convert the first argument (since the Decimal method itself converts the second).

If you like, you could also usefully deal with the NotImplemented return value by turning it into a TypeError (i.e., in the context method, check for a NotImplemented return value, and raise TypeError there if necessary).  This is only needed for the double underscore methods __add__, __sub__, etc.  associated with Python's binary operators;  the other methods shouldn't ever return NotImplemented.

----------

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

From report at bugs.python.org  Wed Jan  6 12:26:06 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 11:26:06 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262777166.11.0.72866159601.issue7640@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hum, with a selective merge (tortoiseSVN makes it easy), backporting _pyio should be doable in a decent time. Triaging pertinent tests should be more brain damaging :p
I'm looking at this.

----------

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

From report at bugs.python.org  Wed Jan  6 14:21:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jan 2010 13:21:56 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1262784116.65.0.756251193583.issue7644@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

('crash' is for the interpreter crashing)

Unfortunately there currently are no unit tests for nntplib.  Unless someone feels like creating an nntp test framework we may have to commit this fix without a test.

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
type: crash -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Wed Jan  6 15:23:18 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 14:23:18 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1262787798.71.0.343532082916.issue7640@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Well, here is a patch for the seek() methods of io module, in python2.6 maintenance branch.
Finally, I've only backported some assertions and the offset stuffs - I'm not comfortable enough about recent io refactorings to do more (it changed pretty quickly while I looked away, actually :p).
Tests have been patched too (bufferedrandom wasn't tested as other buffer classes), and to have the whole suite pass, I had to modify testWriteNonBlocking() as well (mock objects returned wrong values - this test is marked as unreliable in sources anyway).
If more is needed to patch the py2.6 branch, just tell me B-)

----------
keywords: +patch
Added file: http://bugs.python.org/file15759/seek_cur_buffers_py26.patch

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

From report at bugs.python.org  Wed Jan  6 16:38:28 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 06 Jan 2010 15:38:28 +0000
Subject: [issue7627] mailbox.MH.remove() lock handling is broken
In-Reply-To: <1262564711.76.0.763774175522.issue7627@psf.upfronthosting.co.za>
Message-ID: <1262792308.89.0.695752925857.issue7627@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee:  -> akuchling
nosy: +akuchling

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

From report at bugs.python.org  Wed Jan  6 16:48:40 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 06 Jan 2010 15:48:40 +0000
Subject: [issue5368] curses patch add color_set and wcolor_set ,
	and addchstr family of functions
In-Reply-To: <1235583031.0.0.493464972804.issue5368@psf.upfronthosting.co.za>
Message-ID: <1262792920.8.0.66731178563.issue5368@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: georg.brandl -> akuchling

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

From report at bugs.python.org  Wed Jan  6 17:26:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Jan 2010 16:26:23 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262795183.13.0.624691908942.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the missing divmod docstring, too:  I've applied this separately, partly because it needs to go into 2.6 and 3.1 as well as 2.7 and 3.2, and partly as an excuse to check that the new py3k-cdecimal branch is set up correctly.  See revisions r77324 through r77327.

----------

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

From report at bugs.python.org  Wed Jan  6 17:30:33 2010
From: report at bugs.python.org (=?utf-8?b?Sm96ZWYgR8OhYm9yw61r?=)
Date: Wed, 06 Jan 2010 16:30:33 +0000
Subject: [issue7601] Installation - 2 tests failed: test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262795433.31.0.887976822527.issue7601@psf.upfronthosting.co.za>


Jozef G?bor?k <jozef.gaborik at gmail.com> added the comment:

Thank you!

----------

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

From report at bugs.python.org  Wed Jan  6 17:31:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Jan 2010 16:31:48 +0000
Subject: [issue7601] Installation - 2 tests failed: test_cmd_line test_xmlrpc
In-Reply-To: <1262191284.36.0.167842926616.issue7601@psf.upfronthosting.co.za>
Message-ID: <1262795508.46.0.819077793703.issue7601@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks to you for the report :)

----------

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

From report at bugs.python.org  Wed Jan  6 17:42:05 2010
From: report at bugs.python.org (Tim Mooney)
Date: Wed, 06 Jan 2010 16:42:05 +0000
Subject: [issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
In-Reply-To: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za>
Message-ID: <1262796125.66.0.294403440814.issue6299@psf.upfronthosting.co.za>


Tim Mooney <enchanter at users.sourceforge.net> added the comment:

This still happens in 2.6.3 and 2.6.4 so I spent some time looking at it.

It's happening because of a combination of issues, but ultimately it's because python's build isn't making certain that it's including its private copy of expat.h and expat_external.h.

Basically, this

-DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.4/./Modules/expat

should *precede* CFLAGS, rather than coming after it.

To reproduce:

- install expat 2.0.1 under /usr/local or /opt (or any prefix other
  than just /usr)
- include -I$prefix/include in CFLAGS when configuring Python
- make

This results in the special includes for python's local copy of the expat sources being *after* the -I/usr/local/include on the command line, so the copy of expat.h and expat_external.h in /usr/local/include are found first, and that causes the link failure when generating pyexpat.so.

Note that it's not just as simple as not including -I/usr/local/include in CFLAGS, because there may be other locally-installed packages that python should be finding to build other modules.

The real fix is for Python's build machinery to make certain that the special includes for Python's private expat sources precede CFLAGS.

----------

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

From report at bugs.python.org  Wed Jan  6 18:28:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Jan 2010 17:28:48 +0000
Subject: [issue6067] make error
In-Reply-To: <1242810066.3.0.038429040919.issue6067@psf.upfronthosting.co.za>
Message-ID: <1262798928.66.0.111122367145.issue6067@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing due to lack of response.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Wed Jan  6 18:31:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Jan 2010 17:31:05 +0000
Subject: [issue5959] PyCode_NewEmpty
In-Reply-To: <1241720694.59.0.328707962514.issue5959@psf.upfronthosting.co.za>
Message-ID: <1262799065.4.0.475695302727.issue5959@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

PyCode_NewEmpty has been merged in r74132.

----------
nosy: +georg.brandl
status: open -> closed

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

From report at bugs.python.org  Wed Jan  6 18:31:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Jan 2010 17:31:42 +0000
Subject: [issue5954] PyFrame_GetLineNumber
In-Reply-To: <1241679764.04.0.154044942183.issue5954@psf.upfronthosting.co.za>
Message-ID: <1262799102.89.0.121188256436.issue5954@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This was merged in r74132.

----------
nosy: +georg.brandl
status: open -> closed

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

From report at bugs.python.org  Wed Jan  6 19:02:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Jan 2010 18:02:34 +0000
Subject: [issue5991] Add non-command help topics to help completion of cmd.Cmd
In-Reply-To: <1241999603.41.0.146280599558.issue5991@psf.upfronthosting.co.za>
Message-ID: <1262800954.76.0.643499992754.issue5991@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch; applied and fixed up a bit in r77332.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Wed Jan  6 19:26:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Jan 2010 18:26:36 +0000
Subject: [issue5950] zimport doesn't work with zipfile containing comments
In-Reply-To: <1241628586.95.0.0801479384158.issue5950@psf.upfronthosting.co.za>
Message-ID: <1262802396.1.0.949054017936.issue5950@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, comments are not supported right now. Documented this in r77333, and turning this issue into a feature request for adding that support.

----------
nosy: +georg.brandl
type:  -> feature request

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

From report at bugs.python.org  Wed Jan  6 20:13:56 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Wed, 06 Jan 2010 19:13:56 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1262805236.66.0.962939103616.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gmail.com> added the comment:

New patch.

Fix Context.method that were returning NotImplemented.
Decimal.__methods__ don't use raiseit=True in _convert_other so I check in Context.method and raise TypeError if necessary.

Added tests for Context.divmod missed in first patch.

----------
Added file: http://bugs.python.org/file15760/issue7633_jjconti2.patch

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

From report at bugs.python.org  Wed Jan  6 20:56:22 2010
From: report at bugs.python.org (Austin English)
Date: Wed, 06 Jan 2010 19:56:22 +0000
Subject: [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: [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 20:59:12 2010
From: report at bugs.python.org (Austin English)
Date: Wed, 06 Jan 2010 19:59:12 +0000
Subject: [issue7646] test_telnetlib fails in Windows XP
In-Reply-To: <1262807945.09.0.76029719332.issue7646@psf.upfronthosting.co.za>
Message-ID: <1262807952.58.0.71428216127.issue7646@psf.upfronthosting.co.za>


Changes by Austin English <austinenglish+python at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Wed Jan  6 21:16:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jan 2010 20:16:22 +0000
Subject: [issue6511] zipfile: Invalid argument when opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1262808982.24.0.167926085391.issue6511@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've backported this to 2.6 in r77334 and to 3.1 in r77335.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> committed/rejected

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

From report at bugs.python.org  Wed Jan  6 21:18:06 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 20:18:06 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262809086.96.0.445873931244.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hi

Here is a patch for the python2.6 _fileio.c module, as well as the corresponding testcase.
I'll check the _pyio and C _io trunk modules asap.

----------
keywords: +patch
Added file: http://bugs.python.org/file15763/python26_io_truncate_bugfix.patch

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

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


Changes by Adam Jackson <ajax at redhat.com>:


----------
type:  -> feature request

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

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


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

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

From report at bugs.python.org  Wed Jan  6 21:40:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 06 Jan 2010 20:40:23 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262810423.8.0.102568096111.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Still some "-3" warnings to silence:

./python -3m "collections" >/dev/null
./python -3c "import Cookie"
./python -3c "import idlelib.rpc"
./python -3c "import logging.handlers"
./python -3c "import multiprocessing"
./python -3c "import shelve"
./python -3c "import trace"

All these modules yield:
"DeprecationWarning: the cPickle module has been removed in Python 3.0"

There's also "bsddb" but it is deprecated.

----------
status: pending -> open

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

From report at bugs.python.org  Wed Jan  6 21:52:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Jan 2010 20:52:17 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262811137.1.0.128980219467.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> All these modules yield:
> "DeprecationWarning: the cPickle module has been removed in Python 3.0"

I think this warning is both annoying (cPickle is a legitimate module to use in 2.x, since pickle is much slower) and useless (2to3 should be able to do the module rename -- Benjamin, does it?). Therefore I suggest to remove this warning.

----------

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

From report at bugs.python.org  Wed Jan  6 21:59:19 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 06 Jan 2010 20:59:19 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262811559.76.0.650331726432.issue7092@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> I think this warning is both annoying (cPickle is a legitimate module to use in 2.x, since pickle is much slower) and useless (2to3 should be able to do the module rename -- Benjamin, does it?). Therefore I suggest to remove this warning.

You may be right, but keep in mind that cPickle and pickle are only *mostly* compatible with each other.  There are uses of one which will not automatically work if you switch to the other.

----------

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

From report at bugs.python.org  Wed Jan  6 21:59:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jan 2010 20:59:35 +0000
Subject: [issue7645] test_distutils fails on Windows XP
In-Reply-To: <1262807781.76.0.367553383725.issue7645@psf.upfronthosting.co.za>
Message-ID: <1262811575.74.0.591014486307.issue7645@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +tarek

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

From report at bugs.python.org  Wed Jan  6 22:00:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jan 2010 21:00:14 +0000
Subject: [issue7645] test_distutils fails on Windows XP
In-Reply-To: <1262807781.76.0.367553383725.issue7645@psf.upfronthosting.co.za>
Message-ID: <1262811614.03.0.39033100878.issue7645@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> tarek
components: +Distutils
priority:  -> normal

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

From report at bugs.python.org  Wed Jan  6 22:02:16 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 21:02:16 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262811736.75.0.760032134608.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Whoups - I forgot to bugfix as well the _bytesio classes... let's just forget about the previous patch.

----------

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

From report at bugs.python.org  Wed Jan  6 22:03:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 06 Jan 2010 21:03:25 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262811805.29.0.94011599236.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

+1 to remove this boring cPickle message.

cStringIO do not print such messages.

----------

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

From report at bugs.python.org  Wed Jan  6 22:36:39 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 21:36:39 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262813799.58.0.435746896697.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Here is the new patch for py2.6, fixing (hopefully) all the truncate() methods.
Note that the python _BytesIO implementation isn't covered by the test suite, as it's shadowed by the C implementation ; but imo we shouldn't care : I've manually tested it once, and anyway the trunk sources don't have this problem.

----------
Added file: http://bugs.python.org/file15765/python26_full_truncate_patch.patch

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

From report at bugs.python.org  Wed Jan  6 22:38:52 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 06 Jan 2010 21:38:52 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1262813932.39.0.578721139601.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

And here is the python trunk patch, covering _Pyio and _io modules (+ corresponding tests).

----------
Added file: http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch

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

From report at bugs.python.org  Wed Jan  6 23:09:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jan 2010 22:09:47 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262815787.45.0.304595010679.issue7319@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The wording of the documentation flows and is arranged better than before.

However, there is a test failure: test_exceptions.testDeprecatedMessageAttribute depends on the deprecation warning always occuring. 
@unittest.skipIf(DeprecationWarning in [filter[2] for filter in warnings.filters], "DeprecationWarning disabled") or something like that could avoid it.

----------

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

From report at bugs.python.org  Wed Jan  6 23:19:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Jan 2010 22:19:08 +0000
Subject: [issue3660] reference leaks in test_distutils
In-Reply-To: <1219605179.44.0.949380312397.issue3660@psf.upfronthosting.co.za>
Message-ID: <1262816348.48.0.558241602073.issue3660@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This issue has been fixed.

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

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: [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 00:56:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jan 2010 23:56:58 +0000
Subject: [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: <1262822218.9.0.47778498963.issue7648@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Tests
keywords: +easy
nosy: +orsenthil
priority:  -> low
type:  -> behavior

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

From report at bugs.python.org  Thu Jan  7 01:03:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 07 Jan 2010 00:03:19 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1262822599.17.0.120697572233.issue7643@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

'\x85' when decoded using latin-1 is just transcoded to u'\x85' which is treated as the NEL (a C1 control code equivalent to end of line). This changes iteration over the file when you decode and actually broke our csv parsing code when we got some latin-1 encoded data with \x85 in it from our customer.

----------
nosy: +michael.foord

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

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: [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:30:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jan 2010 01:30:07 +0000
Subject: [issue7519] ConfigParser can't read files with BOM markers
In-Reply-To: <1260905357.88.0.211998340765.issue7519@psf.upfronthosting.co.za>
Message-ID: <1262827807.0.0.685299656327.issue7519@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Use utf_8_sig charset and open your file using io.open() or codecs.open() to get unicode sections, options and values.

Example:
-------------------------------------
from ConfigParser import ConfigParser
import io

# create an utf-8 .ini file with a BOM marker
with open('bla.ini', 'wb') as fp:
    fp.write(u'[section]\ncl\xe9=value'.encode('utf_8_sig'))

# read the .ini file
config = ConfigParser()
with io.open('bla.ini', 'r', encoding='utf_8_sig') as fp:
    config.readfp(fp)

# dump the config
for section in config.sections():
    print "[", repr(section), "]"
    for option in config.options(section):
        value = config.get(section, option)
        print "%r=%r" % (option, value)
-------------------------------------

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Jan  7 02:41:23 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 01:41:23 +0000
Subject: [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: <1262828483.4.0.533841033629.issue7649@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Jan  7 02:41:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 01:41:58 +0000
Subject: [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: <1262828518.75.0.111537765351.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This looks like a signed vs. unsigned char problem. What platform are you on?

----------

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

From report at bugs.python.org  Thu Jan  7 02:46:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 01:46:04 +0000
Subject: [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: <1262828764.21.0.611237079844.issue7649@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +doerwalter

_______________________________________
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: [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 02:55:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jan 2010 01:55:46 +0000
Subject: [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: <1262829346.69.0.731343511263.issue7649@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is the cast char => Py_UNICODE in formatchar() function. char may be unsigned, but most of the time it's signed. signed => unsigned cast extend the sign. Example: (unsigned short)(signed char)0x80 gives 0xFF80.

Attached patch fixes the issue and includes an unit test.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file15768/unicode_formatchar.patch

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

From report at bugs.python.org  Thu Jan  7 03:01:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jan 2010 02:01:54 +0000
Subject: [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: <1262829714.4.0.520304108.issue7649@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is specific to Python 2.x. With Python3, "%c" expects one unicode character (eg. "a").

My patch fixes the char => Py_UNICODE conversion, but raising an error is maybe better to be consistent with u"%s" % "\x80" (and prepare the migration the Python3).

----------

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

From report at bugs.python.org  Thu Jan  7 03:48:38 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 02:48:38 +0000
Subject: [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: <1262832518.91.0.974797470207.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Shouldn't it work the same as it does for integers?

>>> u'%c' % 0x7f
u'\x7f'
>>> u'%c' % '\x7f'
u'\x7f'
>>> u'%c' % 0x80
u'\x80'
>>> u'%c' % '\x80'
u'\uff80'

That would imply to me it shouldn't be an error, it should just return u'\x80'.

----------

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

From report at bugs.python.org  Thu Jan  7 03:50:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 02:50:47 +0000
Subject: [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: <1262832647.5.0.0308579354838.issue7649@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
keywords: +easy
priority: high -> normal
stage: test needed -> patch review

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

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: [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 05:29:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 04:29:11 +0000
Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as
	Python comments
In-Reply-To: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za>
Message-ID: <1262838551.32.0.114624059965.issue1034@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think this would be a good addition so I took Adrian's patch and brought it up to date. I'll need to expand the testing, but I think Benjamin's 1 and 3 are covered.

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file15769/issue1034.diff

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

From report at bugs.python.org  Thu Jan  7 05:30:27 2010
From: report at bugs.python.org (Michael Mullins)
Date: Thu, 07 Jan 2010 04:30:27 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1262838627.71.0.871070981315.issue7644@psf.upfronthosting.co.za>


Michael Mullins <pabloonbreak at gmail.com> added the comment:

"('crash' is for the interpreter crashing)"

Sorry.

     "Unless someone feels like creating an nntp test framework..."

This sounds like it is beyond me. But given the evidence, specifically the previous line:

     "file.write(line + b'\n')"

...the module is obviously writing as binary. I know that opening the files created by this method in 3.0 requires the 'rb' flag so it seems a safe bet. And I am actually using this module (as revised above) to get work done.

...

I apologise if this isn't the place for this (should I open another ticket?) but as a larger issue with 3.x in general, it was very confusing about when to use binary data and when to use strings when using nntplib. It took a lot of trial and error. If there was someway to make this more clear, or perhaps the methods themselves could be made flexible, excepting both types but always outputing in binary. (Liberal with input but conservative in output.) This would allow anyone working with nntplib to interact with the module in a completely binary way, understanding that all output will be explicitly binary, and that if strings are necessary, it's for the user to decode().

Just a thought.

MDMullins

----------

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

From report at bugs.python.org  Thu Jan  7 05:31:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 04:31:10 +0000
Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as
	Python comments
In-Reply-To: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za>
Message-ID: <1262838670.24.0.857534760503.issue1034@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Thu Jan  7 08:11:35 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Jan 2010 07:11:35 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262848295.34.0.621493595502.issue7319@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file15758/silence_deprecations.diff

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

From report at bugs.python.org  Thu Jan  7 08:12:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Jan 2010 07:12:23 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262848343.57.0.324448630829.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Latest patch adds fixes to test_exceptions test_ascii_formatd to pass.

----------
Added file: http://bugs.python.org/file15770/silence_deprecations.diff

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

From report at bugs.python.org  Thu Jan  7 09:19:51 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 08:19:51 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262852391.89.0.56559209663.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15748/unicode_escape_reorg.patch

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

From report at bugs.python.org  Thu Jan  7 09:42:07 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 08:42:07 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262853727.3.0.475007409598.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching updated unicode_escape_reorg.patch.  This addresses two additional issues:
  * removes pickle's workaround of raw-unicode-escape's broken escaping
  * eliminates duplicated code (the raw escape encode function was copied with only a slight modification in cPickle.c)

With this, all regression tests pass.

----------
Added file: http://bugs.python.org/file15771/unicode_escape_reorg.patch

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

From report at bugs.python.org  Thu Jan  7 10:03:13 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 09:03:13 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262854993.09.0.216840552495.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

I believe this issue is ready to be bumped to the "patch review" stage.  Thoughts?

----------

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

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: [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 12:40:48 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 11:40:48 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262864448.85.0.443072090375.issue7652@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Is the intention to write Decimal.__format__ in C, too? That would be quite a bit of work, and I'm not sure I could recommend it. But I'm not sure if your plan is to get rid of all Python code or not.

If your plan is to rewrite absolutely everything in C, I could help out by exposing the methods that parse format specifiers and do some of the low level formatting. They're used internally by the int, float, and str formatting code. Let me know.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Jan  7 12:49:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 11:49:17 +0000
Subject: [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: <1262864957.57.0.964886577876.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If we allow it to work on 2.7 the code will break:
1) when ported to Py3, where mixing bytes strings and unicode is not allowed;
2) when used on Py<2.7, where the behavior is broken;
3) when converted to str.format, where only ints are accepted.

If we raise an error, the user will have to either use unicode strings or ints and he will avoid further problems. Moreover, the fact that no one noticed this problems means that is not a common operation, so no one probably expects it to work anyway and raising an error could even help to find the problem if someone used %c in older versions.

----------

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

From report at bugs.python.org  Thu Jan  7 12:55:59 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Jan 2010 11:55:59 +0000
Subject: [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: <1262865359.31.0.44690031896.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

There's no perfect answer. And since we've gotten this far without anyone caring, and 2.7 is basically the end of life for this issue, perhaps doing nothing is the best course. Any change we make will affect code that runs in both 2.6 and 2.7, doing nothing preserves compatibility on the 2.x side.

----------

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

From report at bugs.python.org  Thu Jan  7 13:37:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Jan 2010 12:37:18 +0000
Subject: [issue7644] bug in nntplib.body() method with possible fix
In-Reply-To: <1262773754.82.0.67564143033.issue7644@psf.upfronthosting.co.za>
Message-ID: <1262867838.26.0.984153719048.issue7644@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, it should be another issue.  That said, there are similar (worse, actually) problems with the py3 email package that we are moving toward addressing.  There we are planning to have dual APIs.  If you want to work on fixing nntplib similarly, that would be great.  I'm expecting there to be synergy between the two, so you might be interested in joining the effort to update the email module as well.  See http://wiki.python.org/moin/Email%20SIG for more details.  (Trying to use nntplib in py3 is how I myself wound up involved in the email effort).

----------

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

From report at bugs.python.org  Thu Jan  7 14:02:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Jan 2010 13:02:08 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262869328.41.0.728063629472.issue7615@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Does the last patch obsolete the first two?  If so please delete the obsolete ones.

I imagine there are might be small doc updates required, as well.

I haven't looked at the patch itself, but concerning your test patch:  your try/except style is unnecessary, I think.  Better to just let the syntax error bubble up on its own.  After all, you don't *know* that the SyntaxError is because the quotes aren't escaped.  I've run into other unit tests in the test suite where the author made such an assumption, which turned out to be false and confused me for a bit while debugging the failure.  I had to remove the code producing the mistaken reason message in order to see the real problem.  So it's better to just let the real error show up in the first place, in my experience.

----------
nosy: +r.david.murray
stage: test needed -> patch review

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

From report at bugs.python.org  Thu Jan  7 14:02:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 13:02:39 +0000
Subject: [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: <1262869359.12.0.90000807045.issue7649@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Tested on 2.5...

~ $ python2.5
Python 2.5.2 (r252:60911, Jan  4 2009, 21:59:32) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> u'%c' % '\x80'
u'\Uffffff80'
>>> 

On 2.7 (trunk) I get same behaviour as described on msg97334.

----------
nosy: +flox

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

From report at bugs.python.org  Thu Jan  7 14:35:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 13:35:59 +0000
Subject: [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: <1262871359.69.0.326315802597.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

First patch that makes u'%c' % '\x80' raise a UnicodeDecodeError.

I could reproduce the problem on Linux 32/64bit, Windows 32bit and Python from 2.4 to 2.7. The '\Uffffff80' is returned by wide builds.

----------
Added file: http://bugs.python.org/file15772/issue7649.diff

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

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


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to clarify, no decision has yet been made on *whether* the cdecimal work should be integrated into py3k;  we'll consult python-dev on this once we've got a working branch and performance information.

----------

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

From report at bugs.python.org  Thu Jan  7 15:28:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 14:28:33 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1262874513.46.0.128021491492.issue7319@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15743/warnings_rst_reword.diff

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

From report at bugs.python.org  Thu Jan  7 15:29:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 14:29:47 +0000
Subject: [issue1034] [patch] Add 2to3 support for displaying warnings as
	Python comments
In-Reply-To: <1188181252.17.0.123349198402.issue1034@psf.upfronthosting.co.za>
Message-ID: <1262874587.05.0.541310800334.issue1034@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type:  -> feature request

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

From report at bugs.python.org  Thu Jan  7 15:40:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 14:40:46 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262875246.26.0.181575863426.issue7092@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

>Antoine> (2to3 should be able to do the module rename -- Benjamin, does it?).
2to3 will rename cPickle to pickle.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Thu Jan  7 16:11:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Jan 2010 15:11:17 +0000
Subject: [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262877077.51.0.459789286814.issue7636@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm not sure how much value this adds, given that you can just call set() on the list resulting from "append" actions.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Jan  7 16:17:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 15:17:12 +0000
Subject: [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262877432.87.0.614396979998.issue7636@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think it's overkill, especially given the easy alternatives.

----------

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

From report at bugs.python.org  Thu Jan  7 16:58:21 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Thu, 07 Jan 2010 15:58:21 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262879901.94.0.90343322224.issue7652@psf.upfronthosting.co.za>


Changes by Juan Jos? Conti <jjconti at gmail.com>:


----------
nosy: +jjconti

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

From report at bugs.python.org  Thu Jan  7 18:27:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 17:27:30 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1262885250.88.0.210323480269.issue7455@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15605/issue7455_silence_py3k_warning.diff

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

From report at bugs.python.org  Thu Jan  7 18:35:28 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 07 Jan 2010 17:35:28 +0000
Subject: [issue1379416] email.Header encode() unicode P2.6
Message-ID: <1262885728.72.0.740874437019.issue1379416@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Any hope of this being fixed?

----------
nosy: +exarkun

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

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


Austin English <austinenglish+python at gmail.com> added the comment:

More info from the wine bug:
Whoops, I didn't notice that Python uses UuidCreateSequential.  From MSDN:

  For security reasons, UuidCreate was modified so that it no longer uses a machine's MAC address to generate UUIDs. UuidCreateSequential was
introduced to allow creation of UUIDs using the MAC address of a machine's Ethernet card.

I'm reopening this, as Wine's implementation of UuidCreateSequential calls UuidCreate, whereas it should use the MAC address-based method.  Setting component to rpcrt4, too.

My comment about the multicast bit occasionally being set (when the machine on which UuidCreateSequential is called has no MAC address) still stands, so there's still a Python bug.

----------

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

From report at bugs.python.org  Thu Jan  7 18:42:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 17:42:11 +0000
Subject: [issue1379416] email.Header encode() unicode P2.6
Message-ID: <1262886131.5.0.103334019846.issue1379416@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 2.7

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

From report at bugs.python.org  Thu Jan  7 18:43:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 17:43:54 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262886234.46.0.662117877478.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15773/issue7092_cpickle.diff

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

From report at bugs.python.org  Thu Jan  7 18:44:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 17:44:04 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262886244.2.0.819585373569.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15740/issue7092_lib_many_fixes_v3.diff

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

From report at bugs.python.org  Thu Jan  7 18:44:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 17:44:10 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262886250.55.0.587694509551.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15628/issue7092_compiler.diff

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

From report at bugs.python.org  Thu Jan  7 18:54:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Jan 2010 17:54:01 +0000
Subject: [issue7636] Add a set update action to optparse
In-Reply-To: <1262657940.5.0.389141298958.issue7636@psf.upfronthosting.co.za>
Message-ID: <1262886841.31.0.523338101601.issue7636@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> low
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jan  7 19:05:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Jan 2010 18:05:02 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1262887502.86.0.770124803754.issue7455@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in all four branches. Thank you Victor and Florent!

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jan  7 19:23:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 18:23:34 +0000
Subject: [issue7650] test_uuid is invalid
In-Reply-To: <1262828995.4.0.365764114727.issue7650@psf.upfronthosting.co.za>
Message-ID: <1262888614.79.0.633279755346.issue7650@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jan  7 20:27:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Jan 2010 19:27:48 +0000
Subject: [issue4766] email documentation needs to be precise about
	strings/bytes
In-Reply-To: <1230564109.29.0.851125901537.issue4766@psf.upfronthosting.co.za>
Message-ID: <1262892468.8.0.13386368842.issue4766@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We've concluded that the email package does need to be able to read bytes.  To do this and still support reading text, we're going to have to change the API.  So the docs will get fixed when they get rewritten for the new API.

Patches to the 3.1 docs to clarify the current situation would probably be accepted and applied, but I suspect the email team is not going to provide them due to lack of time :(.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> postponed
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Thu Jan  7 20:30:40 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 19:30:40 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262892640.75.0.383684829846.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

> Does the last patch obsolete the first two?  If so please delete the 
> obsolete ones.

Yes and no -- it depends on what the core Python developers want and are comfortable with:
  * unicode_escape_single_quotes.patch:  Only escapes single quotes, simple patch.
  * unicode_escape_single_and_double_quotes:  Superset of the above (also escapes double quotes), but probably unnecessary.  Still a relatively simple patch.
  * unicode_escape_reorg.patch:  Superset of unicode_escape_single_quotes.patch that also fixes raw_unicode_escape and other small issues.  It's a bigger patch with a greater potential for backwards-compatibility issues.  (Pickle is an example:  It implemented its own workaround to address raw_unicode_escape's broken escaping, so fixing raw_unicode_escape ended up breaking pickle.  The reorg patch removes pickle's workaround, but there will probably be similar workarounds in other existing code.)

My preference is to have unicode_escape_reorg.patch committed, but I'm not sure how conservative the core developers are.  The release of Python 2.7 is approaching, and they may not want to take on the risk right now.  If that's the case, I'd be happy with applying unicode_escape_single_quotes.patch for now and moving unicode_escape_reorg.patch to a new issue report.

> I imagine there are might be small doc updates required, as well.

Certainly Misc/NEWS will need to be patched.  I'm unfamiliar with what else the devs might want for documentation, so I'd love to get some additional guidance.  I would also appreciate additional feedback on the technical merits of the reorg patch before investing too much time on updating documentation.

> I haven't looked at the patch itself, but concerning your test 
> patch:  your try/except style is unnecessary, I think.  Better to 
> just let the syntax error bubble up on its own.

OK, I'll make that change.  I added the try/except as an attempt to convert a known ERROR to a FAIL in case that was important for some reason.

Thanks for the feedback!

----------

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

From report at bugs.python.org  Thu Jan  7 20:34:33 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 19:34:33 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262892873.75.0.593627027214.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15746/unicode_escape_tests.patch

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

From report at bugs.python.org  Thu Jan  7 20:39:20 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 19:39:20 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262893160.37.0.496445694185.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching updated unit tests for the unicode_escape codec.  I removed the raw_unicode_escape tests and will attach a separate patch for those.

----------
Added file: http://bugs.python.org/file15774/unicode_escape_tests.patch

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

From report at bugs.python.org  Thu Jan  7 20:40:05 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 19:40:05 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262893205.74.0.162537741959.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching updated unit tests for the raw_unicode_escape codec.

----------
Added file: http://bugs.python.org/file15775/raw_unicode_escape_tests.patch

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

From report at bugs.python.org  Thu Jan  7 20:49:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Jan 2010 19:49:20 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1262893760.06.0.608919746872.issue7651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should ask on the mailing-list (python-dev) because this is an important behaviour change which I'm not sure will get accepted.

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Jan  7 20:49:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 19:49:52 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1262893792.42.0.0671681576758.issue4388@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Thu Jan  7 20:54:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 19:54:58 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262894098.22.0.868817101894.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The Big Patch?.

It removes 99% of noisy deprecation messages.

----------
Added file: http://bugs.python.org/file15776/issue7092_Lib_tests_big_patch.diff

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

From report at bugs.python.org  Thu Jan  7 21:02:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Jan 2010 20:02:06 +0000
Subject: [issue5063] python-2.6.spec doesn't build properly
In-Reply-To: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>
Message-ID: <1262894526.89.0.170234920912.issue5063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I see that, eg, 'libver', which the patch wants to change to 'libvers', is still 'libver' in trunk/py3k.  I know nothing about RPM, so am adding Martin as nosy since svn indicates he was the author of most of the file.

----------
nosy: +loewis, r.david.murray

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

From report at bugs.python.org  Thu Jan  7 21:15:21 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 07 Jan 2010 20:15:21 +0000
Subject: [issue5063] python-2.6.spec doesn't build properly
In-Reply-To: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>
Message-ID: <1262895321.01.0.0647729356254.issue5063@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I just created the first version of the spec file after migration to subversion, by copying from an older version, which then got copied across versions.

The original RPM support was from Jeremy Hylton (r18101); the spec file in its current form was contributed by Sean Reifschneider (r25016, r31581, r34435 - taken from issue823259).

Assigning the issue to jafo - Sean, if you don't want it, unassign it.

----------
assignee:  -> jafo
nosy: +jafo

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

From report at bugs.python.org  Thu Jan  7 21:19:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 20:19:29 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1262895569.71.0.0644200868896.issue2777@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15313/issue2777.patch

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

From report at bugs.python.org  Thu Jan  7 21:22:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 20:22:27 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1262895747.99.0.304506041082.issue2777@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Minor patch change

----------
keywords: +needs review
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file15777/issue2777.patch

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

From report at bugs.python.org  Thu Jan  7 21:40:31 2010
From: report at bugs.python.org (Paul Keating)
Date: Thu, 07 Jan 2010 20:40:31 +0000
Subject: [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 21:54:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Jan 2010 20:54:15 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262897655.8.0.628629654735.issue7652@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To answer Eric's question:  Decimal.__format__ is already implemented in Stefan's work---it looks like most of the code is in

http://svn.python.org/projects/python/branches/py3k-cdecimal/Modules/cdecimal/io.c

(Stefan, is this right?)

----------

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

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


Mark Dickinson <dickinsm at gmail.com> added the comment:

So the new branch looks great---thanks, Stefan!  I'm only just beginning to look at the code properly, though.

A couple of things:

(1) Could we unify test_decimal and test_cdecimal somehow?  This would avoid them getting out of sync when new tests are added, and would make it clear what the differences between them are.  It looks like there's currently a lot of duplicate code.

(2) At some point we'll need some documentation.  Even if all it says is:  the cdecimal module operates identically to the decimal module, with the following exceptions... (notes on threading differences, exponent limits, correct rounding of pow, etc.)

----------

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

From report at bugs.python.org  Thu Jan  7 22:23:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 21:23:30 +0000
Subject: [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: <1262899410.45.0.894453820225.issue7653@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It seems a bit wordy. I propose an alternate wording in the attached patch.

----------
keywords: +needs review, patch
nosy: +brian.curtin
priority:  -> low
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15778/issue7653.diff

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

From report at bugs.python.org  Thu Jan  7 22:23:46 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 07 Jan 2010 21:23:46 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262892640.75.0.383684829846.issue7615@psf.upfronthosting.co.za>
Message-ID: <4B4650DD.5080007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Richard Hansen wrote:
> 
> Richard Hansen <rhansen at bbn.com> added the comment:
> 
>> Does the last patch obsolete the first two?  If so please delete the 
>> obsolete ones.
> 
> Yes and no -- it depends on what the core Python developers want and are comfortable with:
>   * unicode_escape_single_quotes.patch:  Only escapes single quotes, simple patch.
>   * unicode_escape_single_and_double_quotes:  Superset of the above (also escapes double quotes), but probably unnecessary.  Still a relatively simple patch.
>   * unicode_escape_reorg.patch:  Superset of unicode_escape_single_quotes.patch that also fixes raw_unicode_escape and other small issues.  It's a bigger patch with a greater potential for backwards-compatibility issues.  (Pickle is an example:  It implemented its own workaround to address raw_unicode_escape's broken escaping, so fixing raw_unicode_escape ended up breaking pickle.  The reorg patch removes pickle's workaround, but there will probably be similar workarounds in other existing code.)
> 
> My preference is to have unicode_escape_reorg.patch committed, but I'm not sure how conservative the core developers are.  The release of Python 2.7 is approaching, and they may not want to take on the risk right now.  If that's the case, I'd be happy with applying unicode_escape_single_quotes.patch for now and moving unicode_escape_reorg.patch to a new issue report.

We'll need a patch that implements single and double quote escaping for
unicode_escape and a \uXXXX style escaping of quotes for the raw_unicode_escape
encoder.

Other changes are not necessary. The pickle copy of the codec can be
left untouched (both cPickle.c and pickle.py) - it doesn't matter
whether quotes are escaped or not in the pickle data stream.

It's only important that the decoders can reliably decode the
additional escapes (which AFAIK, they do automatically anyway).

>> I imagine there are might be small doc updates required, as well.
> 
> Certainly Misc/NEWS will need to be patched.  I'm unfamiliar with what else the devs might want for documentation, so I'd love to get some additional guidance.  I would also appreciate additional feedback on the technical merits of the reorg patch before investing too much time on updating documentation.

Misc/NEWS needs an entry which makes the changes clear.

The codecs' encode direction is not defined anywhere in the
documentation, AFAIK, and basically an implementation detail.
The codecs were originally only meant for Python's internal
use to decode Python literal byte strings into Unicode.
In PEP 100, I only defined the decoding direction. The
main idea was to have a set of codecs which read and produce
Latin-1 compatible text - Python 2.x used to accept Latin-1
Unicode literals without source code encoding marker.

>> I haven't looked at the patch itself, but concerning your test 
>> patch:  your try/except style is unnecessary, I think.  Better to 
>> just let the syntax error bubble up on its own.
> 
> OK, I'll make that change.  I added the try/except as an attempt to convert a known ERROR to a FAIL in case that was important for some reason.

I'll have to have a look at the patch itself as well. No time for
that now, perhaps tomorrow.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

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

From report at bugs.python.org  Thu Jan  7 22:30:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Jan 2010 21:30:59 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1262899859.26.0.538120536794.issue7532@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I would suggest to keep the tests, even if the bug is closed.

----------
Added file: http://bugs.python.org/file15779/issue7532_wontfix_tests.diff

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

From report at bugs.python.org  Thu Jan  7 22:35:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Jan 2010 21:35:46 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262900146.29.0.208433230969.issue7652@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

>mark> (1) Could we unify test_decimal and test_cdecimal somehow?
>mark> This would avoid them getting out of sync when new tests are
>mark> added, and would make it clear what the differences between 
>mark> them are.  It looks like there's currently a lot of duplicate code.

An approach similar to the one taken in test_warnings.py might work: write common test code as a base class, then subclass it to be run against both the C and Py versions of the module.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Thu Jan  7 22:36:22 2010
From: report at bugs.python.org (Demur Rumed)
Date: Thu, 07 Jan 2010 21:36:22 +0000
Subject: [issue1506122] Add "compose" function to the functools
Message-ID: <1262900182.96.0.097635819453.issue1506122@psf.upfronthosting.co.za>


Demur Rumed <junkmute at hotmail.com> added the comment:

A type safe compose could be useful. One which instead of returning a function that takes (*args,**kwargs), takes the same as the first function which the arguments would be passed to. Copying a functions argument semantics would be useful in general, such as for decorators

----------
nosy: +serprex

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

From report at bugs.python.org  Thu Jan  7 22:36:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Jan 2010 21:36:26 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1262900186.24.0.804135372235.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, sounds reasonable.  Reopening to consider tests.

----------
assignee:  -> mark.dickinson
status: closed -> open

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

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: [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 22:48:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Jan 2010 21:48:59 +0000
Subject: [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: <1262900939.0.0.24578130132.issue7653@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied your patch in r77360.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Jan  7 22:53:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 21:53:33 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1262901213.88.0.306745475614.issue7624@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Thu Jan  7 23:06:07 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 07 Jan 2010 22:06:07 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262901967.7.0.384286136327.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, formatting is completely implemented in io.c, together with quite a comprehensive test suite. I like the new Python format strings, so I wanted them in the C library, too.

----------

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

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: [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  Thu Jan  7 23:33:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Jan 2010 22:33:19 +0000
Subject: [issue7655] PEP 374 Title usage & script redirection typo fixes
In-Reply-To: <1262903371.51.0.129729572973.issue7655@psf.upfronthosting.co.za>
Message-ID: <1262903599.08.0.412045453718.issue7655@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r77361.

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Thu Jan  7 23:42:58 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 22:42:58 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262904178.99.0.252194974459.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

> We'll need a patch that implements single and double quote escaping 
> for unicode_escape and a \uXXXX style escaping of quotes for the 
> raw_unicode_escape encoder.

OK, I'll remove unicode_escape_single_quotes.patch and update unicode_escape_reorg.patch.

> Other changes are not necessary.

Would you please clarify?  There are a few other (minor) bugs that were discovered while writing unicode_escape_reorg.patch that I think should be fixed:
  * the UTF-16 surrogate pair decoding logic could read past the end of the provided Py_UNICODE character array if the last character is between 0xD800 and 0xDC00
  * _PyString_Resize() will be called on an empty string if the size argument of unicodeescape_string() is 0.  This will raise a SystemError because _PyString_Resize() can only be called if the object's ref count is 1 (even if no resizing is to take place) yet PyString_FromStringAndSize() returns a shared empty string instance if size is 0.
  * it is unclear what unicodeescape_string() should do if size < 0

Beyond those issues, I'm worried about manageability stemming from the amount of code duplication.  If a bug is found in one of those encoding functions, the other two will likely need updating.

> The pickle copy of the codec can be left untouched (both cPickle.c 
> and pickle.py) - it doesn't matter whether quotes are escaped or not 
> in the pickle data stream.

Unfortunately, pickle.py must be modified because it does its own backslash escaping before encoding with the raw_unicode_escape codec.  This means that backslashes would become double escaped and the decoded value would differ (confirmed by running the pickle unit tests).

The (minor) bugs in PyUnicode_EncodeRawUnicodeEscape() are also present in cPickle.c, so they should probably be fixed as well.

> The codecs' encode direction is not defined anywhere in the 
> documentation, AFAIK, and basically an implementation detail.

I read the escape codec documentation (see the original post) as implying that the encoders can generate eval-able string literals.  I'll add some clarifying statements.

Thanks for the feedback!

----------

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

From report at bugs.python.org  Thu Jan  7 23:43:15 2010
From: report at bugs.python.org (Richard Hansen)
Date: Thu, 07 Jan 2010 22:43:15 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1262904195.67.0.495754926595.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed 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  8 00:18:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jan 2010 23:18:51 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1262906330.66.0.125497764461.issue7651@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

open_bom.patch is the proof of concept. It only works in read mode. The idea is to delay the creation of the encoding and the decoder. We wait for just after the first read_chunk().

The patch changes the default behaviour of open(): if the file starts with a BOM, the BOM is used but skipped. Example:
-------------
from _pyio import open

with open('test.txt', 'w', encoding='utf-8-sig') as fp:
    print("abc", file=fp)
    print("d\xe9f", file=fp)

with open('test.txt', 'r') as fp:
    print("open().read(): {!r}".format(fp.read()))
-------------

Unpatched Python displays '\ufeffabc\nd?f\n', whereas patched Python displays 'abc\nd?f\n'.

----------
keywords: +patch
Added file: http://bugs.python.org/file15782/open_bom.patch

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

From report at bugs.python.org  Fri Jan  8 00:28:45 2010
From: report at bugs.python.org (Jacob Godserv)
Date: Thu, 07 Jan 2010 23:28:45 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1262906925.62.0.402848998621.issue1006238@psf.upfronthosting.co.za>


Jacob Godserv <jacobgodserv at gmail.com> added the comment:

This bug affects me as well. Adding myself to CC.

----------
nosy: +javaJake

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

From report at bugs.python.org  Fri Jan  8 00:32:32 2010
From: report at bugs.python.org (Jacob Godserv)
Date: Thu, 07 Jan 2010 23:32:32 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1262907152.45.0.628899434906.issue1006238@psf.upfronthosting.co.za>


Jacob Godserv <jacobgodserv at gmail.com> added the comment:

The stage of this bug could be changed to "patch review", since a patch is available.

----------

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

From report at bugs.python.org  Fri Jan  8 00:36:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 23:36:10 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1262907370.95.0.705895656533.issue1006238@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
stage: test needed -> patch review

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

From report at bugs.python.org  Fri Jan  8 00:41:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jan 2010 23:41:20 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1262907680.92.0.730386337793.issue7651@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, fix read() method of my previous patch.

----------
Added file: http://bugs.python.org/file15783/open_bom-2.patch

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

From report at bugs.python.org  Fri Jan  8 00:46:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 23:46:57 +0000
Subject: [issue7654] [patch] Enable additional bytes and memoryview tests.
In-Reply-To: <1262900856.17.0.385951173483.issue7654@psf.upfronthosting.co.za>
Message-ID: <1262908017.3.0.0913371636549.issue7654@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Fri Jan  8 00:52:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Jan 2010 23:52:48 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1262908368.48.0.971824658729.issue5827@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Fri Jan  8 01:08:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Jan 2010 00:08:15 +0000
Subject: [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1262909295.82.0.200525881414.issue7635@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The xml.dom.pulldom module doesn't have docstrings so I guess that when the doc page has been created only the names of the classes/method have been listed.

----------
nosy: +ezio.melotti, loewis
priority:  -> normal
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jan  8 01:44:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Jan 2010 00:44:58 +0000
Subject: [issue5127] Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1262911498.02.0.573401569034.issue5127@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
title: UnicodeEncodeError - I can't even see license -> Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
versions: +Python 3.1, Python 3.2 -Python 3.0

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

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: [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 02:49:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jan 2010 01:49:06 +0000
Subject: [issue5277] email message.get_params() and related methods sometimes
	fail.
In-Reply-To: <1234758915.75.0.150242965655.issue5277@psf.upfronthosting.co.za>
Message-ID: <1262915346.62.0.861981771745.issue5277@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +easy
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Fri Jan  8 03:11:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Jan 2010 02:11:36 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1262916696.73.0.798717700445.issue7105@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

LGTM

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Jan  8 03:51:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jan 2010 02:51:04 +0000
Subject: [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: <1262919064.16.0.788976779691.issue7653@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If, as the OP indicates, the value of the key itself is ignored, this should be mentioned in the doc, especially if it normally has an apparently valid value.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Jan  8 05:25:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 08 Jan 2010 04:25:54 +0000
Subject: [issue2539] Windows Registry issue with 2.5.2 AMD64 msi
In-Reply-To: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>
Message-ID: <1262924754.36.0.91493417891.issue2539@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It seems like this may have been the result of registry redirection. Jason didn't say if the 2.5.1 install he went back to was 64-bit or not, but that could have been the difference. Given how old this is, I doubt he remembers :)

wxPython has 32 and 64 bit versions, so if you have a 64-bit Python and try to install the 32-bit wx, the wx installer won't immediately find a registry entry. It will be redirected to HKLM\Software\Wow6432Node\Python, which won't exist.

I think we can close this. Any thoughts, Martin?

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Fri Jan  8 08:02:34 2010
From: report at bugs.python.org (sangamesh)
Date: Fri, 08 Jan 2010 07:02:34 +0000
Subject: [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 09:54:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 08 Jan 2010 08:54:12 +0000
Subject: [issue2539] Windows Registry issue with 2.5.2 AMD64 msi
In-Reply-To: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>
Message-ID: <1262940852.94.0.0653399994912.issue2539@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Whatever the problem, it seems to have gone away. Closing as out-of-date.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Jan  8 10:06:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Jan 2010 09:06:07 +0000
Subject: [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 10:06:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 09:06:10 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262941570.76.0.342941159427.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15776/issue7092_Lib_tests_big_patch.diff

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

From report at bugs.python.org  Fri Jan  8 10:08:35 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Jan 2010 09:08:35 +0000
Subject: [issue6834] use different mechanism for pythonw on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1262941715.7.0.0483986643684.issue6834@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note, r77031 and r77032 cause compile errors for OS X deployment targets of 10.4 or earlier.  See Issue7658 for details and patch.

----------

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

From report at bugs.python.org  Fri Jan  8 10:18:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 08 Jan 2010 09:18:14 +0000
Subject: [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: <1262942294.21.0.839949294442.issue7658@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would it be possible to make this a runtime choice? I.e. use posix_spawn when available, and exec otherwise?

----------
nosy: +loewis

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

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


Ned Deily <nad at acm.org> added the comment:

Not cleanly, I think.  The problem is there's no spawn.h in the 10.4u SDK so it can't be built on 10.4 without supplying a copy of a system header file.

----------
title: OS X pythonw.c compile error with 10.4 or earlier deployment target -> OS X pythonw.c compile error with 10.4 or earlier deployment target: no spawn.h

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

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


Ned Deily <nad at acm.org> added the comment:

Also, the new functionality is really only needed for 32-bit/64-bit multi-arch builds which aren't support with the 10.4u SDK anyway.

----------

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

From report at bugs.python.org  Fri Jan  8 10:31:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 08 Jan 2010 09:31:34 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1262943094.8.0.00778788079818.issue7658@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

To elaborate, it should be possible to declare the posix_spawnp functions as __attribute__((weak)), and then test at run-time whether the function (pointers) are null. See http://tinyurl.com/y8myawg for an example.

----------

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

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


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: the new functionality is also needed for 2-way univeral binaries, it makes pythonw behave much more as if you execute the real interpreter instead of a stub executable.

That posix_spawn doesn't exist sucks, and I'm a bit annoyed with myself for not noticing that before the commit. 

It is pretty easy to create executables on 10.5 that use posix_spawnv when available using weak linking (we already do that in posixmodule.c for other functionality).

That won't work for builds on 10.4, or linking to the 10.4u SDK, if the posix_spawn symbols aren't present there: weak linking still has to resolve the symbol at link-time and only ensures that the executable won't fail to start when the symbol isn't present at runtime.

I don't have the 10.4u SKD on my machine at the moment and cannot investigate further at the moment, but will do ASAP.

Another thing I'd like to do before 2.7 is released is to see if it is possible to perform the build using the default SDK and patch distutils to use the 10.4u SDK when building extensions for a universal build on a n OSX 10.4 system (because the default SDK on those systems cannot build  universal binaries).

----------

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

From report at bugs.python.org  Fri Jan  8 10:46:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Jan 2010 09:46:33 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1262943993.74.0.465805385389.issue7658@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. The patch is incorrect in it current form:

* The change to LIPO_32BIT_FLAGS is unconditional, the current values are needed to build on modern system, I guess the proposed new value would be needed for building on 10.4?

* The patch changes pythonw to use execv unconditionally when building a binary that should work on 10.4, as noted in the discussion it is easy enough to build an executable that uses posix_spawnv when it is available and falls back to execv when it is not.  A configure check can be used to detect if posix_spawnv is available at link-time.

----------

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

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


Ned Deily <nad at acm.org> added the comment:

As far as I can see, the only possible shortcoming of the patch is that it restores the current behavior with a 2-way fat ppc/i386 build with 10.4u (i.e. the way python.org installers are currently built); that is, you would still not be able to use "arch" to select PPC-emulation on an Intel machine when a 10.4 SDK build is installed on a 10.5 or later Intel system.  That's no different than what we have today and I don't know of any demand for that feature.  There are other fairly easy ways around it, if really necessary.  But perhaps I'm overlooking something. On the other hand, I don't see anything wrong with going the weak linking route (thanks for the pointer, Martin), either, other than the additional effort and complexity.

----------

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

From report at bugs.python.org  Fri Jan  8 11:23:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Jan 2010 10:23:48 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1262946228.21.0.698183448117.issue7651@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch which is shorter, cleaner, fix the last bug (seek) and don't change the default behaviour anymore (checking for BOM is now explicit):
 * BOM checking is now optional (explicit): use open(filename, encoding="BOM"). open(filename, "w", encoding="BOM") raises a ValueError.
 * Create a BOMS dictionary directly in the codecs module
 * Fix TextIOWrapper for seek(0) (add _has_bom attribute)
 * Add an unit test for read() and readlines()
 * Read the encoding property before the first read gives None

I also removed the _get_encoding() method (hack).

----------
Added file: http://bugs.python.org/file15786/open_bom-3.patch

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

From report at bugs.python.org  Fri Jan  8 11:32:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 10:32:07 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1262946727.6.0.739397040405.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Some technical background.

== Unicode ==

According to the Unicode Standard Annex #9, a character with
bidirectional class B is a "Paragraph Separator". And ?Because a
Paragraph Separator breaks lines, there will be at most one per line,
at the end of that line.?

As a consequence, there's 3 reasons to identify a character as a
linebreak:
 - General Category Zl "Line Separator"
 - General Category Zp "Paragraph Separator"
 - Bidirectional Class B "Paragraph Separator"

There's 8 linebreaks in the current Unicode Database (5.2):
------------------------------------------------------------------------
000A    LF  LINE FEED                   Cc  B
000D    CR  CARRIAGE RETURN             Cc  B
001C    FS  INFORMATION SEPARATOR FOUR  Cc  B (UCD 3.1 FILE SEPARATOR)
001D    GS  INFORMATION SEPARATOR THREE Cc  B (UCD 3.1 GROUP SEPARATOR)
001E    RS  INFORMATION SEPARATOR TWO   Cc  B (UCD 3.1 RECORD SEPARATOR)
0085    NEL NEXT LINE                   Cc  B (C1 Control Code)
2028    LS  LINE SEPARATOR              Zl  WS  (Unicode)
2029    PS  PARAGRAPH SEPARATOR         Zp  B   (Unicode)
------------------------------------------------------------------------


== ASCII ==

The Standard ASCII control codes (C0) are in the range 00-1F.
It limits the list to LF, CR, FS, GS, RS.
Regarding the last three, they are not considered as linebreaks:
?The separators (File, Group, Record, and Unit: FS, GS, RS and US) were made to
structure data, usually on a tape, in order to simulate punched cards. End of
medium (EM) warns that the tape (or whatever) is ending. While many systems use
CR/LF and TAB for structuring data, it is possible to encounter the separator
control characters in data that needs to be structured. The separator control
characters are not overloaded; there is no general use of them except to
separate data into structured groupings. Their numeric values are contiguous
with the space character, which can be considered a member of the group, as a
word separator.?
(Ref: http://en.wikipedia.org/wiki/Control_character#Data_structuring)

In conclusion, it may be better to keep things unchanged.
We may add some words to the documentation for str.splitlines() and bytes.splitlines() to explain what is considered a line break character.

References:
 - The Unicode Character Database (UCD): http://www.unicode.org/ucd/
 - UCD Property Values: http://unicode.org/reports/tr44/#Property_Values
 - The Bidirectional Algorithm: http://www.unicode.org/reports/tr9/
 - C0 and C1 Control Codes:
     http://en.wikipedia.org/wiki/C0_and_C1_control_codes

----------

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

From report at bugs.python.org  Fri Jan  8 11:33:54 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 08 Jan 2010 10:33:54 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1262946834.43.0.544703281984.issue7643@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Documenting the characters that splitlines treats as newlines for Unicode should definitely be done.

----------

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

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


Ned Deily <nad at acm.org> added the comment:

"* The change to LIPO_32BIT_FLAGS is unconditional, the current values
    are needed to build on modern system, I guess the proposed new
    value would be needed for building on 10.4?"

Ah, yes, sorry. I built and tested with and on 10.6 with 10.5 SDK/gcc-4.0, on 10.5 with gcc-4.0, and on 10.4u/gcc-4.0 but I see I did overlook trying 3-way on 10.6 with 10.6 SDK/gcc-4.2, where ppc7400 is indeed needed. Arch ppc is definitely needed for building on 10.6 and 10.5 with the 10.4u SDK and gcc-4.0:

  lipo: -extract ppc7400 specified but fat file: pythonw does not contain that architecture

If you don't get to it first, I'll fix and resubmit the patch later.

----------

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

From report at bugs.python.org  Fri Jan  8 12:42:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 11:42:42 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1262950962.97.0.235825438798.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It's confusing.

There's a specific annex UAX #14 which defines "Line Breaking Properties".
Some properties are defines as "Mandatory Line Breaks (non-tailorable)":
  BK, CR, LF, NL

And the resulting list is different:
                                       CAT BIDI BRK
------------------------------------------------------------------------000A    LF  LINE FEED                   Cc  B   LF
000B    VT  LINE TABULATION             Cc  S   BK (since Unicode 5.0) 
000C    FF  FORM FEED                   Cc  WS  BK
000D    CR  CARRIAGE RETURN             Cc  B   CR
0085    NEL NEXT LINE                   Cc  B   NL (C1 Control Code)
2028    LS  LINE SEPARATOR              Zl  WS  BK
2029    PS  PARAGRAPH SEPARATOR         Zp  B   BK
------------------------------------------------------------------------

Differences:
 - VT and FF are mandatory breaks (even if ?implementations are not
   required to support the VT character?)
 - FS, GS, US are combined marks (CM): ?Prohibit a line break between
   the character and the preceding character?

According to this Annex, the current splitlines() implementation violates the Unicode standard.

References:
 - Unicode Standard Annex #14 - Line Breaking Algorithm
   http://www.unicode.org/reports/tr14/
 - UCD LineBreak.txt
   http://www.unicode.org/Public/5.2.0/ucd/LineBreak.txt

----------

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

From report at bugs.python.org  Fri Jan  8 12:46:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 08 Jan 2010 11:46:16 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262951176.32.0.603663164731.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Unify test_decimal and test_cdecimal:

Yes, quite possible. The diff is currently 400 lines, but it should be easy to get that down to below 100 without any loss of functionality.

I'll look into that when I'm done with the 64 bit ANSI path.


Documentation:

Anything is welcome, even a patch that just creates a stub so I don't have to figure out where to put it.

The differences are listed at the bottom of:

http://www.bytereef.org/cdecimal.html

----------

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

From report at bugs.python.org  Fri Jan  8 12:50:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 08 Jan 2010 11:50:00 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1262951400.42.0.951988652622.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just an update. Rev.77358 should compile and run stable on the buildbot platforms except Alpha and ia64. I'm working on a default ANSI path for
64-bit.

----------

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

From report at bugs.python.org  Fri Jan  8 15:47:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 08 Jan 2010 14:47:50 +0000
Subject: [issue7657] test_ctypes failure on AIX 5.3
In-Reply-To: <1262934153.84.0.332661974456.issue7657@psf.upfronthosting.co.za>
Message-ID: <1262962070.28.0.446962251758.issue7657@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> needs patch

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

From report at bugs.python.org  Fri Jan  8 15:49:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 08 Jan 2010 14:49:57 +0000
Subject: [issue2796] Build issues in DragonFly BSD
In-Reply-To: <1210316878.4.0.717885872695.issue2796@psf.upfronthosting.co.za>
Message-ID: <1262962197.18.0.433992567455.issue2796@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you confirm that this is still an issue on a version >= 2.6?

----------
nosy: +brian.curtin
versions: +Python 2.6 -Python 2.5

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

From report at bugs.python.org  Fri Jan  8 15:51:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 14:51:52 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262962312.54.0.852536926364.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15787/issue7092_syntax_imports.diff

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

From report at bugs.python.org  Fri Jan  8 15:52:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 14:52:39 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262962359.63.0.321719870746.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15788/issue7092_check_warnings.diff

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

From report at bugs.python.org  Fri Jan  8 15:53:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 14:53:01 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262962381.45.0.0722416217995.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15789/issue7092_filterwarnings.diff

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

From report at bugs.python.org  Fri Jan  8 15:53:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 14:53:44 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262962424.26.0.951333432858.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I split the Big Patch? into pieces.
It should be easier to review and merge.

 - issue7092_syntax_imports.diff
   --> Only syntax and import_module(m, deprecated=True)

 - issue7092_check_warnings.diff
   --> Use test.test_support.check_warnings()

 - issue7092_filterwarnings.diff
   --> Use warnings.filterwarnings()

 - issue7092_json_sqlite.diff
   --> Silence external libraries

 - issue7092_cpickle.diff
   --> Remove cPickle warning

And there's a last patch for "test_index" attached to issue7532.


Then you reach the Zen of Python.
  ?Do not speak ? unless it improves on silence.?

----------
Added file: http://bugs.python.org/file15790/issue7092_json_sqlite.diff

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

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


Changes by sangamesh <swamy.sangamesh at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15791/bitfield.patch

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

From report at bugs.python.org  Fri Jan  8 17:03:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 16:03:53 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262966633.87.0.436990800299.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

About issue7092_json_sqlite.diff: if json produces py3k warnings in normal use (does it?), the warnings should be suppressed in json itself, not in regrtest.py.

----------

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

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: [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 18:10:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Jan 2010 17:10:28 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262970628.81.0.0429711604817.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that seems to fix the problem;  I'll wait a while to see if I get a response from David Gay before applying this.

Also, if we've got to the stage of modifying the algorithmic part of the original dtoa.c, we should really make sure that we've got our own set of comprehensive tests.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15792/issue7632.patch

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

From report at bugs.python.org  Fri Jan  8 18:16:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:16:18 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262970978.64.0.455371381059.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15790/issue7092_json_sqlite.diff

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

From report at bugs.python.org  Fri Jan  8 18:16:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:16:37 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262970997.2.0.691007259.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15793/issue7092_regrtest_clean.diff

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

From report at bugs.python.org  Fri Jan  8 18:26:17 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 08 Jan 2010 17:26:17 +0000
Subject: [issue1658] "RuntimeError: dictionary changed size during iteration"
	in Tkinter
In-Reply-To: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>
Message-ID: <1262971577.08.0.5347101584.issue1658@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

I get this error while running Python 2.6.4 tests (on 64-bit Linux box)

test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/test_urllib.py", line 104, in setUp
    for k, v in os.environ.iteritems():
RuntimeError: dictionary changed size during iteration

Should open a new bug?

----------
nosy: +srid

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

From report at bugs.python.org  Fri Jan  8 18:29:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 08 Jan 2010 17:29:58 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1262971798.32.0.475004460592.issue7659@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The 3.x documentation[1] has this:
"object does not have a __dict__, so you can?t assign arbitrary attributes to an instance of the object class."
- 2.x doesn't have that same blurb -- it looks like it should.

AttributeError vs. TypeError seems to be the issue here.


FWIW, the way to achieve what you had in your example is something like this:
>>> a = type("my_type", (object,), {})
>>> a.abc = 3


[1] http://docs.python.org/3.1/library/functions.html#object

----------
nosy: +brian.curtin
stage:  -> needs patch
title: Problems with attribute assignment on object instances -> Attribute assignment on object() instances raises wrong exception
versions: +Python 2.7

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

From report at bugs.python.org  Fri Jan  8 18:48:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:48:55 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262972935.94.0.477674239554.issue7026@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The method does not work as expected.


See msg97419:
----------------------------------------------------------------------
Author: Sridhar Ratnakumar (srid)  	Date: 2010-01-08 18:26

I get this error while running Python 2.6.4 tests (on 64-bit Linux box)

test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/test_urllib.py", line 104, in setUp
    for k, v in os.environ.iteritems():
RuntimeError: dictionary changed size during iteration
----------------------------------------------------------------------

----------
nosy: +flox
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Fri Jan  8 18:50:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:50:43 +0000
Subject: [issue1658] "RuntimeError: dictionary changed size during iteration"
	in Tkinter
In-Reply-To: <1198069697.21.0.802905521155.issue1658@psf.upfronthosting.co.za>
Message-ID: <1262973043.14.0.920161408365.issue1658@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

> test_urllib
> test test_urllib failed -- Traceback (most recent call last):
>  File "/home/apy/rrun/tmp/autotest/apy/lib/python2.6/test/test_urllib.py", line 104, in setUp
>     for k, v in os.environ.iteritems():
> RuntimeError: dictionary changed size during iteration

I reopened issue7026 for this one.

----------
nosy: +flox

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

From report at bugs.python.org  Fri Jan  8 18:53:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:53:09 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262973189.26.0.0608009185023.issue7026@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Index: Lib/test/test_urllib.py
===================================================================
--- Lib/test/test_urllib.py     (revision 77361)
+++ Lib/test/test_urllib.py     (working copy)
@@ -101,7 +101,7 @@
         # Records changes to env vars
         self.env = test_support.EnvironmentVarGuard()
         # Delete all proxy related env vars
-        for k, v in os.environ.iteritems():
+        for k, v in os.environ.keys():
             if 'proxy' in k.lower():
                 self.env.unset(k)

----------

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

From report at bugs.python.org  Fri Jan  8 18:53:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:53:37 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262973217.45.0.0141274322282.issue7026@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------

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

From report at bugs.python.org  Fri Jan  8 18:56:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 17:56:27 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262973387.04.0.00526220969649.issue7026@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Index: Lib/test/test_urllib.py
===================================================================
--- Lib/test/test_urllib.py     (revision 77361)
+++ Lib/test/test_urllib.py     (working copy)
@@ -101,7 +101,7 @@
         # Records changes to env vars
         self.env = test_support.EnvironmentVarGuard()
         # Delete all proxy related env vars
-        for k, v in os.environ.iteritems():
+        for k in os.environ.keys():
             if 'proxy' in k.lower():
                 self.env.unset(k)

----------

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

From report at bugs.python.org  Fri Jan  8 18:57:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 17:57:04 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1262973424.63.0.637541253309.issue7105@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r77365 (py3k) and r77366 (3.1). Thank you.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Jan  8 19:26:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 08 Jan 2010 18:26:09 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262975169.6.0.299145532248.issue7026@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 77367

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Jan  8 19:37:44 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 08 Jan 2010 18:37:44 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1262975864.21.0.265925945516.issue7659@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, I suppose it's some kind of optimization ?

We get a proper error when we do :

>>> object.test=1

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    object.test=1
TypeError: can't set attributes of built-in/extension type 'object'
>>> 

So we'd need a similar error when trying to assign to object instances, too...
I fear I won't be able to help with finding a patch alas, it's a little too deep into the python core for me :p

----------

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

From report at bugs.python.org  Fri Jan  8 19:38:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 18:38:51 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1262975931.55.0.545862880472.issue7659@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think it's an optimization. The point is that object is mostly meant to be subclassed, not to be used as a glorified dict.

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Jan  8 19:40:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 08 Jan 2010 18:40:21 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262976021.77.0.255995006434.issue7026@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thanks. It should be propagated to 2.7.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Fri Jan  8 19:52:22 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 08 Jan 2010 18:52:22 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1262976742.78.0.346704929808.issue7659@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

OK, eligible to QOTW    :D

----------

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

From report at bugs.python.org  Fri Jan  8 19:57:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jan 2010 18:57:52 +0000
Subject: [issue7659] Attribute assignment on object() instances raises wrong
	exception
In-Reply-To: <1262968332.68.0.476240777656.issue7659@psf.upfronthosting.co.za>
Message-ID: <1262977072.72.0.764337636599.issue7659@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But an object to which you can assign attributes but which has no methods can be useful in a number of contexts.  It's not a glorified dict, because attribute-style access is different from dict-style access.  The main place I have used this (creating my own trivial object subclass) is for passing a duck-typed object in to a function that only needs to access certain attributes to get the correct quack.

Why prevent us from using an object instance for this if there's not a functional reason for it?  Python is supposed to be a Consulting Adults language, after all :).

That said, I suspect that giving object a dict would break various assumptions in the core code, and I have no problem with creating that trivial subclass.  It does have the advantage of providing a more meaningful name in error messages.

----------
nosy: +r.david.murray

_______________________________________
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: [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  Fri Jan  8 20:10:16 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 08 Jan 2010 19:10:16 +0000
Subject: [issue7026] test_urllib: unsetting missing 'env' variable
In-Reply-To: <1254358150.75.0.46389883722.issue7026@psf.upfronthosting.co.za>
Message-ID: <1262977816.48.0.890255209433.issue7026@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, I indeed, I quickly moved to patch it up in the trunk and did a svn submit -m "..." I had your big patch for tests in the trunk. I have reverted it for now and shall fix this one only.

----------

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

From report at bugs.python.org  Fri Jan  8 20:23:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:23:30 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262978610.73.0.941234112774.issue7092@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

issue7092_cpickle.diff was committed to trunk and 2.6.

----------

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

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


Mark Dickinson <dickinsm at gmail.com> added the comment:

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

This is deliberate, though perhaps surprising if you haven't seen it before.  There's a long history of nan comparisons behaving this way (that is, x == nan always returns False, x != nan always returns True, even if x is a nan);  the behaviour comes from the IEEE 754 specification for floating-point arithmetic.

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

This is also as expected:  the sign bit of a nan result (either as a result of conversion from string, or the result of an arithmetic operation) is probably best regarded as undefined.  The new string -> float conversion algorithms that are used in Python 3.1 (and in the upcoming 2.7) make sure that 'nan' and '-nan' are converted to nans with different signs, but again that's an implementation detail that shouldn't be relied upon.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Jan  8 20:30:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:30:14 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262979014.22.0.648057457862.issue7092@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15773/issue7092_cpickle.diff

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

From report at bugs.python.org  Fri Jan  8 20:40:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:40:27 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1262979627.11.0.0417350616477.issue7316@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against newest py3k.

----------
Added file: http://bugs.python.org/file15795/timedlock4.patch

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

From report at bugs.python.org  Fri Jan  8 20:40:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:40:40 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1262979640.2.0.750169261886.issue7316@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15321/timedlock.patch

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

From report at bugs.python.org  Fri Jan  8 20:40:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:40:43 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1262979643.62.0.617978738648.issue7316@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15352/timedlock2.patch

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

From report at bugs.python.org  Fri Jan  8 20:40:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:40:48 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1262979648.09.0.453574851405.issue7316@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15533/timedlock3.patch

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

From report at bugs.python.org  Fri Jan  8 20:41:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jan 2010 19:41:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1262979668.18.0.732081184133.issue7092@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15793/issue7092_regrtest_clean.diff

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

From report at bugs.python.org  Fri Jan  8 21:10:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 08 Jan 2010 20:10:15 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262945022.45.0.234871053624.issue7658@psf.upfronthosting.co.za>
Message-ID: <4B479123.1050305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> As far as I can see, the only possible shortcoming of the patch is
> that it restores the current behavior with a 2-way fat ppc/i386 build
> with 10.4u (i.e. the way python.org installers are currently built);
> that is, you would still not be able to use "arch" to select
> PPC-emulation on an Intel machine when a 10.4 SDK build is installed
> on a 10.5 or later Intel system.  That's no different than what we
> have today and I don't know of any demand for that feature.  There
> are other fairly easy ways around it, if really necessary.

For users, what matters are really the binaries provided by python.org
(and those provided by Apple). So if you restore the previous behavior,
that's basically "for good" - that you still have the compile option to
support arch won't matter for users.

Now, ISTM that users do indeed request the ability to chose between a
32-bit interpreter and a 64-bit interpreter at launch time. I know that
they do on Windows (just because you can), and I would be puzzled if
there weren't OSX users that wanted it one way or the other (depending
on the application you intend to run).

----------

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

From report at bugs.python.org  Fri Jan  8 21:18:16 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 08 Jan 2010 20:18:16 +0000
Subject: [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: <1262981896.32.0.916818891101.issue7617@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> normal
resolution:  -> accepted

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

From report at bugs.python.org  Fri Jan  8 21:18:23 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Jan 2010 20:18:23 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262946727.6.0.739397040405.issue7643@psf.upfronthosting.co.za>
Message-ID: <4B47930B.6010708@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <laxyf at yahoo.fr> added the comment:
> 
> Some technical background.
> 
> == Unicode ==
> 
> According to the Unicode Standard Annex #9, a character with
> bidirectional class B is a "Paragraph Separator". And ?Because a
> Paragraph Separator breaks lines, there will be at most one per line,
> at the end of that line.?
> 
> As a consequence, there's 3 reasons to identify a character as a
> linebreak:
>  - General Category Zl "Line Separator"
>  - General Category Zp "Paragraph Separator"
>  - Bidirectional Class B "Paragraph Separator"

This definition is what we use in Python for Py_UNICODE_ISLINEBREAK(ch).

> There's 8 linebreaks in the current Unicode Database (5.2):
> ------------------------------------------------------------------------
> 000A    LF  LINE FEED                   Cc  B
> 000D    CR  CARRIAGE RETURN             Cc  B
> 001C    FS  INFORMATION SEPARATOR FOUR  Cc  B (UCD 3.1 FILE SEPARATOR)
> 001D    GS  INFORMATION SEPARATOR THREE Cc  B (UCD 3.1 GROUP SEPARATOR)
> 001E    RS  INFORMATION SEPARATOR TWO   Cc  B (UCD 3.1 RECORD SEPARATOR)
> 0085    NEL NEXT LINE                   Cc  B (C1 Control Code)
> 2028    LS  LINE SEPARATOR              Zl  WS  (Unicode)
> 2029    PS  PARAGRAPH SEPARATOR         Zp  B   (Unicode)
> ------------------------------------------------------------------------

And that's the list we're currently using.

> == ASCII ==
> 
> The Standard ASCII control codes (C0) are in the range 00-1F.
> It limits the list to LF, CR, FS, GS, RS.
> Regarding the last three, they are not considered as linebreaks:
> ?The separators (File, Group, Record, and Unit: FS, GS, RS and US) were made to
> structure data, usually on a tape, in order to simulate punched cards. End of
> medium (EM) warns that the tape (or whatever) is ending. While many systems use
> CR/LF and TAB for structuring data, it is possible to encounter the separator
> control characters in data that needs to be structured. The separator control
> characters are not overloaded; there is no general use of them except to
> separate data into structured groupings. Their numeric values are contiguous
> with the space character, which can be considered a member of the group, as a
> word separator.?
> (Ref: http://en.wikipedia.org/wiki/Control_character#Data_structuring)
> 
> In conclusion, it may be better to keep things unchanged.

Agreed.

> We may add some words to the documentation for str.splitlines() and bytes.splitlines() to explain what is considered a line break character.

For ASCII we should make the list of characters explicit.
For Unicode, we should mention the above definition and give
the table as example list (the Unicode database may add more
such characters in the future).

> References:
>  - The Unicode Character Database (UCD): http://www.unicode.org/ucd/
>  - UCD Property Values: http://unicode.org/reports/tr44/#Property_Values
>  - The Bidirectional Algorithm: http://www.unicode.org/reports/tr9/
>  - C0 and C1 Control Codes:
>      http://en.wikipedia.org/wiki/C0_and_C1_control_codes

----------

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

From report at bugs.python.org  Fri Jan  8 21:44:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Jan 2010 20:44:12 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262983452.88.0.753329877158.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Randomised testing quickly turned up another troublesome string for str -> float conversion:

s = "94393431193180696942841837085033647913224148539854e-358"

This one's actually giving incorrectly rounded results (the horror!) in a non-debug build of trunk, and giving the same 'oversize b in quorem' in a debug build.  With the patch, it doesn't give the 'oversize b' error, but does still give incorrect results.

Python 2.7a1+ (trunk:77375, Jan  8 2010, 20:33:59) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "94393431193180696942841837085033647913224148539854e-358"
>>> float(s)   # result of dtoa.c
9.439343119318067e-309
>>> from __future__ import division
>>> int(s[:-5])/10**358  # result via (correctly rounded) division
9.43934311931807e-309

I also double checked this value using a simple pure Python implementation of strtod, and using MPFR (via the Python bigfloat module), with the same result:

>>> from test_dtoa import strtod
>>> strtod(s)  # result via a simple pure Python implementation of strtod
9.43934311931807e-309
>>> from bigfloat import *
>>> with double_precision: x = float(BigFloat(s))
>>> x   # result from MPFR, via the bigfloat module
9.43934311931807e-309

----------
stage: patch review -> needs patch

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

From report at bugs.python.org  Fri Jan  8 22:08:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Jan 2010 21:08:22 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262950962.97.0.235825438798.issue7643@psf.upfronthosting.co.za>
Message-ID: <4B479EC1.8020009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <laxyf at yahoo.fr> added the comment:
> 
> It's confusing.
> 
> There's a specific annex UAX #14 which defines "Line Breaking Properties".
> Some properties are defines as "Mandatory Line Breaks (non-tailorable)":
>   BK, CR, LF, NL

Note that a line breaking algorithm is something different than
a line split algorithm. The latter is used to separate lines at
pre-defined positions in the text, the former is used to format
a piece of text to fit e.g. into a certain width of available
character positions.

.splitlines() implements a line splitting algorithm, not a line
breaking one.

> And the resulting list is different:
>                                        CAT BIDI BRK
> ------------------------------------------------------------------------
> 000A    LF  LINE FEED                   Cc  B   LF
> 000B    VT  LINE TABULATION             Cc  S   BK (since Unicode 5.0) 
> 000C    FF  FORM FEED                   Cc  WS  BK
> 000D    CR  CARRIAGE RETURN             Cc  B   CR
> 0085    NEL NEXT LINE                   Cc  B   NL (C1 Control Code)
> 2028    LS  LINE SEPARATOR              Zl  WS  BK
> 2029    PS  PARAGRAPH SEPARATOR         Zp  B   BK
> ------------------------------------------------------------------------
>
> Differences:
>  - VT and FF are mandatory breaks (even if ?implementations are not
>    required to support the VT character?)
>  - FS, GS, US are combined marks (CM): ?Prohibit a line break between
>    the character and the preceding character?
> 
> According to this Annex, the current splitlines() implementation violates the Unicode standard.

It appears so and I guess that's an oversight on my part when
writing the code: in Unicode 2.1 (the version I started with),
FF was marked as "B", later on Unicode 3.0 was published and
the new LineBreak.txt file was added to the standard. FF was
changed to "WS" and instead marked as "BK" in that new LineBreak.txt
file.

Since we only used the main UnicodeData.txt file as basis for
the type database, the "FF" code point dropped out of the
line break code point set.

I guess we'll have to add FF and VT to the generator makeunicodedata.py
to remedy this.

> References:
>  - Unicode Standard Annex #14 - Line Breaking Algorithm
>    http://www.unicode.org/reports/tr14/
>  - UCD LineBreak.txt
>    http://www.unicode.org/Public/5.2.0/ucd/LineBreak.txt

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

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

From report at bugs.python.org  Fri Jan  8 22:26:55 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Jan 2010 21:26:55 +0000
Subject: [issue5127] Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1262986015.58.0.297444713155.issue5127@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I don't see the point in changing the various conversion APIs in the unicode database to return Py_UCS4 when there are no conversions that map code points between BMP and non-BMP.

In order to solve the problem in question (unicode_repr() failing), we should change the various property checking APIs to accept Py_UCS4 input data. This needlessly increases the type database size without real benefit.

For that to work properly we'll have to either make sure that extensions get recompiled if they use these changed APIs, or we provide an additional set of UCS2 APIs that extend the Py_UNICODE input value to a Py_UCS4 value before calling the underlying Py_UCS4 API.

----------

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

From report at bugs.python.org  Fri Jan  8 22:32:28 2010
From: report at bugs.python.org (Alan Justino)
Date: Fri, 08 Jan 2010 21:32:28 +0000
Subject: [issue706263] print raises exception when no console available
Message-ID: <1262986348.72.0.166328817382.issue706263@psf.upfronthosting.co.za>


Alan Justino <alan.justino at yahoo.com.br> added the comment:

FWIW: I don't know if it changes anything, but when deploying Django projects on some clients who uses Windows as server, I'm using this piece of code to workarround this issue:

## Fixes "IOError: [Errno 9] Bad file descriptor" when in pythonw.exe of Windows

if sys.platform.find('win') != -1 and sys.executable.find('pythonw') != -1:

    blackhole = file(os.devnull, 'w')

    sys.stdout = sys.stderr = blackhole

##

Is not my intention to remove print statments neither to send they to a file. For this I'm using logging module.

I really expect they to be silently ignored, bothering not my user.

----------
nosy: +alanjds
versions: +Python 2.6

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

From report at bugs.python.org  Fri Jan  8 23:18:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Jan 2010 22:18:33 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1262989113.44.0.897688875119.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, I think I've found the cause of the second rounding bug above: at the end of the bigcomp function there's a correction block that looks like

    ...
    else if (dd < 0) {
        if (!dsign)     /* does not happen for round-near */
          retlow1:
            dval(rv) -= ulp(rv);
    }
    else if (dd > 0) {
        if (dsign) {
          rethi1:
            dval(rv) += ulp(rv);
        }
    }
    else ...

The problem is that the += and -= corrections don't take into account the possibility that bc->scale is nonzero, and for the case where the scaled rv is subnormal, they'll typically have no effect.

I'll work on a fix...  tomorrow.

----------

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

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: [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 00:28:19 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 08 Jan 2010 23:28:19 +0000
Subject: [issue7071] distutils and IronPython compatibility
In-Reply-To: <1254827503.56.0.590175679082.issue7071@psf.upfronthosting.co.za>
Message-ID: <1262993299.87.0.833568697594.issue7071@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

merged in 2.6 in r77376

----------

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

From report at bugs.python.org  Sat Jan  9 00:43:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Jan 2010 23:43:21 +0000
Subject: [issue5640] Wrong print() result when unicode error handler is not
	'strict'
In-Reply-To: <1238571303.14.0.143713902199.issue5640@psf.upfronthosting.co.za>
Message-ID: <1262994201.67.0.0732030979618.issue5640@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Sat Jan  9 01:04:05 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 09 Jan 2010 00:04:05 +0000
Subject: [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: <1262995445.4.0.715240241604.issue7617@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r77377, r77378, r77380, r77381

Thanks!

----------
status: open -> closed

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

From report at bugs.python.org  Sat Jan  9 01:45:21 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 09 Jan 2010 00:45:21 +0000
Subject: [issue5127] Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1262997921.1.0.403720271527.issue5127@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I don't see the point in changing the various conversion APIs in the
> unicode database to return Py_UCS4 when there are no conversions that
> map code points between BMP and non-BMP.

For consistency: if Py_UNICODE_ISPRINTABLE is changed to take Py_UCS4, Py_UNICODE_TOLOWER should also take Py_UCS4, and must return the same type.

> In order to solve the problem in question (unicode_repr() failing), 
> we should change the various property checking APIs to accept Py_UCS4
> input data. This needlessly increases the type database size without
> real benefit.
[I'm not sure to understand. For me the 'real benefit' is that it solves the problem in question.]

Yes this increases the type database: there are 300 more "case" statements in _PyUnicode_ToNumeric(), and the PyUnicode_TypeRecords array needs 1068 more bytes.
On Windows, VS9.0 release build, unicodectype.obj grows from 86Kb to 94Kb; python32.dll is exactly 1.5Kb larger (from 2219Kb to 2221.5Kb);
the memory usage of the just-started interpreter is about 32K larger (around 5M).  These look reasonable figures to me.

> For that to work properly we'll have to either make sure that
> extensions get recompiled if they use these changed APIs, or we
> provide an additional set of UCS2 APIs that extend the Py_UNICODE
> input value to a Py_UCS4 value before calling the underlying Py_UCS4
> API.

Extensions that use these changed APIs need to be recompiled, or they won't load: existing modules link with symbols like _PyUnicodeUCS2_IsPrintable, when the future interpreter will define _PyUnicode_IsPrintable.

----------

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

From report at bugs.python.org  Sat Jan  9 02:02:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Jan 2010 01:02:57 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1262998976.97.0.0686474008011.issue7658@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Martin, just to be clear: the purpose of the new feature *is* to allow the choice between 32-bit/64-bit and that is important.  My comment was that the downside of the submitted fix, as it stands, would be to not allow choosing archs only for pythons built with the 10.4u SDKs.  And with the 10.4u SDK, those pythons are and can only be 32-bit so the only arch choice there would be between 32-bit Intel and 32-bit PPC and the only environment where that could mean anything is on a 10.5 or 10.6 Intel machine where, in theory, it should be possible to run 32-bit PPC pythons in emulation mode. For pythons built with 10.5 or 10.6 SDKs (in as yet to be supplied python.org installers), then the arch feature allows choice among the up-to 4 archs in the build: 32/64, Intel/PPC.  The proposed fix doesn't alter that aspect of the new feature at all.  But the patch needs to be redone anyway so, if the weak linking is added, there wouldn't even be that very small drawback.

OS X multi-architecture executables: complicated!

----------

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

From report at bugs.python.org  Sat Jan  9 04:24:00 2010
From: report at bugs.python.org (Joe Julian)
Date: Sat, 09 Jan 2010 03:24:00 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1263007440.62.0.280269092805.issue644744@psf.upfronthosting.co.za>


Changes by Joe Julian <joe at julianfamily.org>:


----------
nosy: +jjulian

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

From report at bugs.python.org  Sat Jan  9 10:40:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 09:40:05 +0000
Subject: [issue7647] Add statvfs flags to the posix module
In-Reply-To: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>
Message-ID: <1263030005.53.0.128081734712.issue7647@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

IMO these symbols should go to the "stat" module, not the "posix" module.  However, that module is Python, so the values would need to be hardcoded.  Do you know whether they are constant on all relevant systems?

----------
assignee:  -> loewis
nosy: +georg.brandl, loewis

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

From report at bugs.python.org  Sat Jan  9 10:48:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 09:48:53 +0000
Subject: [issue7422] Document inspect.get(full)argspec limitation to Python
	function
In-Reply-To: <1259703494.2.0.925283786633.issue7422@psf.upfronthosting.co.za>
Message-ID: <1263030533.54.0.375402536325.issue7422@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, added "Python" in r77382, r77383.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Jan  9 10:51:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 09:51:48 +0000
Subject: [issue7441] Py3.1: Fatal Python Error: Py_Initialize...unknown
	encoding: chcp 65001.
In-Reply-To: <1260009658.59.0.0106753931217.issue7441@psf.upfronthosting.co.za>
Message-ID: <1263030708.99.0.765131434337.issue7441@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

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

From report at bugs.python.org  Sat Jan  9 11:03:01 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 10:03:01 +0000
Subject: [issue7498] test_multiprocessing test_rapid_restart fails if port
	9999 already in use
In-Reply-To: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
Message-ID: <1263031381.49.0.600992243315.issue7498@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can this be closed?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Jan  9 11:03:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Jan 2010 10:03:23 +0000
Subject: [issue7647] Add statvfs flags to the posix module
In-Reply-To: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>
Message-ID: <1263031403.64.0.315131802227.issue7647@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think having a stat module is a mistake in the first place. It's primary purpose (giving symbolic names to fields in a stat result) is out-of-date, now that we have named tuples. It's secondary purpose (collecting symbolic constants and macros around them) is flawed, as there is no guarantee that they are fixed across systems (unless we explicitly map the values correspondingly.

So I support addition of the constants to the posix module. Not sure whether documentation is lacking in the patch (i.e. whether they ought to be documented).

----------

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

From report at bugs.python.org  Sat Jan  9 11:22:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 10:22:26 +0000
Subject: [issue7647] Add statvfs flags to the posix module
In-Reply-To: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>
Message-ID: <1263032546.07.0.792700907462.issue7647@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay.  Would it then make sense to migrate those constants in the stat module to posix, and deprecate the former?

----------

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

From report at bugs.python.org  Sat Jan  9 11:25:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 10:25:26 +0000
Subject: [issue7507] pipes.quote does not correctly escape !
In-Reply-To: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
Message-ID: <1263032726.76.0.540199553315.issue7507@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm attaching a patch that changes quote() logic.  It also fixes #7476, the empty argument case.

Strings with unsafe characters are now always quoted with single quotes. Single quotes themselves are replaced by a single quote in double quotes, so that

    te$t'quoting

becomes

    'te$t'"'"'quoting'

which I believe is portable across all commonly used shells.

(Another implementation would be to just backslash-quote all unsafe chars, but it makes for less readable results.)

Assigning to David for review -- you recently claimed to like shells :)

----------
assignee:  -> r.david.murray
nosy: +georg.brandl, r.david.murray

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

From report at bugs.python.org  Sat Jan  9 11:45:57 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Sat, 09 Jan 2010 10:45:57 +0000
Subject: [issue7651] Python3: guess text file charset using the BOM
In-Reply-To: <1262833437.24.0.308267564541.issue7651@psf.upfronthosting.co.za>
Message-ID: <1263033957.3.0.943516410262.issue7651@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

IMHO this is the wrong approach.

As Martin v. L?wis suggested here http://mail.python.org/pipermail/python-dev/2010-January/094841.html the best solution would be a new codec (which he named sniff), that autodetects the encoding on reading. This doesn't require *any* changes to the IO library. It could even be developed as a standalone project and published in the Cheeseshop.

----------
nosy: +doerwalter

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

From report at bugs.python.org  Sat Jan  9 14:23:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Jan 2010 13:23:20 +0000
Subject: [issue7498] test_multiprocessing test_rapid_restart fails if port
	9999 already in use
In-Reply-To: <1260739335.32.0.700170561891.issue7498@psf.upfronthosting.co.za>
Message-ID: <1263043400.46.0.0943426268047.issue7498@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Sat Jan  9 17:31:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Jan 2010 16:31:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263054668.07.0.409353427309.issue7092@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This can wait.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sat Jan  9 17:37:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 09 Jan 2010 16:37:24 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1263055044.93.0.587371637787.issue7559@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Wouldn't this be a backwards incompatible change of tested behaviour though?

----------

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

From report at bugs.python.org  Sat Jan  9 17:47:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Jan 2010 16:47:37 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263055657.3.0.594075402908.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Second patch, adding a fix for the rounding bug to the first patch.

----------
Added file: http://bugs.python.org/file15796/issue7632_v2.patch

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

From report at bugs.python.org  Sat Jan  9 17:54:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Jan 2010 16:54:18 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263056058.18.0.0675362419811.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's the (rather crude) testing program that turned up these errors.

----------
Added file: http://bugs.python.org/file15797/test_dtoa.py

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

From report at bugs.python.org  Sat Jan  9 17:58:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 09 Jan 2010 16:58:31 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1263056311.52.0.775733135775.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

New version detects DST using time.daylight flag.

utcoffset = -(time.altzone if time.daylight else time.timezone) // 60

----------
Added file: http://bugs.python.org/file15798/diff.py_iso_timestamps_true_with_dst.diff

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

From report at bugs.python.org  Sat Jan  9 18:06:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Jan 2010 17:06:51 +0000
Subject: [issue6327] [mimetext] long lines get cut with exclamation mark and
	newline
In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>
Message-ID: <1263056811.45.0.0645039553455.issue6327@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since there's no response I'm closing this as 'works for me'.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> works for me
stage:  -> committed/rejected

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

From report at bugs.python.org  Sat Jan  9 18:08:35 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 09 Jan 2010 17:08:35 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1263056915.24.0.578986955789.issue7559@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'm unhappy with a straight change in behaviour because it will break code that is currently catching AttributeError.

A slightly less invasive change would be to raise an AttributeError if the module doesn't exist, otherwise letting the original error propagate.

That means distinguishing between a module not existing and an ImportError raised whilst importing the module. Example code that does this by walking the stack: http://twistedmatrix.com/trac/browser/trunk/twisted/python/reflect.py#L382

In addition we could add a new method that loads a test from name, returning an 'ErrorHolder' if loading the test fails. (A TestCase that reraises the original error when run - test discovery already does this in fact so that a test module failing to load doesn't halt discovery.)

----------

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

From report at bugs.python.org  Sat Jan  9 18:09:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 09 Jan 2010 17:09:14 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1263056954.59.0.228930092372.issue7559@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord

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

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: [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  Sat Jan  9 18:28:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Jan 2010 17:28:58 +0000
Subject: [issue6523] smtplib exception smtp.connect TypeError encode_plain
In-Reply-To: <1248070339.45.0.0640518982252.issue6523@psf.upfronthosting.co.za>
Message-ID: <1263058138.26.0.66952728478.issue6523@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> smtplib is broken in Python3

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

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


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


----------
title: time.utcoffset(dst=true) -> time.utcoffset()

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

From report at bugs.python.org  Sat Jan  9 18:50:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Jan 2010 17:50:07 +0000
Subject: [issue6681] email.parser clips trailing \n of multipart/mixed part if
	part ends in \r\n
In-Reply-To: <1249945114.19.0.529736934099.issue6681@psf.upfronthosting.co.za>
Message-ID: <1263059407.55.0.242500444083.issue6681@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This turns out to be a duplicate of issue 5610, which has a better solution.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> email feedparser.py CRLFLF bug: $ vs \Z

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

From report at bugs.python.org  Sat Jan  9 18:56:31 2010
From: report at bugs.python.org (Nick Bastin)
Date: Sat, 09 Jan 2010 17:56:31 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1263059791.75.0.230492989041.issue4366@psf.upfronthosting.co.za>


Nick Bastin <nick.bastin at gmail.com> added the comment:

A more appropriate patch should be (for 2.7 trunk - I'm grabbing a checkout of 3.2 trunk now):

Index: build_ext.py
===================================================================
--- build_ext.py	(revision 77388)
+++ build_ext.py	(working copy)
@@ -280,7 +280,7 @@
         # Python's library directory must be appended to library_dirs
         sysconfig.get_config_var('Py_ENABLE_SHARED')
         if ((sys.platform.startswith('linux') or sys.platform.startswith('gnu')
-             or sys.platform.startswith('sunos'))
+             or sys.platform.startswith('sunos') or sys.platform.startswith('freebsd'))
             and sysconfig.get_config_var('Py_ENABLE_SHARED')):
             if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
                 # building third party extensions


I'm hoping someone will weigh in on whether this should be done on all versions of FreeBSD (I don't see why not, but perhaps there is some magic that I don't understand in newer versions).

----------
keywords: +patch
nosy: +nbastin
Added file: http://bugs.python.org/file15799/4366.diff

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

From report at bugs.python.org  Sat Jan  9 19:21:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Jan 2010 18:21:04 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1263061264.94.0.452981161108.issue4366@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

configure.in has the same action for NetBSD*|FreeBSD*|DragonFly*, so I think distutils should parallel that. Not sure what sys.platform would be on the other BSDs, though.

----------

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

From report at bugs.python.org  Sat Jan  9 19:55:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Jan 2010 18:55:05 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1263063305.24.0.793770757471.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tests applied to trunk in r77391.  Are you interested in producing a py3k version of the patch?

----------

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

From report at bugs.python.org  Sat Jan  9 19:56:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Jan 2010 18:56:12 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1263063372.36.0.709569025234.issue7478@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

So, would this fix be part of python 2.7?

----------

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

From report at bugs.python.org  Sat Jan  9 19:57:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Jan 2010 18:57:05 +0000
Subject: [issue3366] Add gamma function,
	error functions and other C99 math.h functions to math module
In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za>
Message-ID: <1263063425.15.0.293626071831.issue3366@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: pending -> closed

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

From report at bugs.python.org  Sat Jan  9 19:57:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Jan 2010 18:57:37 +0000
Subject: [issue4294] Macros for PyLong: sign, number of digits, fits in an int
In-Reply-To: <1226322752.92.0.0671581209413.issue4294@psf.upfronthosting.co.za>
Message-ID: <1263063457.62.0.289283221403.issue4294@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: pending -> closed

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

From report at bugs.python.org  Sat Jan  9 21:09:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Jan 2010 20:09:20 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263067760.66.0.653263474489.issue7092@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
priority: deferred blocker -> release blocker

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

From report at bugs.python.org  Sat Jan  9 21:36:37 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 09 Jan 2010 20:36:37 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1263069397.64.0.351767663916.issue1023290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r77394. Thank you for the good reviews!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jan  9 21:59:32 2010
From: report at bugs.python.org (Christophe Simonis)
Date: Sat, 09 Jan 2010 20:59:32 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1263070772.91.0.956553176995.issue4331@psf.upfronthosting.co.za>


Christophe Simonis <simonis.christophe at gmail.com> added the comment:

I followed the advice of Raymond and implement a descriptor on partial.

----------
keywords: +patch
Added file: http://bugs.python.org/file15800/issue4331.patch

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

From report at bugs.python.org  Sat Jan  9 22:22:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 09 Jan 2010 21:22:37 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1263072157.97.0.767061131058.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Using time.daylight is incorrect. time.daylight specifies the number of hours that the daylight offset is, not a flag to specify whether or not daylight savings time is in effect.

Steven's suggestion of using time.localtime().tm_isdst seems to be the better route.

----------
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  9 22:26:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 09 Jan 2010 21:26:56 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1263072416.0.0.727999952852.issue7662@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think this would be nice, but see msg97471 from your diff.py ISO timestamp issue. time.daylight should probably be time.localtime().tm_isdst.

----------
nosy: +brian.curtin
type:  -> feature request
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Jan  9 22:58:39 2010
From: report at bugs.python.org (Runar Tenfjord)
Date: Sat, 09 Jan 2010 21:58:39 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1263074319.1.0.738748278218.issue3783@psf.upfronthosting.co.za>


Runar Tenfjord <runar.tenfjord at gmail.com> added the comment:

Multi threading:

According to http://www.sqlite.org/cvstrac/wiki?p=MultiThreading
we need to keep a connection for each thread to support multi threaded
access to the database. 

I came across this when deploying an application in a multi threaded
environment. Solution is to keep the connection in the thread local-data.

Also note that a memory database is not shared between threads and
a hairy workaround with a separate working thread with queues for access
is needed. A memory database could perhaps be disallowed as the dbm is file only?

import threading

class SQLhash(collections.MutableMapping):
    def __init__(self, filename=':memory:', flags='r', mode=None):
        self.__filename = filename
        self.__local = threading.local()
        
        MAKE_SHELF = 'CREATE TABLE IF NOT EXISTS shelf (key TEXT PRIMARY KEY, value TEXT NOT NULL)'
        self.conn.execute(MAKE_SHELF)
        self.conn.commit()
    
    @property
    def conn(self):
        try:
            conn = self.__local.conn
        except AttributeError:
            conn = self.__local.conn = sqlite3.connect(self.__filename)
            self.conn.text_factory = bytes
            
        return conn

----------
type: feature request -> behavior

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

From report at bugs.python.org  Sat Jan  9 23:15:18 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 09 Jan 2010 22:15:18 +0000
Subject: [issue6688] Optimize PyBytes_FromObject.
In-Reply-To: <1250026477.34.0.625583102893.issue6688@psf.upfronthosting.co.za>
Message-ID: <1263075318.8.0.442115267785.issue6688@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r77398.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jan  9 23:59:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 09 Jan 2010 22:59:27 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1263077967.56.0.561867215993.issue7532@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Here it is, with some cleaning and simple Bytes/Bytearray tests.

And Bytearray tests backported to 2.7.

----------
Added file: http://bugs.python.org/file15801/issue7532_wontfix_tests_py3k.diff

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

From report at bugs.python.org  Sat Jan  9 23:59:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 09 Jan 2010 22:59:48 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1263077988.89.0.821705614715.issue7532@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15802/issue7532_bytearray.diff

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

From report at bugs.python.org  Sun Jan 10 00:00:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 09 Jan 2010 23:00:41 +0000
Subject: [issue7507] pipes.quote does not correctly escape !
In-Reply-To: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
Message-ID: <1263078041.2.0.519324019188.issue7507@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Really adding the patch now.

----------
keywords: +patch
Added file: http://bugs.python.org/file15803/pipes.diff

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

From report at bugs.python.org  Sun Jan 10 00:08:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 09 Jan 2010 23:08:53 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1263078533.65.0.473500162308.issue7532@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15801/issue7532_wontfix_tests_py3k.diff

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

From report at bugs.python.org  Sun Jan 10 00:09:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 09 Jan 2010 23:09:15 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1263078555.8.0.820838973535.issue7532@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15804/issue7532_wontfix_tests_py3k.diff

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

From report at bugs.python.org  Sun Jan 10 00:22:43 2010
From: report at bugs.python.org (Nick Bastin)
Date: Sat, 09 Jan 2010 23:22:43 +0000
Subject: [issue4366] cannot find -lpythonX.X when buinding Python on FreeBSD
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1263079363.28.0.419552339337.issue4366@psf.upfronthosting.co.za>


Nick Bastin <nick.bastin at gmail.com> added the comment:

NetBSD is netbsd* and DragonFly is dragonfly* (currently dragonfly2, although I suspect in this way dragonfly1 was identical, if it ever existed).

----------

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

From report at bugs.python.org  Sun Jan 10 00:37:30 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 09 Jan 2010 23:37:30 +0000
Subject: [issue2335] Backport set literals
In-Reply-To: <1205775527.12.0.350527481128.issue2335@psf.upfronthosting.co.za>
Message-ID: <1263080250.13.0.752294868356.issue2335@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

It been a long week, but this patch is now committed as r77400.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 00:51:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 09 Jan 2010 23:51:25 +0000
Subject: [issue7607] stringlib fastsearch could be improved on 64-bit builds
In-Reply-To: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
Message-ID: <1263081085.85.0.499536097968.issue7607@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Proposed in the patch for issue #7622.

----------
stage: needs patch -> 
superseder:  -> [patch] improve unicode methods: split() rsplit() and replace()

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

From report at bugs.python.org  Sun Jan 10 00:54:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Jan 2010 23:54:26 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263081266.38.0.111203413834.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here I come with a patch! nirai idea was the good one: prealloc PyThreadState before creating the thread. Raise a MemoryError if the allocation fail, instead of raising a *fatal* Python error.

Patch is quite simple and allow better error handling.

----------
keywords: +patch
Added file: http://bugs.python.org/file15805/thread_prealloc_pystate.patch

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

From report at bugs.python.org  Sun Jan 10 00:57:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 09 Jan 2010 23:57:30 +0000
Subject: [issue3599] test_pydoc after test_urllib2 causes exception in
	Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1263081450.14.0.829073944602.issue3599@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Since nobody (and no bot) reported this error in twelve months,
we may close it.

----------
resolution:  -> works for me
status: open -> pending

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

From report at bugs.python.org  Sun Jan 10 01:36:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 00:36:01 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1263083761.55.0.369891121165.issue7643@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15806/issue7643_remove_deprecation.diff

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

From report at bugs.python.org  Sun Jan 10 01:41:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 00:41:43 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1263084103.48.0.507785675111.issue3311@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue was fixed by r68768 for issue #3321.

----------
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 01:41:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 00:41:51 +0000
Subject: [issue3311] block operation on closed socket/pipe for multiprocessing
In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za>
Message-ID: <1263084111.28.0.281515939567.issue3311@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Sun Jan 10 01:45:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 00:45:30 +0000
Subject: [issue7643] What is an ASCII linebreak?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1263084330.04.0.438193719442.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Here is draft of the patch to do what is proposed by Marc Andr? on msg97440 (add VT and FF).
Additionnally I upgraded the UCD 5.1 -> 5.2.

The implementation uses field 16 as defined in "py3k" implementation of "makeunicodedata.py". It should minimize differences between Py2 and Py3 implementations.

Documentation and tests are missing.
I can provide a "diff.gz" containing "Modules/unicodedata_db.h", "Modules/unicodename_db.h" and "Objects/unicodetype_db.h", if needed.


- /* Returns 1 for Unicode characters having the category 'Zl',
-  * 'Zp' or type 'B', 0 otherwise.
+ /* Returns 1 for Unicode characters having the line break
+  * property 'BK', 'CR', 'LF' or 'NL' or having bidirectional
+  * type 'B', 0 otherwise.
   */

Note: the "remove_deprecation" should be applied before to remove "-3" warnings.

----------
Added file: http://bugs.python.org/file15807/issue7643_use_LineBreak.diff

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

From report at bugs.python.org  Sun Jan 10 01:46:19 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Jan 2010 00:46:19 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263084379.33.0.206014696739.issue5683@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Updated the patch against the latest version of cPickle.c (r77393).  All tests pass on my Mac.

----------
nosy: +skip.montanaro
Added file: http://bugs.python.org/file15808/cPickle.-r77393.patch

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

From report at bugs.python.org  Sun Jan 10 02:39:15 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:39:15 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263087555.29.0.664325479153.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15729/unicode_escape_single_and_double_quotes.patch

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

From report at bugs.python.org  Sun Jan 10 02:39:19 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:39:19 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263087559.03.0.875118364803.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15771/unicode_escape_reorg.patch

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

From report at bugs.python.org  Sun Jan 10 02:39:21 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:39:21 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263087561.9.0.0343868528631.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15774/unicode_escape_tests.patch

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

From report at bugs.python.org  Sun Jan 10 02:39:24 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:39:24 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263087564.61.0.237793379507.issue7615@psf.upfronthosting.co.za>


Changes by Richard Hansen <rhansen at bbn.com>:


Removed file: http://bugs.python.org/file15775/raw_unicode_escape_tests.patch

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

From report at bugs.python.org  Sun Jan 10 02:43:01 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:43:01 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263087781.9.0.476093940212.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching updated unit tests.  The tests now check to make sure that single and double quotes are escaped.

----------
Added file: http://bugs.python.org/file15809/unicode_escape_tests.patch

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

From report at bugs.python.org  Sun Jan 10 02:50:16 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:50:16 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263088216.59.0.818125204188.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching a minimal patch:
  * unicode_escape now backslash-escapes single and double quotes
  * raw_unicode_escape now unicode-escapes single and double quotes
  * raw_unicode_escape now unicode-escapes backslashes
  * removes pickle's escaping workarounds so that it continues to work
  * updates documentation

----------
Added file: http://bugs.python.org/file15810/unicode_escape_1_minimal.patch

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

From report at bugs.python.org  Sun Jan 10 02:52:42 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:52:42 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263088362.64.0.216173174062.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching a patch for an issue discovered while looking at the code:
  * The UTF-16 decode logic in the Unicode escape encoders no longer reads past the end of the provided Py_UNICODE buffer if the last character's value is between 0xD800 and 0xDC00.

This patch is meant to be applied after unicode_escape_1_minimal.patch.

----------
Added file: http://bugs.python.org/file15811/unicode_escape_2_utf-16_invalid_read.patch

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

From report at bugs.python.org  Sun Jan 10 02:55:17 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 01:55:17 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263088517.3.0.669713599634.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching a patch for another issue discovered while looking at the code:
  * The Unicode escape encoders now check to make sure that the provided size is nonnegative.
  * C API documentation updated to make it clear that size must be nonnegative.

This patch is meant to be applied after unicode_escape_2_utf-16_invalid_read.patch.

----------
Added file: http://bugs.python.org/file15812/unicode_escape_3_check_size_nonnegative.patch

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

From report at bugs.python.org  Sun Jan 10 02:58:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jan 2010 01:58:07 +0000
Subject: [issue7507] pipes.quote does not correctly escape !
In-Reply-To: <1260827310.19.0.583545445855.issue7507@psf.upfronthosting.co.za>
Message-ID: <1263088687.55.0.960723576615.issue7507@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch looks good to me, except that one test fails.  You seem to have inadvertently deleted the '=' from the safe chars list in the test.

We should also add a test for the '' case.  And presumably the docs requested in the other ticket...

----------
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan 10 03:00:07 2010
From: report at bugs.python.org (Richard Hansen)
Date: Sun, 10 Jan 2010 02:00:07 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1263088807.46.0.622871400647.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Attaching a patch that eliminates duplicate code:
  * Merge unicodeescape_string(), PyUnicode_EncodeRawUnicodeEscape(), and modified_EncodeRawUnicodeEscape() into one function called _PyUnicode_EncodeCustomUnicodeEscape().

This patch is meant to be applied after unicode_escape_3_check_size_nonnegative.patch.

----------
Added file: http://bugs.python.org/file15813/unicode_escape_4_eliminate_duplicate_code.patch

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

From report at bugs.python.org  Sun Jan 10 03:31:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 02:31:02 +0000
Subject: [issue4757] reject unicode in zlib
In-Reply-To: <1230382698.86.0.846541744822.issue4757@psf.upfronthosting.co.za>
Message-ID: <1263090662.6.0.667427035514.issue4757@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch was committed to py3k and 3.1. Thank you!

r76836 and r76838

----------

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

From report at bugs.python.org  Sun Jan 10 03:36:13 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Jan 2010 02:36:13 +0000
Subject: [issue5671] Speed up pickling of lists in cPickle
In-Reply-To: <1238700497.01.0.638889592432.issue5671@psf.upfronthosting.co.za>
Message-ID: <1263090973.12.0.902812466285.issue5671@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Still applies cleanly (with a little fuzz) to the trunk after applying
the issue 5683 patch.  Tests all still pass (including xpickle w/ 2.4,
2.5, 2.6 available).

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Sun Jan 10 03:38:43 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Jan 2010 02:38:43 +0000
Subject: [issue5372] Distutils inappropriately reuses .o files between
	extension modules
In-Reply-To: <1235606727.67.0.443849487538.issue5372@psf.upfronthosting.co.za>
Message-ID: <1263091123.22.0.080790204524.issue5372@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

LGTM.  Nothing is quite as satisfying as simply deleting a bunch of
logic/lines.

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Sun Jan 10 03:58:09 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Jan 2010 02:58:09 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1263092289.91.0.164441276088.issue7319@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Committed in r77402. I am going to wait to see if any doc changes occur before I commit in py3k.

For historical reasons, here is the thread that hashed out the reasonsing: http://mail.python.org/pipermail/stdlib-sig/2009-November/000789.html

And thanks to everyone who helped out with this!

----------
keywords:  -needs review
stage: patch review -> 
versions:  -Python 2.7

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

From report at bugs.python.org  Sun Jan 10 04:04:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 03:04:18 +0000
Subject: [issue7455] cPickle: stack underflow in load_pop()
In-Reply-To: <1260241159.34.0.385504670934.issue7455@psf.upfronthosting.co.za>
Message-ID: <1263092657.96.0.507973688113.issue7455@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Committed in all four branches.

trunk: r77352

----------

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

From report at bugs.python.org  Sun Jan 10 04:08:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 03:08:20 +0000
Subject: [issue7458] crash in str.rfind() with an invalid start value
In-Reply-To: <1260267670.29.0.0996792135992.issue7458@psf.upfronthosting.co.za>
Message-ID: <1263092900.61.0.258241222444.issue7458@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Ok, I've committed the tests after the patch for issue7462 removed the offending code. Thanks!

r77241 and r77247 in trunk

----------

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

From report at bugs.python.org  Sun Jan 10 05:13:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 10 Jan 2010 04:13:33 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263096813.83.0.562468801404.issue7092@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I read the diff for revision 77310 and noticed that arguments with parens
(I mean things like ``def spam((x, y))``, forgot the name) were replaced
by grab-all arguments that are unpacked later (``def spam(x_y)``). I was
wondering whether the documentation for these changed functions was still
accurate when describing the arguments they take. It seems none of them
have a docstring, and docs.python.org/dev/ isn?t up to date so I can?t
check right now.

Kind regards

----------
nosy: +Merwok

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

From report at bugs.python.org  Sun Jan 10 05:52:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Jan 2010 04:52:53 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1263096813.83.0.562468801404.issue7092@psf.upfronthosting.co.za>
Message-ID: <bbaeab101001092052i4fbb7395q865926afe634a9e8@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

The documentation is still accurate. The translation is literal so there no
shift except where the unpacking exception occurs.

On Sat, Jan 9, 2010 at 20:13, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Hello
>
> I read the diff for revision 77310 and noticed that arguments with parens
> (I mean things like ``def spam((x, y))``, forgot the name) were replaced
> by grab-all arguments that are unpacked later (``def spam(x_y)``). I was
> wondering whether the documentation for these changed functions was still
> accurate when describing the arguments they take. It seems none of them
> have a docstring, and docs.python.org/dev/ isn???t up to date so I can???t
> check right now.
>
> Kind regards
>
> ----------
> nosy: +Merwok
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7092>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15814/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________
-------------- next part --------------
The documentation is still accurate. The translation is literal so there no shift except where the unpacking exception occurs.<br><br><div class="gmail_quote">On Sat, Jan 9, 2010 at 20:13, ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Hello<br>
<br>
I read the diff for revision 77310 and noticed that arguments with parens<br>
(I mean things like ``def spam((x, y))``, forgot the name) were replaced<br>
by grab-all arguments that are unpacked later (``def spam(x_y)``). I was<br>
wondering whether the documentation for these changed functions was still<br>
accurate when describing the arguments they take. It seems none of them<br>
have a docstring, and <a href="http://docs.python.org/dev/" target="_blank">docs.python.org/dev/</a> isn???t up to date so I can???t<br>
check right now.<br>
<br>
Kind regards<br>
<br>
----------<br>
nosy: +Merwok<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7092" target="_blank">http://bugs.python.org/issue7092</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

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: [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 06:32:37 2010
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 10 Jan 2010 05:32:37 +0000
Subject: [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: <1263101557.94.0.366979598761.issue7663@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

See also issue5127.

----------
nosy: +Rhamphoryncus

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

From report at bugs.python.org  Sun Jan 10 11:28:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 10:28:25 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1263119305.98.0.326287465797.issue7643@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I don't know what to do about this:

>  - FS, GS, RS are combined marks (CM): ?Prohibit a line break between
>    the character and the preceding character?

I know they are not commonly used. So we can keep them as line breaks.
But if we comply strictly with UAX 14 we do not consider them as line breaks.

----------
components: +Unicode
title: What is an ASCII linebreak? -> What is a Unicode line break character?

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

From report at bugs.python.org  Sun Jan 10 11:36:47 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Jan 2010 10:36:47 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1263119807.89.0.674195097032.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Brian, documentation says quite the opposite.

time.daylight
    Nonzero if a DST timezone is defined.
http://docs.python.org/library/time.html?highlight=daylight#time.daylight

----------

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

From report at bugs.python.org  Sun Jan 10 11:58:32 2010
From: report at bugs.python.org (Yateen V. Joshi)
Date: Sun, 10 Jan 2010 10:58:32 +0000
Subject: [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 12:05:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 11:05:12 +0000
Subject: [issue6965] tmpnam should not be used if tempfile or mkstemp are
	available
In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
Message-ID: <1263121512.42.0.674523198984.issue6965@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I get similar warnings while building on Debian AMD64:

(...)
libpython2.7.a(posixmodule.o): In function `posix_tmpnam':
./Modules/posixmodule.c:7193: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.7.a(posixmodule.o): In function `posix_tempnam':
./Modules/posixmodule.c:7148: warning: the use of `tempnam' is dangerous, better use `mkstemp'
(...)

----------
nosy: +flox

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

From report at bugs.python.org  Sun Jan 10 12:11:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 11:11:24 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1263121884.67.0.68560286471.issue2973@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Still occurs on dev and py3k.
And patch applies correctly.

----------
nosy: +flox
versions:  -Python 3.0

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

From report at bugs.python.org  Sun Jan 10 12:11:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 11:11:40 +0000
Subject: [issue6965] tmpnam should not be used if tempfile or mkstemp are
	available
In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
Message-ID: <1263121900.32.0.662436540743.issue6965@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
type:  -> compile error

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

From report at bugs.python.org  Sun Jan 10 12:13:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 11:13:57 +0000
Subject: [issue2973] _ssl compiler warnings
In-Reply-To: <1211822122.76.0.619319801709.issue2973@psf.upfronthosting.co.za>
Message-ID: <1263122037.4.0.157519620019.issue2973@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It occurs on Debian Lenny AMD64.

----------

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

From report at bugs.python.org  Sun Jan 10 12:19:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Jan 2010 11:19:51 +0000
Subject: [issue6965] tmpnam should not be used if tempfile or mkstemp are
	available
In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
Message-ID: <1263122391.8.0.276258431453.issue6965@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The os.tmpnam and os.tempnam functions are already removed from Python 3.x:  see issue 1318 for the discussion leading to that removal.  I don't see a way to remove them from 2.7 without breaking backwards compatibility.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sun Jan 10 12:45:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Jan 2010 11:45:58 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1263123958.07.0.724424854859.issue7662@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Answered in msg97503

In the meanwhile it looks like another proposal about RFC format in issue #7584 doesn't account for proper timezone too.

----------

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

From report at bugs.python.org  Sun Jan 10 12:46:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 11:46:50 +0000
Subject: [issue6965] tmpnam should not be used if tempfile or mkstemp are
	available
In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
Message-ID: <1263124010.08.0.169225053576.issue6965@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Then close it as duplicate of issue486434, which was closed for the same reason.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 13:01:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Jan 2010 12:01:14 +0000
Subject: [issue7532] Extended slicing with classic class behaves strangely
In-Reply-To: <1261068849.95.0.141869907153.issue7532@psf.upfronthosting.co.za>
Message-ID: <1263124874.43.0.21403904971.issue7532@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks!  Applied in r77408.

----------
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 14:27:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Jan 2010 13:27:30 +0000
Subject: [issue5377] Strange behavior when performing int on a Decimal
	made	from -sys.maxint-1
In-Reply-To: <1235679869.5.0.97489087981.issue5377@psf.upfronthosting.co.za>
Message-ID: <1263130050.88.0.964601834041.issue5377@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority: low -> normal

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

From report at bugs.python.org  Sun Jan 10 15:24:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 14:24:32 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263133472.71.0.110672842718.issue7661@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch attached.

----------
keywords: +patch
nosy: +flox
stage: needs patch -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file15815/issue7661_ctypes_path.diff

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

From report at bugs.python.org  Sun Jan 10 15:30:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 14:30:35 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263133835.1.0.155571717441.issue7661@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Build, ctypes

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

From report at bugs.python.org  Sun Jan 10 15:32:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 14:32:47 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263133967.98.0.861813891752.issue7661@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15815/issue7661_ctypes_path.diff

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

From report at bugs.python.org  Sun Jan 10 15:33:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 14:33:36 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263134016.11.0.969014631038.issue7661@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Fixed typo in previous patch.

----------
Added file: http://bugs.python.org/file15816/issue7661_ctypes_path.diff

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

From report at bugs.python.org  Sun Jan 10 15:44:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jan 2010 14:44:20 +0000
Subject: [issue7664] python logger does not handle IOError Exception
In-Reply-To: <1263121111.41.0.440295567357.issue7664@psf.upfronthosting.co.za>
Message-ID: <1263134660.36.0.984566934924.issue7664@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Sun Jan 10 16:22:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 15:22:59 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263136979.06.0.987146163636.issue5683@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There were a couple of comments on the Rietveld code review above.

----------

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

From report at bugs.python.org  Sun Jan 10 16:38:37 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Jan 2010 15:38:37 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1263136979.06.0.987146163636.issue5683@psf.upfronthosting.co.za>
Message-ID: <19273.62584.224409.827957@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> There were a couple of comments on the Rietveld code review
    Antoine> above.

Indeed there are.  Given that the Unladen Swallow folks were focusing on the
2.6 branch and their goal was to improve performance I don't see any reason
to not accept what they've done, then tweak it for 2.7/3.1 assuming the
changes you and Alexandre suggested further improve performance.

Skip

----------

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

From report at bugs.python.org  Sun Jan 10 16:52:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 15:52:25 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <19273.62584.224409.827957@montanaro.dyndns.org>
Message-ID: <1263138802.3610.7.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Indeed there are.  Given that the Unladen Swallow folks were focusing on the
> 2.6 branch and their goal was to improve performance I don't see any reason
> to not accept what they've done, then tweak it for 2.7/3.1 assuming the
> changes you and Alexandre suggested further improve performance.

The main thing I'm worried about is the potentially unbounded buffering,
since it could reduce performance (or even thrash the machine) instead
of improving it.

----------

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

From report at bugs.python.org  Sun Jan 10 16:57:48 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Jan 2010 15:57:48 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1263138802.3610.7.camel@localhost>
Message-ID: <19273.63735.521268.278511@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> The main thing I'm worried about is the potentially unbounded
    Antoine> buffering, since it could reduce performance (or even thrash
    Antoine> the machine) instead of improving it.

Got a test case in mind?  If so, I'll code it up and compare 2.6 and Unladen
Swallow as well as offer it up for inclusion in the U-S test suite.

S

----------

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

From report at bugs.python.org  Sun Jan 10 17:02:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 16:02:56 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <19273.63735.521268.278511@montanaro.dyndns.org>
Message-ID: <1263139435.3610.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Got a test case in mind?  If so, I'll code it up and compare 2.6 and Unladen
> Swallow as well as offer it up for inclusion in the U-S test suite.

Trying to pickle a structure that's larger than half the RAM should do
the trick. Something like a list of large strings.

----------

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

From report at bugs.python.org  Sun Jan 10 17:23:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 16:23:34 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263140614.18.0.323145820881.issue7661@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It fails if path contains space, too.

Additional patch fixes this case.

----------
Added file: http://bugs.python.org/file15817/issue7661_ctypes_path_space.diff

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

From report at bugs.python.org  Sun Jan 10 17:32:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 16:32:06 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263141126.56.0.486462167507.issue5683@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Quick test on a 3GB machine:

Without patch ("top" shows the process reaches 1.2GB RAM max):

$ time ./python -c "import cPickle;l=['a'*1024 for i in xrange(1000000)];cPickle.dump(l, open('/dev/null', 'wb'))"
10.67user 1.47system 0:12.92elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+319042minor)pagefaults 0swaps

With the patch, the same command quickly swaps hopelessly and after 5 minutes of elapsed time I finally manage to kill the process.

----------

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

From report at bugs.python.org  Sun Jan 10 17:41:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 16:41:08 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263141668.34.0.23632330697.issue7661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks ok to me. Thomas, do you have any take on this?

----------

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

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: [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 17:59:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Jan 2010 16:59:59 +0000
Subject: [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: <1263142799.86.0.0860222520043.issue7663@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +amaury.forgeotdarc, ezio.melotti, loewis
priority:  -> normal
stage:  -> test needed
type:  -> behavior

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

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


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, orsenthil
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Sun Jan 10 18:16:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jan 2010 17:16:41 +0000
Subject: [issue6854] UnicodeDecodeError when retrieving binary data from
	cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1263143801.26.0.597845113392.issue6854@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This appears to be a duplicate of issue 4953.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> cgi module cannot handle POST with multipart/form-data in 3.0

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

From report at bugs.python.org  Sun Jan 10 18:34:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Jan 2010 17:34:58 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263144898.39.0.63480739938.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more incorrectly rounded result, this time for a normal number:

AssertionError: Incorrectly rounded str->float conversion for 99999999999999994487665465554760717039532578546e-47: expected 0x1.0000000000000p+0, got 0x1.fffffffffffffp-1

----------

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

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: [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 18:37:38 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Jan 2010 17:37:38 +0000
Subject: [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: <1263145058.15.0.729651966223.issue7648@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 77411 for trunk. Will merge it to other branches.

----------
versions: +Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Jan 10 18:37:51 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Jan 2010 17:37:51 +0000
Subject: [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: <1263145071.62.0.352008785475.issue7648@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Sun Jan 10 18:41:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 17:41:32 +0000
Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\"
In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za>
Message-ID: <1263145292.87.0.976750013671.issue7665@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Similar issue with test_ntpath.

/tmp/py2u? ? un\icode $ ./python Lib/test/regrtest.py test_ntpath
test_ntpath
test test_ntpath failed -- Traceback (most recent call last):
  File "/tmp/py2u? ? un\icode/Lib/test/test_ntpath.py", line 171, in test_relpath
    tester('ntpath.relpath("a", "../b")', '..\\'+currentdir+'\\a')
  File "/tmp/py2u? ? un\icode/Lib/test/test_ntpath.py", line 13, in tester
    %(str(fn), str(wantResult), str(gotResult))
TestFailed: ntpath.relpath("a", "../b") should return: ..\py2u? ? un\icode\a but returned: ..\icode\a

1 test failed:
    test_ntpath

----------
title: test_urllib2 fails if path contains "\" -> test_urllib2 and test_ntpath fail if path contains "\"

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

From report at bugs.python.org  Sun Jan 10 18:43:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jan 2010 17:43:52 +0000
Subject: [issue7119] email: msg.items() returns different values before and
	after msg.as_string()
In-Reply-To: <1255460286.78.0.388078271026.issue7119@psf.upfronthosting.co.za>
Message-ID: <1263145432.35.0.232696629987.issue7119@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied in r77412, with ie and eg changed to 'for example'.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 19:00:13 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 10 Jan 2010 18:00:13 +0000
Subject: [issue7663] UCS4 build incorrectly translates cases for non-BMP code
	points
In-Reply-To: <1263101250.07.0.175926881279.issue7663@psf.upfronthosting.co.za>
Message-ID: <1263146413.19.0.319311259973.issue7663@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

This is a duplicate of http://bugs.python.org/issue5127

----------
nosy: +lemburg
resolution:  -> duplicate
status: open -> closed
title: UTF-16 build incorrectly translates cases for non-BMP code points -> UCS4 build incorrectly translates cases for non-BMP code points

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

From report at bugs.python.org  Sun Jan 10 19:01:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Jan 2010 18:01:13 +0000
Subject: [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: <1263146473.36.0.546245794631.issue7648@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

merged it in other branches: r77413,r77414,r77415.
This fixes the errors in test_trivial tests. Verified on windows.

----------
assignee:  -> orsenthil
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 19:04:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Jan 2010 18:04:27 +0000
Subject: [issue5127] Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
In-Reply-To: <1233538306.69.0.00753244691607.issue5127@psf.upfronthosting.co.za>
Message-ID: <1263146667.09.0.370286472894.issue5127@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
superseder:  -> UCS4 build incorrectly translates cases for non-BMP code points

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

From report at bugs.python.org  Sun Jan 10 19:05:01 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 10 Jan 2010 18:05:01 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1263119305.98.0.326287465797.issue7643@psf.upfronthosting.co.za>
Message-ID: <4B4A16CA.1080005@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Florent Xicluna wrote:
> 
> Florent Xicluna <laxyf at yahoo.fr> added the comment:
> 
> I don't know what to do about this:
> 
>>  - FS, GS, RS are combined marks (CM): ?Prohibit a line break between
>>    the character and the preceding character?
> 
> I know they are not commonly used. So we can keep them as line breaks.
> But if we comply strictly with UAX 14 we do not consider them as line breaks.

Right. The only update we'd have to do is add FF and VT.

I am a little worried about the possible breakage this may cause,
though. E.g. if you look at a file with FFs in Emacs, the FFs don't
show up as line breaks. FFs in CSV files are currently also not regarded
as line breaks and thus don't need to be placed in quotes.

VTs are probably a non-issue, since they are not in common use.

----------

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

From report at bugs.python.org  Sun Jan 10 19:05:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Jan 2010 18:05:29 +0000
Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\"
In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za>
Message-ID: <1263146729.16.0.414287403304.issue7665@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

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

From report at bugs.python.org  Sun Jan 10 19:05:43 2010
From: report at bugs.python.org (Austin English)
Date: Sun, 10 Jan 2010 18:05:43 +0000
Subject: [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: <1263146743.45.0.448382678238.issue7648@psf.upfronthosting.co.za>


Austin English <austinenglish+python at gmail.com> added the comment:

Woohoo, thanks!

----------

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

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: [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:12:08 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Jan 2010 18:12:08 +0000
Subject: [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: <1263147128.83.0.284266343466.issue7648@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Just a Note: test_file in py26 had problems with multiple ips in this scenario (execute test.test_urllib2 from different drive in windows), but not in the py3k version. I need to verify it py26-maint/trunk.

----------

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

From report at bugs.python.org  Sun Jan 10 19:14:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 10 Jan 2010 18:14:52 +0000
Subject: [issue5127] Use Py_UCS4 instead of Py_UNICODE in unicodectype.c
In-Reply-To: <1262997921.1.0.403720271527.issue5127@psf.upfronthosting.co.za>
Message-ID: <4B4A1914.3050308@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> I don't see the point in changing the various conversion APIs in the
>> unicode database to return Py_UCS4 when there are no conversions that
>> map code points between BMP and non-BMP.
> 
> For consistency: if Py_UNICODE_ISPRINTABLE is changed to take Py_UCS4, Py_UNICODE_TOLOWER should also take Py_UCS4, and must return the same type.
> 
>> In order to solve the problem in question (unicode_repr() failing), 
>> we should change the various property checking APIs to accept Py_UCS4
>> input data. This needlessly increases the type database size without
>> real benefit.
> [I'm not sure to understand. For me the 'real benefit' is that it solves the problem in question.]

The problem in question is already solved by just changing the property
checking APIs. Changing the conversion APIs fixes a non-problem, since there
are no mappings that would require Py_UCS4 on a UCS2 build.

> Yes this increases the type database: there are 300 more "case" statements in _PyUnicode_ToNumeric(), and the PyUnicode_TypeRecords array needs 1068 more bytes.
> On Windows, VS9.0 release build, unicodectype.obj grows from 86Kb to 94Kb; python32.dll is exactly 1.5Kb larger (from 2219Kb to 2221.5Kb);
> the memory usage of the just-started interpreter is about 32K larger (around 5M).  These look reasonable figures to me.
> 
>> For that to work properly we'll have to either make sure that
>> extensions get recompiled if they use these changed APIs, or we
>> provide an additional set of UCS2 APIs that extend the Py_UNICODE
>> input value to a Py_UCS4 value before calling the underlying Py_UCS4
>> API.
> 
> Extensions that use these changed APIs need to be recompiled, or they won't load: existing modules link with symbols like _PyUnicodeUCS2_IsPrintable, when the future interpreter will define _PyUnicode_IsPrintable.

Hmm, that's a good point.

OK, you got me convinced: let's go for it then.

----------

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

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: [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: [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:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Jan 2010 18:42:16 +0000
Subject: [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 19:46:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 10 Jan 2010 18:46:24 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1263149184.05.0.31752933309.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The documentation could use some work. It means that if the timezone does use a daylight savings time period, time.daylight specifies the amount of the offset. In my timezone this value is 1. However, time.localtime().is_dst is currently 0, because we are not on savings time.

For that reason, using time.daylight in your patch gives an incorrect result for me.

----------

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

From report at bugs.python.org  Sun Jan 10 19:57:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 10 Jan 2010 18:57:55 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1263149875.57.0.513846303081.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

http://msdn.microsoft.com/en-us/library/2t504ch6%28VS.80%29.aspx has some info for how this is implemented on Windows, and I get the same results on my Mac. 

On Linux an AttributeError is raised time.struct_time not having an attribute is_dst, and time.daylight matches the other two platforms.

----------

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

From report at bugs.python.org  Sun Jan 10 20:01:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 19:01:41 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263150101.93.0.466725357113.issue7661@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Updated: added quotes on line 2319.

----------
Added file: http://bugs.python.org/file15820/issue7661_ctypes_path_space.diff

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

From report at bugs.python.org  Sun Jan 10 20:01:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 19:01:55 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263150115.67.0.52078935962.issue7661@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15817/issue7661_ctypes_path_space.diff

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

From report at bugs.python.org  Sun Jan 10 20:06:46 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 10 Jan 2010 19:06:46 +0000
Subject: [issue7664] python logger does not handle IOError Exception
In-Reply-To: <1263121111.41.0.440295567357.issue7664@psf.upfronthosting.co.za>
Message-ID: <1263150406.71.0.17397571285.issue7664@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Please clarify exsctly what you mean by "multiprocessing logger". Note that logging does not support logging to the same file from concurrent processes (threads *are* supported). See

http://docs.python.org/library/logging.html#logging-to-a-single-file-from-multiple-processes

for more information.

Also, I don't believe your fix is appropriate for the core logging module, and it's not clear to me why a lock failure would occur if the disk was full. It might be that way on Solaris (don't have use of a Solaris box), but not in general. In fact, this appears from your stack trace to be a problem in some custom handler you are using (defined in the file cloghandler.py on your system).

In any event, if you believe you can recover from the error, the right thing to do is to subclass the file handler you are using and override its handleError method to attempt recovery.

Did you post this problem on comp.lang.python? There are bound to be other Solaris users there who may be able to reproduce your problem and/or give you more advice about it.

Closing, as this is not a logging bug AFAICT.

----------
assignee:  -> vinay.sajip
resolution:  -> invalid
stage: test needed -> 
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 20:07:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 19:07:17 +0000
Subject: [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 20:20:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 19:20:52 +0000
Subject: [issue7670] _sqlite3: Block *all* operations on a closed Connection
	object
In-Reply-To: <1263148934.81.0.796800587233.issue7670@psf.upfronthosting.co.za>
Message-ID: <1263151252.3.0.288496760349.issue7670@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ghaering
nosy: +ghaering
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan 10 20:43:59 2010
From: report at bugs.python.org (Tim Peters)
Date: Sun, 10 Jan 2010 19:43:59 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263152639.23.0.315850049665.issue7632@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Showing once again that a proof of FP code correctness is about as compelling as a proof of God's ontological status ;-)

Still, have to express surprised admiration for 99999999999999994487665465554760717039532578546e-47!  That one's not even close to being a "hard" case.

----------
nosy: +tim_one

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

From report at bugs.python.org  Sun Jan 10 20:52:15 2010
From: report at bugs.python.org (Adam Olsen)
Date: Sun, 10 Jan 2010 19:52:15 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1263153135.09.0.0405786287299.issue1943@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Points against the subclassing argument:

* We have a null-termination invariant.  For byte strings this was part of the public API, and I'm not sure that's changed for unicode strings; aren't you arguing that we should maximize how much of our implementation is a public API?  This prevents lazy slicing.

* UTF-16 and UTF-32 are rarely used encodings, especially for longer strings (ie files).  For shorter strings (APIs) the unicode object overhead is more significant and we'd need a way to slave to the buffer's lifetime to that of the unicode object (hard to do).  For longer strings UTF-8 would be much more useful, but that's been shot down before.

* subclassing unicode so you can change the meaning of the fields (ie allocating your own buffer) is a gross hack.  It relies far too much on fine details of the implementation and is fragile (what if you miss the dummy byte needed by fastsearch?)  Most of the possible options could be, if they function correctly, applied directly to the basetype as a patch, so it's moot.

* If you dislike PyVarObject in general (I think the API is ugly too) you should argue for a general policy discouraging future use of it, not just get in the way of the one place where it's most appropriate

Terry: PyVarObjects would be much easier to subclass if the type object stored an offset to the beginning of the variable section, so it could be automatically recalculated for subclasses based on the size of the struct.  This'd mean the PyBytesObject struct would no longer end with a char ob_sval[1].  The down side is a tiny bit more math when accessing the variable section (as the offset is no longer constant).

----------
nosy: +Rhamphoryncus

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

From report at bugs.python.org  Sun Jan 10 21:10:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 10 Jan 2010 20:10:54 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1263154254.9.0.203723679834.issue7582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Whoops, nevermind the Linux comment on that last one. My typo there caused the exception. The result there is the same as the other platforms.

----------

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

From report at bugs.python.org  Sun Jan 10 21:27:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Jan 2010 20:27:04 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1263155224.48.0.762273279717.issue7671@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch attached.

----------
keywords: +patch
stage:  -> patch review
title: test_popen fails if path contains semi-colon ";" -> test_popen fails if path contains special char like ";"
Added file: http://bugs.python.org/file15821/issue7671_test_popen.diff

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

From report at bugs.python.org  Sun Jan 10 21:38:38 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 10 Jan 2010 20:38:38 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263155918.49.0.0737524167047.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

If the sequence of readaheads is ['a\r', '\nb\n'], the first use of the pattern will consume 'a', then the peek(2) will trigger a read() and the next use of the pattern will consume '\r\n'.

I updated the patch and enhanced a little the inline comments to clear this up and added the suggested test.

I also ventured into a rewrite of the read() function since it seems to contain various latent bugs / problems, probably the result of ages of slow refactoring. For example, decompressor flush() depends on self.eof flag which is never set and the decrypter is fed by the raw buffer which is in turn set by the decompresser, thus theoretically feeding decrypted data back to the decrypter.

I also made it completely buffered so now small reads are significantly faster.

If this patch is good, i'll prepare a patch for python 3.x and 2.6

----------
Added file: http://bugs.python.org/file15822/zipfile_7610_py27.diff

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

From report at bugs.python.org  Sun Jan 10 21:42:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Jan 2010 20:42:54 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1263156174.44.0.871780309656.issue7671@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77420.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Jan 10 21:44:51 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Jan 2010 20:44:51 +0000
Subject: [issue7666] test_lib2to3 fails if path contains space
In-Reply-To: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>
Message-ID: <1263156291.76.0.60727568538.issue7666@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77419.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

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: [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  Sun Jan 10 22:53:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Jan 2010 21:53:44 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263160424.35.0.150803455187.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Showing once again that a proof of FP code correctness is about as
> compelling as a proof of God's ontological status ;-)

Clearly we need a 1000-page Isabelle/HOL-style machine-checked formal proof, rather than a ten-page TeX proof.  Any takers?

All of the above bugs seem to have been introduced with the new 'bigcomp' code that arrived on March 16, 2009, just a couple of weeks before I downloaded the version that got adapted for Python;  in retrospect, I probably should have used the NO_STRTOD_BIGCOMP #define to bypass the new code.

----------

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

From report at bugs.python.org  Sun Jan 10 22:59:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 10 Jan 2010 21:59:27 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1263153135.09.0.0405786287299.issue1943@psf.upfronthosting.co.za>
Message-ID: <4B4A4DBC.2090009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Adam Olsen wrote:
> 
> Adam Olsen <rhamph at gmail.com> added the comment:
> 
> Points against the subclassing argument:
> 
> * We have a null-termination invariant.  For byte strings this was part of the public API, and I'm not sure that's changed for unicode strings; aren't you arguing that we should maximize how much of our implementation is a public API?  This prevents lazy slicing.

Base type Unicode buffers end with a null-Py_UNICODE termination,
but this is not used anywhere, AFAIK. We could probably remove
that overallocation at some point.

There's no such thing as a null-termination invariant for Unicode.

> * subclassing unicode so you can change the meaning of the fields (ie allocating your own buffer) is a gross hack.  It relies far too much on fine details of the implementation and is fragile (what if you miss the dummy byte needed by fastsearch?)  Most of the possible options could be, if they function correctly, applied directly to the basetype as a patch, so it's moot.

Actually, Unicode objects were designed to be subclassable right
from the start and adjusting the buffer to point e.g. into some
other already allocated string was too. I removed this feature from
Fredrik's type implementation with the intent to readd it later on as
subclass.

See the prototype implementation of such a subclass uniref that I've
written to show how easy it is to add a subclass which can be used
to slice large Unicode objects without having to reallocate new
buffers all the time.

BTW, I'm not aware of any changes to the PyUnicodeObject by some
fastsearch implementation. Could you point me to this ?

----------

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

From report at bugs.python.org  Sun Jan 10 23:27:36 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 10 Jan 2010 22:27:36 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1263162456.08.0.552290394242.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Base type Unicode buffers end with a null-Py_UNICODE termination,
> but this is not used anywhere, AFAIK
On Windows, code like 
   CreateDirectoryW(PyUnicode_AS_UNICODE(po), NULL)
is very common, at least in posixmodule.c.

----------

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

From report at bugs.python.org  Sun Jan 10 23:36:28 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Jan 2010 22:36:28 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1263162988.07.0.679852483236.issue1943@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I find that the null termination for 8-bit strings makes low-level parsing operations (e.g., parsing a numeric string) safer and easier:  for example, it makes skipping a series of digits with something like:

while (isdigit(*s)) ++s;

safe.  I'd imagine that null terminated PyUNICODE arrays would have similar benefits.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Sun Jan 10 23:38:06 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 10 Jan 2010 22:38:06 +0000
Subject: [issue5372] Distutils inappropriately reuses .o files between
	extension modules
In-Reply-To: <1235606727.67.0.443849487538.issue5372@psf.upfronthosting.co.za>
Message-ID: <1263163086.08.0.592095135236.issue5372@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This optimization is indeed simplistic. 

I'll also remove _prep_compiler() in trunk, as I don't see a problem in removing it in the 2.7.x and 3.2.x series.

I also need to fix it in 2.6.x / 3.1.x, but I'll keep the private method there.

----------
priority:  -> normal
resolution:  -> accepted
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jan 10 23:49:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 10 Jan 2010 22:49:33 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263163773.81.0.376199465498.issue2449@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Christopher, are you willing to update your patch for the current trunk (2.7)?

----------
nosy: +brian.curtin
stage:  -> needs patch
versions: +Python 2.7 -Python 2.4

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

From report at bugs.python.org  Sun Jan 10 23:50:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 10 Jan 2010 22:50:18 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263163818.1.0.669500738581.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug in Python?

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Jan 10 23:52:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jan 2010 22:52:26 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1263162988.07.0.679852483236.issue1943@psf.upfronthosting.co.za>
Message-ID: <1263164005.3610.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I find that the null termination for 8-bit strings makes low-level
> parsing operations (e.g., parsing a numeric string) safer and easier:

Not to mention faster. The new IO library makes use of it (for newline
detection), on both bytestrings and unicode strings.

----------

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

From report at bugs.python.org  Mon Jan 11 00:37:22 2010
From: report at bugs.python.org (Sean Soria)
Date: Sun, 10 Jan 2010 23:37:22 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263166642.1.0.73769537881.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

Because Python is not cleaning up after itself. I don't see how a multi-threaded app could work around this issue. The only solution I can think of at the app level is to reset those callbacks once python exits, but a different thread could call an SSL function at any point and cause the crash between the time that _ssl.so is unloaded and the app resets the callbacks.

One solution for Python would be to call CRYPTO_get_id_callback and CRYPTO_get_locking_callback and check that they're NULL before setting them. However, it's also stated in the documentation that id_callback doesn't need to be set for all platforms, so a NULL value could still be safe there. I haven't looked at the callbacks python is setting up, so I can't be sure this solution would work.

----------

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

From report at bugs.python.org  Mon Jan 11 00:42:16 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Jan 2010 23:42:16 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1263141126.56.0.486462167507.issue5683@psf.upfronthosting.co.za>
Message-ID: <19274.26066.477134.533402@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> With the patch, the same command quickly swaps hopelessly and
    Antoine> after 5 minutes of elapsed time I finally manage to kill the
    Antoine> process.

Verified with an Unladen Swallow test case.  I'll see if I can fix it.

S

----------

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

From report at bugs.python.org  Mon Jan 11 00:47:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 10 Jan 2010 23:47:11 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263167231.79.0.422702639296.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What operating system is this on?

IIUC, Python has no chance to perform any cleanup. So it's not a bug that no cleanup happens.

I don't understand the proposal of not setting the callback if they are already set. If that is done, how can we be sure that the callbacks that have been installed work correctly?

----------

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

From report at bugs.python.org  Mon Jan 11 00:53:24 2010
From: report at bugs.python.org (Sean Soria)
Date: Sun, 10 Jan 2010 23:53:24 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263167604.12.0.827471889033.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

The issue was debugged on AMD64 Linux, but I was seeing similar crashing on OSX but could not debug because I wasn't getting a proper stack trace (probably because something else was being loaded into that memory space). I have yet to test if not setting those functions on OSX fixes the crashing, but I will soon.

Well Python's installed callbacks don't work correctly, so wouldn't it be safe to assume that if an app has installed callbacks of their own that those work correctly, or at least better than Python's, i.e. they don't bring down the entire app when Python is unloaded.

----------

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

From report at bugs.python.org  Mon Jan 11 01:10:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Jan 2010 00:10:54 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263168654.75.0.526466813286.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So how do you do cleanup on Linux, or on OSX, in a shared library?

I'd claim that the bug is in your application. It shouldn't unload a DLL that is still in use (by having a function pointer into it stored globally).

Testing for a prior pointer value may fix it for you. It won't fix it in the general case, i.e. when you unload the ssl module and *didn't* install your own callbacks, OpenSSl would still call Python's callback.

----------

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

From report at bugs.python.org  Mon Jan 11 01:46:28 2010
From: report at bugs.python.org (Sean Soria)
Date: Mon, 11 Jan 2010 00:46:28 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263170788.83.0.396247042344.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

You've got init_* that Python calls whenever it loads a library, you could just as easily have destroy_*. But that would probably be overkill.

How would the application know that Python has created callbacks? This is just one instance. Who knows where else this is done in any number of libraries. You you suggest that any application which dynamically loads a library never unload it?

What is the general case that this would not be fixed in? If a multi-threaded app uses SSL and doesn't load its own callbacks then it is in violation as libcryto states that certain callbacks must be set. If it doesn't use SSL then it's never going to have a problem as the callbacks will never be called after _ssl.so is unloaded. So the remaining case is a single threaded app that doesn't load the callbacks because it's single-threaded. But in that case it should be using a single threaded python library or it is in violation as it can no longer be considered a single-threaded app, and therefore should have loaded its own callbacks.

----------

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

From report at bugs.python.org  Mon Jan 11 02:05:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Jan 2010 01:05:58 +0000
Subject: [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 02:07:52 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 Jan 2010 01:07:52 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263172072.58.0.55061227672.issue7544@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good; the line
    tstate->thread_id = PyThread_get_thread_ident();
is needed because the tstate is created in the main thread, but used in another thread.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Mon Jan 11 02:21:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Jan 2010 01:21:54 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263172914.0.0.442711180684.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch looks good

I'm not sure about autoTLSkey value. PyThreadState_New() calls _PyGILState_NoteThreadState() which checks that autoTLSkey is not zero, but I don't know if autoTLSkey have the right value with my preallocation patch.

----------

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

From report at bugs.python.org  Mon Jan 11 02:41:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Jan 2010 01:41:42 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263174102.28.0.890625850985.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure about autoTLSkey value (...)

After some tests (printf fun), it looks ok.

--

There is another problem in _testcapi: test_thread_state() calls directly PyThread_start_new_thread() and the thread function calls PyGILState_Ensure(). PyGILState_Ensure() would then require to create a new thread state (call PyThreadState_New()) because it was not done by PyThread_start_new_thread(). On low memory condition, we hit the same bug here.

Only thread and _testcapi modules calls directly PyThread_start_new_thread(). _*test*capi is reserved to tests, so I consider that we don't care about bugs under low memory condition in this module.

----------

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

From report at bugs.python.org  Mon Jan 11 02:47:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 01:47:22 +0000
Subject: [issue7143] get_payload(decode=True) eats last newline
In-Reply-To: <1255630009.17.0.724034195968.issue7143@psf.upfronthosting.co.za>
Message-ID: <1263174442.93.0.98104638318.issue7143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The behavior you object to is in fact correct per RFC 2046, 5.5.1:

   The boundary delimiter MUST occur at the beginning of a line, i.e.,
   following a CRLF, and the initial CRLF is considered to be attached
   to the boundary delimiter line rather than part of the preceding
   part.

So in your example message your attatched file does not in fact have a final newline.  Note that you do not get a newline regardless of whether decode is true ('p' is the part extracted from your sample message):

>>> p.get_payload()
'MTIzCg=='
>>> p.get_payload(decode=True)
'123'

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan 11 04:03:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 03:03:27 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1263179007.53.0.866435195041.issue3244@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Daniel suggested marking this as superseding issue 727898, and I agree.  But I want to note that in that issue Barry suggested that it was possible services from the email package could be useful in building this support, and that there might be a better place for it to live than urllib.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Jan 11 04:04:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 03:04:07 +0000
Subject: [issue727898] Support for sending multipart form data
Message-ID: <1263179047.83.0.904218105233.issue727898@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> multipart/form-data encoding

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

From report at bugs.python.org  Mon Jan 11 05:26:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 04:26:26 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263183986.29.0.554583484228.issue2449@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is blunck2's patch updated against r77393. Once I have a better understanding of the issue I'll see if I can write tests (eg. I don't know the significance of 8002 on line 675, etc).

----------
stage: needs patch -> test needed

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

From report at bugs.python.org  Mon Jan 11 05:27:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 04:27:19 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263184039.25.0.801568028809.issue2449@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15824/issue2449.diff

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

From report at bugs.python.org  Mon Jan 11 06:02:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 05:02:23 +0000
Subject: [issue2644] errors from msync ignored in mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1263186143.8.0.961348379727.issue2644@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Do you have a test case to reproduce the errors?

I see that we call msync followed by munmap, neither one checked.

----------
nosy: +brian.curtin
stage:  -> test needed

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

From report at bugs.python.org  Mon Jan 11 06:15:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2010 05:15:27 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263186927.14.0.638374963893.issue2449@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A few things about the patch:
1) the MarshallError class has a 'message' attribute that results in a warning on some Python versions, it should be renamed in something different (like 'msg');
2) I'm not sure why the <marshallerror></marshallerror> in the exception message is necessary, but I didn't look at the code in xmlrpclib.py so it might be ok;
3) the first 'pos' is not used in the for loop where it is created but only some lines later inside the except, this is not immediately clear, so a short comment should be added;
4) the str(e) is redundant -- there's already %s;
5) the "except Exception, e:" look suspicious, a more specific exception(s) should probably be specified;
6) 'as' should be used instead of the comma in the 'except' statements.

----------
nosy: +ezio.melotti, krisvale, loewis
priority:  -> normal

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

From report at bugs.python.org  Mon Jan 11 06:47:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 05:47:43 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263188863.02.0.979144170305.issue2449@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This patch should address all but #2. I'm not exactly sure of the use-case blunck2 had in mind so I'm not sure how the message would be used.

----------
Added file: http://bugs.python.org/file15825/issue2449_v2.diff

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

From report at bugs.python.org  Mon Jan 11 06:47:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 05:47:52 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263188872.49.0.658802672001.issue2449@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15824/issue2449.diff

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

From report at bugs.python.org  Mon Jan 11 06:59:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 05:59:56 +0000
Subject: [issue2644] errors from msync ignored in mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1263189596.35.0.2514558418.issue2644@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal

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

From report at bugs.python.org  Mon Jan 11 07:20:21 2010
From: report at bugs.python.org (Yateen V. Joshi)
Date: Mon, 11 Jan 2010 06:20:21 +0000
Subject: [issue7664] python logger does not handle IOError Exception
In-Reply-To: <1263121111.41.0.440295567357.issue7664@psf.upfronthosting.co.za>
Message-ID: <1263190821.33.0.649133170026.issue7664@psf.upfronthosting.co.za>


Yateen V. Joshi <yjoshi at starentnetworks.com> added the comment:

ok, thanks. I will try with subclass for handler.
A question however, I do not see IOError exception being handled 
anywhere in the logging module. Is it not possible that the same would
occur when we are trying to 'emit' a record to a log file? Or some other
IO related processing is happening at logger level?

----------

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

From report at bugs.python.org  Mon Jan 11 07:31:17 2010
From: report at bugs.python.org (Craig McQueen)
Date: Mon, 11 Jan 2010 06:31:17 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1263191477.18.0.293771882446.issue2698@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Eric sent a build_ext.py to me and Daniel26 by e-mail. Attached. The idea was to copy it over the one in C:\Python31\Lib\distutils\command.

I tried the file that he sent, but I'm getting the same issue that Daniel26 described.

----------
Added file: http://bugs.python.org/file15826/build_ext.py

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

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: [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 08:08:19 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Jan 2010 07:08:19 +0000
Subject: [issue7664] python logger does not handle IOError Exception
In-Reply-To: <1263190821.33.0.649133170026.issue7664@psf.upfronthosting.co.za>
Message-ID: <87238.32240.qm@web25801.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> From: Yateen V. Joshi <report at bugs.python.org>

> A question however, I do not see IOError exception being handled 
> anywhere in the logging module. Is it not possible that the same would
> occur when we are trying to 'emit' a record to a log file? Or some other
> IO related processing is happening at logger level?

If you look carefully at the code in the module, you will see code like

except:
    self.handleError(record)

which *will* catch IOError. In handleError, you would have access to the exception via sys.exc_info().

----------

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

From report at bugs.python.org  Mon Jan 11 08:35:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Jan 2010 07:35:12 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263170788.83.0.396247042344.issue7672@psf.upfronthosting.co.za>
Message-ID: <4B4AD4AC.9030700@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You you suggest that any application which
> dynamically loads a library never unload it?

Correct. Library unloading just don't work. Trying it anyway
is an endless uphill battle.

----------

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

From report at bugs.python.org  Mon Jan 11 09:08:31 2010
From: report at bugs.python.org (Adam Olsen)
Date: Mon, 11 Jan 2010 08:08:31 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4B4A4DBC.2090009@egenix.com>
Message-ID: <aac2c7cb1001110008s745ec7dbs1bc4b984d0ab7f5c@mail.gmail.com>


Adam Olsen <rhamph at gmail.com> added the comment:

On Sun, Jan 10, 2010 at 14:59, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> BTW, I'm not aware of any changes to the PyUnicodeObject by some
> fastsearch implementation. Could you point me to this ?

    /* We allocate one more byte to make sure the string is Ux0000 terminated.
       The overallocation is also used by fastsearch, which assumes that it's
       safe to look at str[length] (without making any assumptions about what
       it contains). */

----------

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

From report at bugs.python.org  Mon Jan 11 09:23:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 08:23:53 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1263198233.49.0.355785362914.issue7671@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

With r77420, it fails when path contains backslash "\".

Using '"%s" -c "..."' it does not fail.

----------
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Mon Jan 11 10:14:10 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 11 Jan 2010 09:14:10 +0000
Subject: [issue2644] errors from msync ignored in mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1263201250.9.0.538716716957.issue2644@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

No, I don't know how to provoke such an error other than passing illegal parameters..(or munmap'ing the mmap'ed area).

----------

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

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: [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 12:08:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 11:08:00 +0000
Subject: [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: <1263208080.3.0.640573933383.issue7675@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed.

With Python 2:

>>> import pydoc
>>> pydoc.pipepager(u't?tdel?t\n', 'cat')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./Lib/pydoc.py", line 1357, in pipepager
    pipe.write(text)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 1: ordinal not in range(128)



With Python 3:

>>> import pydoc
>>> pydoc.pipepager('t?tdel?t\n', 'cat')
t?tdel?t

----------
nosy: +flox
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Mon Jan 11 13:10:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Jan 2010 12:10:05 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1263211805.45.0.456723879378.issue7633@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

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

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: [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 14:09:14 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2010 13:09:14 +0000
Subject: [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: <1263215354.91.0.739024793272.issue7675@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Jan 11 14:49:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 13:49:30 +0000
Subject: [issue2449] Improved serialization error logging in xmlrpclib
In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za>
Message-ID: <1263217770.16.0.606923512317.issue2449@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I was curious, so I googled.  You may have already found this as well: it's a 'fault code', and apparently there's no standard for such codes.  The choice of 8002 may be modeled on what twisted.web does with exceptions.  Staying consistent with them is not a bad idea if you decide this is a similar enough fault case, but whatever is done it will need to be documented.

On the other hand, I also happened on this document, but I have no idea what its status is in the xmlrpc community:

http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php

----------
nosy: +r.david.murray
versions: +Python 3.2

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

From report at bugs.python.org  Mon Jan 11 15:48:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Jan 2010 14:48:05 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1263221285.57.0.913096448817.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd still like to see this backported to 2.7;  if no-one else is interested in doing the backport, I'll try to find time before the betas.
(Alexandre, if you want to do the backport, please do steal the issue from me.)

----------
assignee: alexandre.vassalotti -> mark.dickinson
status: closed -> open
versions: +Python 2.7

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

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: [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 16:31:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 15:31:31 +0000
Subject: [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: <1263223891.18.0.580119216063.issue7677@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jan 11 17:43:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 16:43:50 +0000
Subject: [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: <1263228230.1.0.921535835645.issue7675@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The unicode text is sent to the subprocess without encoding.
It is encoded implicitly to ASCII (sys.getdefaultencoding()).

This patch performs explicit encoding.
Tests added.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file15828/issue7675_pydoc.diff

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

From report at bugs.python.org  Mon Jan 11 17:46:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Jan 2010 16:46:23 +0000
Subject: [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: <1263228383.94.0.544017948025.issue7675@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should also work with 8-bit docstrings, and the tests should reflect both uses.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Jan 11 18:18:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 17:18:56 +0000
Subject: [issue1349106] email.Generators does not separates headers with "\r\n"
Message-ID: <1263230336.48.0.530544211406.issue1349106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Consider also issue 975330.

----------
nosy: +r.david.murray
versions: +Python 3.2 -Python 3.1

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

From report at bugs.python.org  Mon Jan 11 18:23:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 17:23:42 +0000
Subject: [issue5525] Problem with email.MIME* library, using wrong new line
In-Reply-To: <1237518711.23.0.918881027535.issue5525@psf.upfronthosting.co.za>
Message-ID: <1263230622.66.0.48736325829.issue5525@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Effectively this is a duplicate of issue 1349106, since you are right that it affects more than just boundary production. I believe we are going to address this in a new version of the email module.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan 11 18:43:49 2010
From: report at bugs.python.org (Sean Soria)
Date: Mon, 11 Jan 2010 17:43:49 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263231829.34.0.339866716808.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

Okay, what if I attack this problem from a "it's not thread-safe" point of view? If the callbacks are already loaded, then who knows what state the locks are in. If you replace the locking_callback while a thread already has the lock, and another thread comes in and tries to lock, it will succeed immediately, and two threads will be in the critical section.

Attaching a patch for how I think this should work.

>From Bill via email:
Hmmm, well, is there a standard way to unload Python?  I could put a
__del__ method on the module which would remove the callbacks, I
suppose.  I just never heard of "unloading" a module before.

----------
keywords: +patch
Added file: http://bugs.python.org/file15829/ssl.patch

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

From report at bugs.python.org  Mon Jan 11 18:45:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 17:45:15 +0000
Subject: [issue1422094] email.MIME*.as_string removes duplicate spaces
Message-ID: <1263231915.28.0.359338693682.issue1422094@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Duplicate of issue 5612, which has a small amount of additional info so I'm closing this one.

----------
nosy: +r.david.murray
resolution:  -> duplicate
status: open -> closed
superseder:  -> whitespace folding in the email package could be better ;-)

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

From report at bugs.python.org  Mon Jan 11 19:01:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Jan 2010 18:01:14 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263232874.86.0.442125939066.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There is no way to unload a module, at least not until Python 3. Losing all references to the module won't help.

----------

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

From report at bugs.python.org  Mon Jan 11 19:04:05 2010
From: report at bugs.python.org (Sean Soria)
Date: Mon, 11 Jan 2010 18:04:05 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263233045.54.0.841672033474.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

Yea, I've given up on getting this fixed based on the crash. Now I'm going for it not being thread safe.

----------

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

From report at bugs.python.org  Mon Jan 11 19:08:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Jan 2010 18:08:47 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263233327.57.0.91104012.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is not thread-safe. If two threads where to do the same thing simultaneously, they might (simultaneously) both determine that the lock is not installed, and then one would overwrite the lock of the other, leading exactly to the situation that the patch is meant to prevent.

----------

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

From report at bugs.python.org  Mon Jan 11 21:11:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 20:11:07 +0000
Subject: [issue1454285] test_parsedate_acceptable_to_time_functions+DST == :-(
Message-ID: <1263240667.49.0.121280843403.issue1454285@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can't reproduce this.  If you can, please reopen.

----------
components: +Tests -None
nosy: +r.david.murray
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Mon Jan 11 21:33:23 2010
From: report at bugs.python.org (Steven K. Wong)
Date: Mon, 11 Jan 2010 20:33:23 +0000
Subject: [issue5898] Hang in Popen.wait() when another process has been created
In-Reply-To: <1241208488.61.0.0189551533272.issue5898@psf.upfronthosting.co.za>
Message-ID: <1263242003.58.0.206057661728.issue5898@psf.upfronthosting.co.za>


Steven K. Wong <sliderw at hotmail.com> added the comment:

I think the hang is not a bug. Take a look at the Popen documentation on close_fds. If you specify close_fds=True when creating proc2, the hang will not happen when you remove the "proc2.stdin.close()" line.

----------
nosy: +steven.k.wong

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

From report at bugs.python.org  Mon Jan 11 21:46:59 2010
From: report at bugs.python.org (Sean Soria)
Date: Mon, 11 Jan 2010 20:46:59 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263242819.8.0.103522782023.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

For an app that makes use of SSL itself it better set the callbacks before spawning threads or it's going to be in trouble anyway. For an app not making use of SSL my patch doesn't make the situation any worse. That sounds like an overall gain to me.

----------

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

From report at bugs.python.org  Mon Jan 11 21:51:12 2010
From: report at bugs.python.org (Steven K. Wong)
Date: Mon, 11 Jan 2010 20:51:12 +0000
Subject: [issue5898] Hang in Popen.wait() when another process has been created
In-Reply-To: <1241208488.61.0.0189551533272.issue5898@psf.upfronthosting.co.za>
Message-ID: <1263243072.33.0.406760421417.issue5898@psf.upfronthosting.co.za>


Steven K. Wong <sliderw at hotmail.com> added the comment:

See this related issue: http://bugs.python.org/issue7448

----------

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

From report at bugs.python.org  Mon Jan 11 21:51:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 20:51:26 +0000
Subject: [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: <1263243086.08.0.616662260532.issue7675@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15828/issue7675_pydoc.diff

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

From report at bugs.python.org  Mon Jan 11 21:51:39 2010
From: report at bugs.python.org (Steven K. Wong)
Date: Mon, 11 Jan 2010 20:51:39 +0000
Subject: [issue5898] Hang in Popen.wait() when another process has been created
In-Reply-To: <1241208488.61.0.0189551533272.issue5898@psf.upfronthosting.co.za>
Message-ID: <1263243099.65.0.799546028327.issue5898@psf.upfronthosting.co.za>


Steven K. Wong <sliderw at hotmail.com> added the comment:

See this related issue: http://bugs.python.org/issue7213

----------

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

From report at bugs.python.org  Mon Jan 11 21:53:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 20:53:32 +0000
Subject: [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: <1263243212.36.0.0618478091541.issue7675@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

New patch: backward compatibility preserved.

----------
Added file: http://bugs.python.org/file15830/issue7675_pydoc_v2.diff

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

From report at bugs.python.org  Mon Jan 11 21:56:31 2010
From: report at bugs.python.org (Steven K. Wong)
Date: Mon, 11 Jan 2010 20:56:31 +0000
Subject: [issue7448] when piping output between subprocesses some fd is left
	open blocking forever
In-Reply-To: <1260119266.95.0.336121928677.issue7448@psf.upfronthosting.co.za>
Message-ID: <1263243391.66.0.680175389489.issue7448@psf.upfronthosting.co.za>


Steven K. Wong <sliderw at hotmail.com> added the comment:

Looks like a duplicate of http://bugs.python.org/issue7213 .

----------
nosy: +steven.k.wong

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

From report at bugs.python.org  Mon Jan 11 21:57:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 20:57:49 +0000
Subject: [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: <1263243469.64.0.114867192263.issue7675@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15830/issue7675_pydoc_v2.diff

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

From report at bugs.python.org  Mon Jan 11 21:58:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 20:58:03 +0000
Subject: [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: <1263243483.22.0.933906634506.issue7675@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15831/issue7675_pydoc_v2.diff

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

From report at bugs.python.org  Mon Jan 11 22:03:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 21:03:42 +0000
Subject: [issue7448] when piping output between subprocesses some fd is left
	open blocking forever
In-Reply-To: <1260119266.95.0.336121928677.issue7448@psf.upfronthosting.co.za>
Message-ID: <1263243822.65.0.497273136955.issue7448@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Popen.subprocess change close_fds default to True

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

From report at bugs.python.org  Mon Jan 11 22:17:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jan 2010 21:17:06 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1263244626.0.0.659472307026.issue1023290@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

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: [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  Mon Jan 11 22:40:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Jan 2010 21:40:20 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1263246020.06.0.982659785633.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It would be nice to upgrade ElementTree for 2.7 and 3.2, at least.

----------
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Jan 11 23:01:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jan 2010 22:01:14 +0000
Subject: [issue1459867] Message.as_string should use "mangle_from_=unixfrom"?
Message-ID: <1263247274.52.0.487326420301.issue1459867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I understand correctly, this is related to issue 1440472.  There the complaint is made that what you get out is not what you put in, since unixfrom defaults to True.  But that's only true for __str__.  As kxroberto points out, in as_string it defaults to False.  Instead, he suggests, it could default to the value of unixfrom set on the Message object, which would make it at least a little bit more likely to preserve format of the message that was fed into it.

----------
nosy: +r.david.murray
stage:  -> test needed
type:  -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Mon Jan 11 23:15:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Jan 2010 22:15:05 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263248105.57.0.801382872208.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Bill, what do you think?

----------
assignee:  -> janssen

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

From report at bugs.python.org  Mon Jan 11 23:20:26 2010
From: report at bugs.python.org (Kirk Vander Meulen)
Date: Mon, 11 Jan 2010 22:20:26 +0000
Subject: [issue4961] Inconsistent/wrong result of askyesno function in
	tkMessageBox
In-Reply-To: <1232098705.28.0.00930049939452.issue4961@psf.upfronthosting.co.za>
Message-ID: <1263248426.76.0.296167544508.issue4961@psf.upfronthosting.co.za>


Kirk Vander Meulen <kvander11 at gmail.com> added the comment:

I've also confirmed this one (by chance).  I'm on ubuntu linux, and I am seeing the problem in both 2.6 and 3.1, both using Tk 8.5.  I don't see the problem on my windows install (Vista, python 2.5, not sure of the Tk version right now).  But I did find a hack around this by explicitly creating and destroying a top level window following the askdirectory() dialog.  Try this snippet on linux/unix, the call to askyesno() returns False always.

import tkFileDialog,tkMessageBox,Tkinter
theDirectory=tkFileDialog.askdirectory()
addDirectory=tkMessageBox.askyesno('a dialog','Add a directory?')
print addDirectory


But the following works fine:

import tkFileDialog,tkMessageBox,Tkinter
toplevel=Tkinter.Tk()
theDirectory=tkFileDialog.askdirectory()
toplevel.destroy()
addDirectory=tkMessageBox.askyesno('a dialog','Add a directory?')
print addDirectory

----------
nosy: +kvander11

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

From report at bugs.python.org  Mon Jan 11 23:36:43 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 11 Jan 2010 22:36:43 +0000
Subject: [issue2333] Backport set and dict comprehensions
In-Reply-To: <1205775453.72.0.387864116054.issue2333@psf.upfronthosting.co.za>
Message-ID: <1263249403.2.0.0538449445298.issue2333@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r77422.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan 11 23:50:49 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 11 Jan 2010 22:50:49 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1263250249.7.0.838605401537.issue2919@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Any comment about the code I posted?

----------

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

From report at bugs.python.org  Tue Jan 12 00:17:54 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 11 Jan 2010 23:17:54 +0000
Subject: [issue1967] Backport dictviews to 2.7
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1263251874.51.0.792137307009.issue1967@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r77428. Thanks for your comments!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 00:24:10 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 11 Jan 2010 23:24:10 +0000
Subject: [issue5372] Distutils inappropriately reuses .o files between
	extension modules
In-Reply-To: <1235606727.67.0.443849487538.issue5372@psf.upfronthosting.co.za>
Message-ID: <1263252250.65.0.785906797058.issue5372@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r77424, r77425, r77427, r77430

Thanks Collin !

----------
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 01:22:54 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 12 Jan 2010 00:22:54 +0000
Subject: [issue6710] hotshot stats load causes TypeError when multiple files
	are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1263255774.96.0.0733548312738.issue6710@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Tue Jan 12 01:44:35 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Jan 2010 00:44:35 +0000
Subject: [issue7453] HPUX 11.00: socketmodule.c -- error 1588: "AI_PASSIVE"
	undefined.
In-Reply-To: <1260230417.68.0.353556130353.issue7453@psf.upfronthosting.co.za>
Message-ID: <1263257075.16.0.852660155764.issue7453@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

BTW, this bug no longer occurs with Python trunk (or 2.7a2). 

I took at look at the vcs history and couldn't find any changes related to this.

----------

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

From report at bugs.python.org  Tue Jan 12 02:03:59 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Jan 2010 01:03:59 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263258239.34.0.609437362044.issue7658@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Our nightly ActivePython builds broke because of this issue. Note that we still build on 10.4 w/ 10.4u SDK.

I should be able to help verify the new fix - once it is uploaded - in our build machine.

----------
nosy: +srid

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

From report at bugs.python.org  Tue Jan 12 02:23:35 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 12 Jan 2010 01:23:35 +0000
Subject: [issue7382] bytes.__getnewargs__ is broken;
	copy.copy() therefore doesn't work on bytes, and bytes subclasses
	can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1263259415.14.0.184289524558.issue7382@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Committed in r77437. Thanks!

----------

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

From report at bugs.python.org  Tue Jan 12 02:36:19 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 12 Jan 2010 01:36:19 +0000
Subject: [issue7382] bytes.__getnewargs__ is broken;
	copy.copy() therefore doesn't work on bytes, and bytes subclasses
	can't be pickled by default
In-Reply-To: <1258989459.99.0.51081222067.issue7382@psf.upfronthosting.co.za>
Message-ID: <1263260179.1.0.507588168543.issue7382@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
resolution:  -> accepted
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 02:41:34 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Jan 2010 01:41:34 +0000
Subject: [issue3876] multiprocessing does not compile on systems which do not
	define sem_timedwait
In-Reply-To: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za>
Message-ID: <1263260494.83.0.923790478885.issue3876@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Tue Jan 12 03:07:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jan 2010 02:07:17 +0000
Subject: [issue1571841] email module does not complay with RFC 2046: CRLF issue
Message-ID: <1263262037.57.0.0345092390681.issue1571841@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> email.Generators does not separates headers with "\r\n"

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

From report at bugs.python.org  Tue Jan 12 03:39:40 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Jan 2010 02:39:40 +0000
Subject: [issue7454] Solaris SPARC: _multiprocessing.so: symbol sem_timedwait:
	referenced symbol not found
In-Reply-To: <1260231160.36.0.952031207978.issue7454@psf.upfronthosting.co.za>
Message-ID: <1263263980.09.0.702166114898.issue7454@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Found the root cause: it was introduced by a patch (to fix the same issue in the past) committed by us.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 03:54:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 02:54:00 +0000
Subject: [issue2679] email.feedparser regex duplicate
In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za>
Message-ID: <1263264840.58.0.0296123481931.issue2679@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> low
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Tue Jan 12 04:33:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 03:33:56 +0000
Subject: [issue2797] Trunk build issues in DragonFly BSD
In-Reply-To: <1210319505.91.0.659015772153.issue2797@psf.upfronthosting.co.za>
Message-ID: <1263267236.06.0.842088629949.issue2797@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

See #2796

----------
keywords: +needs review
nosy: +brian.curtin
priority:  -> normal
resolution:  -> duplicate
stage:  -> patch review
status: open -> closed
superseder:  -> Build issues in DragonFly BSD
versions: +Python 2.7, Python 3.1, Python 3.2

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

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: [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 04:51:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 03:51:54 +0000
Subject: [issue2796] Build issues in DragonFly BSD
In-Reply-To: <1210316878.4.0.717885872695.issue2796@psf.upfronthosting.co.za>
Message-ID: <1263268314.42.0.4644524239.issue2796@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Added file: http://bugs.python.org/file15832/dragonfly-python-trunk.patch

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

From report at bugs.python.org  Tue Jan 12 05:07:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 04:07:35 +0000
Subject: [issue5827] os.path.normpath doesn't preserve unicode
In-Reply-To: <1240547039.35.0.461990786151.issue5827@psf.upfronthosting.co.za>
Message-ID: <1263269255.74.0.105151041492.issue5827@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77442 (trunk) and r77443 (release26-maint), thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

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: [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 05:37:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 04:37:31 +0000
Subject: [issue7680] pythonw crash while attempting to start() a thread object
In-Reply-To: <1263270141.77.0.964688204265.issue7680@psf.upfronthosting.co.za>
Message-ID: <1263271051.47.0.943000844303.issue7680@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On 2.7a2 on Windows 7 it seems to work, I opened the script with IDLE and did F5, this is the output I got:

Python 2.7a2 (r27a2:77402, Jan 10 2010, 10:04:50) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
hello, dude!
>>>

----------
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Tue Jan 12 09:17:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Jan 2010 08:17:23 +0000
Subject: [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: <1263284243.17.0.934268844473.issue7679@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Works for me.

GNU gettext, which provides libintl, is not included in OS X 10.6.  Chances are your build is being contaminated by packages installed via MacPorts or Fink or in /usr/local.  If you do want to build with it, check config.log in your build directory.  I bet you'll find that it is trying to pick up a 32-bit only version from MacPorts or friends.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Tue Jan 12 09:51:08 2010
From: report at bugs.python.org (sangamesh)
Date: Tue, 12 Jan 2010 08:51:08 +0000
Subject: [issue7657] test_ctypes failure on AIX 5.3
In-Reply-To: <1262934153.84.0.332661974456.issue7657@psf.upfronthosting.co.za>
Message-ID: <1263286268.13.0.50229511271.issue7657@psf.upfronthosting.co.za>


sangamesh <swamy.sangamesh at gmail.com> added the comment:

These failures are specific to xlc compiler
In xlc signed bit fields will be mapped to unsigned by default as opposed to gcc where the value stored in the bit field is of type declared. 
so the the value returned by "func(byref(b), name)"  positive in some cases as it expected to be of type declared.

Their  is an xlc compiler option  "-qbitfields=signed" to make the bit fields of type signed.
After this all the ctypes test cases got passed.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 10:14:18 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 Jan 2010 09:14:18 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263287658.82.0.955878938477.issue7658@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a patch that should fix the build issues with the 10.4 SDK. 

The patch touches configure.in, run autoconf and autoheader after applying  the patch.

I haven't tested the patch yet beyond compilation on 10.6 system without the 10.4 SDK. 

This patch does not attempt to fix the issues Ned has with LIPO_32BIT_FLAGS, I will look into that later today.

----------
keywords: +patch
Added file: http://bugs.python.org/file15833/pythonw-on-10.4.patch

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

From report at bugs.python.org  Tue Jan 12 10:18:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 Jan 2010 09:18:04 +0000
Subject: [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: <1263287884.83.0.668689949296.issue7679@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As Ned noted you probably have installed GNU gettext in /usr/local and that copy does not contain both intel architectures (i386 and x86_64)

There's nothing we can do about that, I have tried to find a way to exclude non-system locations from the default compiler search path but haven't found those yet.

----------
resolution:  -> works for me

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

From report at bugs.python.org  Tue Jan 12 11:41:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Jan 2010 10:41:39 +0000
Subject: [issue7680] pythonw crash while attempting to start() a thread object
In-Reply-To: <1263270141.77.0.964688204265.issue7680@psf.upfronthosting.co.za>
Message-ID: <1263292899.05.0.628531668072.issue7680@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

pythonw.exe has an invalid stdout.
Does the problem reproduce when you call print function directly, without a thread?

----------
nosy: +amaury.forgeotdarc

_______________________________________
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: [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:01:59 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Tue, 12 Jan 2010 12:01:59 +0000
Subject: [issue7681] Incorrect division in [wave.py] causing crash
In-Reply-To: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>
Message-ID: <1263297719.38.0.166556268046.issue7681@psf.upfronthosting.co.za>


Changes by Alf P. Steinbach <alfps at start.no>:


Removed 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:04:03 2010
From: report at bugs.python.org (Alf P. Steinbach)
Date: Tue, 12 Jan 2010 12:04:03 +0000
Subject: [issue7681] Incorrect division in [wave.py] causing crash
In-Reply-To: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>
Message-ID: <1263297843.71.0.783521087193.issue7681@psf.upfronthosting.co.za>


Alf P. Steinbach <alfps at start.no> added the comment:

Sorry, here's correct error message:

Traceback (most recent call last):
  File "C:\Documents and Settings\Alf\sound\error.py", line 8, in <module>
    writer.writeframes( b"\0"*2*4 )
  File "C:\Program Files\cpython\python31\lib\wave.py", line 432, in writeframes
    self.writeframesraw(data)
  File "C:\Program Files\cpython\python31\lib\wave.py", line 416, in writeframesraw
    self._ensure_header_written(len(data))
  File "C:\Program Files\cpython\python31\lib\wave.py", line 459, in _ensure_header_written
    self._write_header(datasize)
  File "C:\Program Files\cpython\python31\lib\wave.py", line 472, in _write_header
    self._sampwidth * 8, 'data'))
struct.error: required argument is not an integer
Exception struct.error: 'required argument is not an integer' in <bound method Wave_write.__del__ of <wave.Wave_write ob
ject at 0x00FE87F0>> ignored

----------
Added file: http://bugs.python.org/file15835/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: [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 13:22:28 2010
From: report at bugs.python.org (Sylvain Defresne)
Date: Tue, 12 Jan 2010 12:22:28 +0000
Subject: [issue7682] Optimisation of if with constant expression
In-Reply-To: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za>
Message-ID: <1263298948.97.0.69072487337.issue7682@psf.upfronthosting.co.za>


Changes by Sylvain Defresne <sdefresne at gmail.com>:


Removed 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 13:23:04 2010
From: report at bugs.python.org (Sylvain Defresne)
Date: Tue, 12 Jan 2010 12:23:04 +0000
Subject: [issue7682] Optimisation of if with constant expression
In-Reply-To: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za>
Message-ID: <1263298984.76.0.259286821382.issue7682@psf.upfronthosting.co.za>


Sylvain Defresne <sdefresne at gmail.com> added the comment:

Correct version of the patch.

----------
Added file: http://bugs.python.org/file15837/compile.diff

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

From report at bugs.python.org  Tue Jan 12 13:45:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 12:45:16 +0000
Subject: [issue7682] Optimisation of if with constant expression
In-Reply-To: <1263298923.43.0.408416060324.issue7682@psf.upfronthosting.co.za>
Message-ID: <1263300316.04.0.758851271787.issue7682@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan 12 16:05:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 15:05:16 +0000
Subject: [issue7681] Incorrect division in [wave.py] causing crash
In-Reply-To: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>
Message-ID: <1263308716.26.0.192644240173.issue7681@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

In your example, the "n_frames" name does not exist, which is causing the problem. In your first comment, "framerate" also did not exist.

I don't know what a proper frame rate value is, but I just put 10 in there and it worked fine. Can you confirm?

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> needs patch
type: crash -> 

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

From report at bugs.python.org  Tue Jan 12 16:33:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Jan 2010 15:33:56 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263310436.23.0.966375763652.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15814/unnamed

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

From report at bugs.python.org  Tue Jan 12 17:09:36 2010
From: report at bugs.python.org (sorin)
Date: Tue, 12 Jan 2010 16:09:36 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1263312576.92.0.115907289207.issue1602@psf.upfronthosting.co.za>


Changes by sorin <sorin.sbarnea at gmail.com>:


----------
nosy: +sorin

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

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


dontbugme <pythonbugsbugmenot at spamavert.com> added the comment:

I did not understand the question.
If you were meaning running a plain print(), then it does work:
#!/usr/bin/env python
print "foo"

IDLE 2.6.4      ==== No Subprocess ====
>>> 
foo
>>> 

Well, as you suggested the problem most probably originates from calling print from within a thread.

This code works as it should:
#!/usr/bin/env python
import threading

class MyThread (threading.Thread):
    def __init__(self):
        threading.Thread.__init__(self)
        
    def run(self):
        f = open('I am alive', 'w')
        f.write('hello, dude!\n')
        f.close()
        
t = MyThread()
t.start()

----------

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

From report at bugs.python.org  Tue Jan 12 17:49:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 16:49:02 +0000
Subject: [issue2679] email.feedparser regex duplicate
In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za>
Message-ID: <1263314942.92.0.388645332813.issue2679@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
type:  -> behavior

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

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: [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 18:53:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 17:53:06 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1263318786.84.0.393643542534.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is basically fine. I'll add a "try .. finally" to the tests.
lekma, do you have a real name that we should add to the ACKS file?

----------

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

From report at bugs.python.org  Tue Jan 12 18:54:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 17:54:48 +0000
Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>
Message-ID: <1263318888.96.0.340769212474.issue2554@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Tue Jan 12 18:55:29 2010
From: report at bugs.python.org (July Tikhonov)
Date: Tue, 12 Jan 2010 17:55:29 +0000
Subject: [issue7683] Wrong link in HTML documentation
In-Reply-To: <1263315700.03.0.719806034204.issue7683@psf.upfronthosting.co.za>
Message-ID: <1263318929.16.0.136238873407.issue7683@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

I don't see anything wrong in this fact..

All "what's new" pages since python 2.0 are keeped in documentation, not only the last one.

----------
nosy: +july

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

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


Francesco Ricciardi <francesco.ricciardi at hp.com> added the comment:

As written in the description, it should point to the "What's New in Python 3.1" page, shouldn't it?

----------

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

From report at bugs.python.org  Tue Jan 12 19:02:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 18:02:03 +0000
Subject: [issue7683] Wrong link in HTML documentation
In-Reply-To: <1263315700.03.0.719806034204.issue7683@psf.upfronthosting.co.za>
Message-ID: <1263319323.8.0.783061244787.issue7683@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The section before the tutorial is the "What's new" and there all the "What's new" pages are listed starting from 3.1 to 2.0 in descending order.
The "What's new in Python 2.0" is therefore the last page in the "What's new" section so the link in the tutorial points there.
It shouldn't point to the 3.1 page, but maybe the "previous/next topic" links shouldn't be visible in the first/last page of the section.

----------
nosy: +ezio.melotti
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 19:05:26 2010
From: report at bugs.python.org (Alex)
Date: Tue, 12 Jan 2010 18:05:26 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263319526.08.0.619494470972.issue6690@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Ugh, I haven't had the time to work on this, just wanted to note that this now applies to 2.7 as well since set literals were backported.

----------

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

From report at bugs.python.org  Tue Jan 12 19:05:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 18:05:52 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1263319552.42.0.97170209947.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at it again, there's the question of accept() behaviour. In the original code, it will call internal_setblocking() on the new fd if the listening socket is non-blocking. In the new code, if SOCK_NONBLOCK is defined it will not call any OS function to set the new fd in non-blocking mode.

Here is what the man page has to say:

       On Linux, the new socket returned by accept() does not inherit file status  flags  such  as
       O_NONBLOCK and O_ASYNC from the listening socket.  This behavior differs from the canonical
       BSD sockets implementation.  Portable programs should not rely on inheritance or non-inher?
       itance  of  file  status  flags  and always explicitly set all required flags on the socket
       returned from accept().

Linux has defined accept4() precisely for this purpose:

       If flags is 0, then accept4() is the same as accept().  The following values can be bitwise
       ORed in flags to obtain different behavior:

       SOCK_NONBLOCK   Set the O_NONBLOCK file status flag  on  the  new  open  file  description.
                       Using this flag saves extra calls to fcntl(2) to achieve the same result.

       SOCK_CLOEXEC    Set  the  close-on-exec  (FD_CLOEXEC) flag on the new file descriptor.  See
                       the description of the O_CLOEXEC flag in open(2) for reasons why  this  may
                       be useful.

----------

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

From report at bugs.python.org  Tue Jan 12 19:07:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 18:07:14 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263319634.57.0.1596613407.issue6690@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Tue Jan 12 19:16:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 18:16:10 +0000
Subject: [issue7669] test_unicode_file fails with non-ascii path
In-Reply-To: <1263147507.26.0.603744082511.issue7669@psf.upfronthosting.co.za>
Message-ID: <1263320170.37.0.237165132806.issue7669@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is because in "path = join(os.getcwd(), path)" os.getcwd() returns a non-ascii byte string and path is unicode, so the cwd is implicitly decoded with the ascii codec in join and the error is raised.
Using getcwdu() when the path is unicode seems to fix the problem:

 def abspath(path):
     """Return an absolute path."""
     if not isabs(path):
-        path = join(os.getcwd(), path)
+        if isinstance(path, unicode):
+            path = join(os.getcwdu(), path)
+        else:
+            path = join(os.getcwd(), path)
     return normpath(path)

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Jan 12 19:24:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 18:24:21 +0000
Subject: [issue6651] Py3k's posixpath.relpath not compatible with
	ntpath.relpath
In-Reply-To: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
Message-ID: <1263320661.28.0.589843322385.issue6651@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Tue Jan 12 19:25:15 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 18:25:15 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1263320715.57.0.303020232517.issue2643@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Added the FlushViewOfFile calls, and an msync call to the close method. Not sure how to explicitly test this, if it's possible. Current tests pass on Windows, I'll need to check *NIX when I have the access later today.

As for justification, from the UnmapViewOfFile docs[1]: "To minimize the risk of data loss in the event of a power failure or a system crash, applications should explicitly flush modified pages using the FlushViewOfFile function."

[1] http://msdn.microsoft.com/en-us/library/aa366882%28VS.85%29.aspx

----------
keywords: +needs review, patch
nosy: +brian.curtin
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15838/issue2643.diff

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

From report at bugs.python.org  Tue Jan 12 19:26:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 18:26:27 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1263320787.55.0.595026205578.issue2643@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15838/issue2643.diff

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

From report at bugs.python.org  Tue Jan 12 19:27:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Jan 2010 18:27:05 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1263320825.35.0.503367761635.issue2643@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

tab/space issue, updated the patch

----------
Added file: http://bugs.python.org/file15839/issue2643.diff

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

From report at bugs.python.org  Tue Jan 12 19:30:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 18:30:59 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263321059.23.0.252281429254.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This also caused the failure in #7669.
I think that the functions in os.path are supposed to return unicode when they get unicode, so I agree that os.getcwdu should be used instead.
I'm not sure about os.path.supports_unicode_filenames though.

----------
assignee:  -> ezio.melotti
stage:  -> test needed
superseder:  -> test_unicode_file fails with non-ascii path

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

From report at bugs.python.org  Tue Jan 12 19:31:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 18:31:59 +0000
Subject: [issue7669] test_unicode_file fails with non-ascii path
In-Reply-To: <1263147507.26.0.603744082511.issue7669@psf.upfronthosting.co.za>
Message-ID: <1263321119.2.0.473045287518.issue7669@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See #3426.

----------
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 19:35:49 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Jan 2010 18:35:49 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1263321349.88.0.394904611544.issue2919@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'll see if I can have a look sometime soon, but my profile experience is practically non-existent so I am not the best person for a code review.

----------

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

From report at bugs.python.org  Tue Jan 12 19:37:40 2010
From: report at bugs.python.org (Steve Steiner)
Date: Tue, 12 Jan 2010 18:37:40 +0000
Subject: [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: <1263321460.8.0.818858689424.issue7679@psf.upfronthosting.co.za>


Steve Steiner <ssteinerX at gmail.com> added the comment:

It's in /usr/local/include alright but I have no idea with which package it came in.  I don't use Fink or Macports.

If it's not going to wreck the build, maybe remove the "Report this to http://bugs.python.org/" instructions?

----------

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

From report at bugs.python.org  Tue Jan 12 19:39:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Jan 2010 18:39:09 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263321549.85.0.14781429736.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Progress report:  I've had a response, and fix, from David Gay for the first 2 bugs (Stefan's original bug and the incorrect subnormal result);  I'm still arguing with him about a 3rd one (not reported here; there's some possibly incorrect code in bigcomp that probably never actually gets called).  I reported the 4th bug (the incorrect rounding for values near 1) to him today.  In the mean time, here's bug number 5, found by eyeballing the bigcomp code until it surrendered.  :-)

>>> 1000000000000000000000000000000000000000e-16
1e+23
>>> 10000000000000000000000000000000000000000e-17
1.0000000000000001e+23

----------

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

From report at bugs.python.org  Tue Jan 12 19:43:14 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Jan 2010 18:43:14 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263321794.43.0.121380595655.issue3426@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

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

From report at bugs.python.org  Tue Jan 12 19:49:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 18:49:31 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1263322171.82.0.936993378906.issue767645@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Jan 12 20:03:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Jan 2010 19:03:13 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1263322993.16.0.759711501365.issue767645@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

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

From report at bugs.python.org  Tue Jan 12 20:36:22 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 12 Jan 2010 19:36:22 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263324982.39.0.611958258849.issue6690@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attaching a probably over-simplistic attempt at this patch, against the py3k branch.

This patch attempts to extend the replacement of
  LOAD_CONST, ...., LOAD_CONST, BUILD_LIST, COMPARE_OP(in)
with
  LOAD_CONST(tuple), COMPAREOP(in)

so that it also replaces:
  LOAD_CONST, ...., LOAD_CONST, BUILD_SET, COMPARE_OP(in)
with 
  LOAD_CONST(tuple), COMPAREOP(in)

i.e. using a tuple, not a frozenset (on the grounds that the "in" conditions should at least still work); caveat: I'm relatively new to the innards of this code.

With this patch:
>>> dis.dis(lambda o: o in {1,2,3})
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 ((1, 2, 3)) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
but:
>>> dis.dis(lambda o: o in {1,2,3,3,2,1})
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 ((1, 2, 3, 3, 2, 1)) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         

Is it worth me working on a rewrite to use a frozenset.

Hope this is helpful
Dave

----------
keywords: +patch
nosy: +dmalcolm
Added file: http://bugs.python.org/file15840/simple-optimization-of-BUILD_SET-COMPARE_OP(IN)-to-LOAD_CONST(tuple)_COMPARE_OP(IN)-py3k.patch

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

From report at bugs.python.org  Tue Jan 12 20:39:15 2010
From: report at bugs.python.org (Alex)
Date: Tue, 12 Jan 2010 19:39:15 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263325155.34.0.374268683555.issue6690@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

David, I think it should use frozen set since doing it this way could actually increase the time the operation takes (which is certainly not our goal!).  Plus marshall.c already handles frozenset, so I don't think it's that much more work.

----------

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

From report at bugs.python.org  Tue Jan 12 20:44:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2010 19:44:05 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1263325445.51.0.897575364202.issue767645@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Maybe os.path.supports_unicode_filenames should be deprecated.
The doc currently says:
"True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if os.listdir() returns Unicode strings for a Unicode argument."

On Linux both the things work, even if the value of os.path.supports_unicode_filenames is still False:
>>> os.path.supports_unicode_filenames
False
>>> open(u'f??b?r', 'w')
<open file u'f\xf2\xf2b\xe0r', mode 'w' at 0x9470778>
>>> os.listdir(u'.')
[u'f\xf2\xf2b\xe0r', ...]
>>> open(u'f??b?r')
<open file u'f\xf2\xf2b\xe0r', mode 'r' at 0x9470778>

----------

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

From report at bugs.python.org  Tue Jan 12 20:57:21 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 12 Jan 2010 19:57:21 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263326241.2.0.265928262441.issue6690@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Alex: good point - thanks!

Attaching updated version of the patch (again, against py3k, likewise, I'm somewhat new to this code, so I may have missed things)

With this:
>>> dis.dis(lambda o: o in {1,2,3})
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 (frozenset({1, 2, 3})) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
>>> dis.dis(lambda o: o in {1,2,3,3,2,1})
  1           0 LOAD_FAST                0 (o) 
              3 LOAD_CONST               3 (frozenset({1, 2, 3})) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE         
and the tuple/list cases are again as in the original comment.

I'm in the process of running the full test suite.

----------
Added file: http://bugs.python.org/file15841/simple-optimization-of-BUILD_SET-COMPARE_OP(IN)-to-LOAD_CONST(frozenset)_COMPARE_OP(IN)-py3k.patch

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

From report at bugs.python.org  Tue Jan 12 20:58:57 2010
From: report at bugs.python.org (Alex)
Date: Tue, 12 Jan 2010 19:58:57 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263326337.67.0.451260796605.issue6690@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

The patch looks more or less right to me (but I'm far from an expert).  It needs tests in the peephole tests though.

----------

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

From report at bugs.python.org  Tue Jan 12 21:16:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jan 2010 20:16:46 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1263327406.96.0.27697411532.issue767645@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In addition, whether or not true unicode filenames are supported really depends, at least on Linux, on the *filesystem*, not on the OS (for some definition of support).  In other words, I think os.path.supports_unicode_filenames is an API design that is broken and should probably be dropped.

----------
nosy: +r.david.murray

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

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: [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 21:49:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Jan 2010 20:49:07 +0000
Subject: [issue7684] decimal.py: infinity coefficients in tuples
In-Reply-To: <1263327517.52.0.041459928833.issue7684@psf.upfronthosting.co.za>
Message-ID: <1263329347.27.0.812475791563.issue7684@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Tue Jan 12 22:10:22 2010
From: report at bugs.python.org (Adam Jackson)
Date: Tue, 12 Jan 2010 21:10:22 +0000
Subject: [issue7647] Add statvfs flags to the posix module
In-Reply-To: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>
Message-ID: <1263330622.99.0.801055452375.issue7647@psf.upfronthosting.co.za>


Adam Jackson <ajax at redhat.com> added the comment:

None of the other symbolic constants in 'posix' have documentation.  Perhaps they should, but the patch is at least doing the same as what's already done.

----------

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

From report at bugs.python.org  Tue Jan 12 22:14:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Jan 2010 21:14:56 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1263330896.99.0.346111015308.issue767645@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Additionally it filters out test_pep277 on some platforms.

But seemingly, it is not needed anymore with this patch.

----------
nosy: +flox
resolution: later -> 
Added file: http://bugs.python.org/file15842/issue767645_test_pep277.py

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

From report at bugs.python.org  Tue Jan 12 22:34:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 21:34:35 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263332075.82.0.258603714937.issue7610@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some comments:
* you should probably write `n = sys.maxsize` instead of `n = 1 << 31 - 1`
* ZipExtFile.read() should support `n=None` as a synonym to `n=-1` (read everything)
* `bytes` as a variable name isn't very good since it's the built-in name for bytestrings in py3k
* in ZipExtFile.read(), it seems you have removed the adjustment for encrypted files (see `adjust read size for encrypted files since the first 12 bytes [etc.]`)
* is there a situation where the decompressor might return less bytes than expected? (after all compression doesn't /always/ compress, in unfavourable chunks of data it might actually expand things a bit)

----------

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

From report at bugs.python.org  Tue Jan 12 22:35:27 2010
From: report at bugs.python.org (Joe Amenta)
Date: Tue, 12 Jan 2010 21:35:27 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1263332127.03.0.890465940549.issue767645@psf.upfronthosting.co.za>


Joe Amenta <amentajo at msu.edu> added the comment:

If it is decided to keep supports_unicode_filenames, here is a patch for test_os.py that verifies the value of supports_unicode_filenames against the following line from the documentation:
"True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if os.listdir() returns Unicode strings for a Unicode argument."

----------
keywords: +patch
nosy: +joe.amenta
Added file: http://bugs.python.org/file15843/test_supports_unicode_filenames.patch

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

From report at bugs.python.org  Tue Jan 12 22:58:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jan 2010 21:58:29 +0000
Subject: [issue1693546] email.Message set_param rfc2231 encoding incorrect
Message-ID: <1263333509.01.0.789725788967.issue1693546@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  The RFC text says:

   Note that quotes around parameter values are part of the value
   syntax; they are NOT part of the value itself.  Furthermore, it is
   explicitly permitted to have a mixture of quoted and unquoted
   continuation fields.

So this looks more like a bug in the RFC to me.

----------
nosy: +r.david.murray
status: open -> pending

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

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: [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  Tue Jan 12 23:06:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 22:06:22 +0000
Subject: [issue7654] [patch] Enable additional bytes and memoryview tests.
In-Reply-To: <1262900856.17.0.385951173483.issue7654@psf.upfronthosting.co.za>
Message-ID: <1263333981.99.0.670229987327.issue7654@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r77448 and r77449, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 12 23:11:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 22:11:00 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1263334260.82.0.992933047665.issue2643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A test could explicitly close a dirtied mmaped file and then open() it to check that everything was written, no?

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Jan 12 23:12:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jan 2010 22:12:17 +0000
Subject: [issue1721862] email.FeedParser.BufferedSubFile improperly handles
	"\r\n"
Message-ID: <1263334337.18.0.960320169506.issue1721862@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This seems to be a duplicate of issue 1555570, which has a simpler patch.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> email parser incorrectly breaks headers with a CRLF at 8192

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

From report at bugs.python.org  Tue Jan 12 23:13:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jan 2010 22:13:37 +0000
Subject: [issue1555570] email parser incorrectly breaks headers with a CRLF at
	8192
Message-ID: <1263334417.94.0.651003734856.issue1555570@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 1721862, which has a different test and patch.  This one seems simpler.

----------
nosy: +r.david.murray
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Tue Jan 12 23:25:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Jan 2010 22:25:15 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263335115.12.0.642798986235.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed the crash that Stefan originally reported in r77450.  That revision also removes the 'possibly incorrect code in bigcomp that probably never actually gets called'.

----------

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

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


Alf P. Steinbach <alfps at start.no> added the comment:

No, sorry, the bugs in [wave.py] have nothing to do with a name IN A COMMENT in the trivial code to exercise the bugs.

To reproduce the crash, just run the supplied code with Python 3.1.1 in Windows XP.

The cause of the crash is, as I pointed out, use of Python 2.x "/" division instead of Python 3.x "//" division. The author of [wave.py] had fixed that in some places. But he/she forgot two places.


Cheers & hth.,

- Alf

----------

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

From report at bugs.python.org  Tue Jan 12 23:33:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jan 2010 22:33:20 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263335600.34.0.427748411044.issue7544@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Running the tests in debug mode gives the following error:

test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... Fatal Python error: Invalid thread state for this thread
[21851 refs]
FAIL
[snip]

======================================================================
FAIL: test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/debug/Lib/test/test_threading.py", line 476, in test_3_join_in_forked_from_thread
    self._run_and_join(script)
  File "/home/antoine/cpython/debug/Lib/test/test_threading.py", line 412, in _run_and_join
    self.assertEqual(data, "end of main\nend of thread\n")
AssertionError: 'end of main\n' != 'end of main\nend of thread\n'

----------------------------------------------------------------------
Ran 78 tests in 3.739s

----------

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

From report at bugs.python.org  Tue Jan 12 23:56:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Jan 2010 22:56:53 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263337013.64.0.129178523013.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Second bug fixed in r77451 (trunk), using a fix from David Gay, modified slightly for correctness.

----------

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

From report at bugs.python.org  Tue Jan 12 23:59:45 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 12 Jan 2010 22:59:45 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263337185.91.0.0590724001482.issue6690@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks for looking at the patch.

Attached is an updated version (again against py3k) which adds tests to Lib/test/test_peepholer.py, for both the new folding away of BUILD_SET, and for the pre-existing folding of BUILD_LIST (which didn't seem to have tests).

Hopefully these look good.  One possible worry I had with them is with the string comparison against repr(various frozensets) for the disassembly of the bytecode: the new tests thus assume that the ordering of the repr of a frozenset is constant.  Is this a reasonable assumption, or should the choice of test items be changed to ones with more robust ordering in their repr() string?

----------
Added file: http://bugs.python.org/file15845/simple-optimization-of-BUILD_SET-COMPARE_OP(IN)-to-LOAD_CONST(frozenset)_COMPARE_OP(IN)-with-tests-py3k.patch

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

From report at bugs.python.org  Wed Jan 13 00:09:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Jan 2010 23:09:42 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263337782.44.0.306448698369.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged fixes so far, and a couple of other cleanups, to py3k in r77452, and release31-maint in r77453.

----------

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

From report at bugs.python.org  Wed Jan 13 01:19:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 00:19:45 +0000
Subject: [issue7681] Incorrect division in [wave.py]
In-Reply-To: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>
Message-ID: <1263341985.83.0.0296198523172.issue7681@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

There is no crash, but I see what you are saying now.
Patch to correct the two divisions and a test similar to your example.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
title: Incorrect division in [wave.py] causing crash -> Incorrect division in [wave.py]
type:  -> behavior
Added file: http://bugs.python.org/file15846/issue7681.diff

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

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: [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 01:31:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 00:31:15 +0000
Subject: [issue7685] minor typo in re docs
In-Reply-To: <1263333789.06.0.194197176787.issue7685@psf.upfronthosting.co.za>
Message-ID: <1263342675.06.0.844693567896.issue7685@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77455 (trunk), r77456 (release26-maint), r77457 (py3k) and r77458 (release31-maint), thanks!

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jan 13 01:42:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 00:42:39 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1263343359.83.0.216893523694.issue5178@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Wed Jan 13 01:46:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 00:46:37 +0000
Subject: [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: <1263343597.45.0.295103361628.issue7686@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Wed Jan 13 01:52:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 00:52:42 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263343962.02.0.503931754247.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a patch that uses os.getcwdu() instead of os.getcwd() when the arg of abspath is unicode (with tests).

It also include an helper context manager in test_support used to create temp dirs and set them as cwd (this will be committed separately) and two helper methods (assertUnicode and assertStr) that will probably be useful when I (or someone else) will add more tests with unicode strings for the other functions.

----------
keywords: +needs review, patch
nosy:  -flox
stage: test needed -> patch review
Added file: http://bugs.python.org/file15847/issue3426.diff

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

From report at bugs.python.org  Wed Jan 13 01:53:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 00:53:32 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263344012.35.0.82431299956.issue3426@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +flox

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

From report at bugs.python.org  Wed Jan 13 02:34:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 01:34:33 +0000
Subject: [issue3636] Managing dual 2.x and 3.0 installations on Windows
In-Reply-To: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>
Message-ID: <1263346473.54.0.810315231604.issue3636@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This won't solve the problem of dual installations, but it'll leave things how you were expecting... There is an option in the installer on the customize page for "Register Extensions". Choosing to not install that item will keep the installer from modifying the path and file association.

I think we could probably have a message on the installer to say that the "Register Extensions" feature would be overwriting your previous settings if it finds settings of a previous version.

----------
components: +Installation -Documentation
nosy: +brian.curtin
priority:  -> normal
stage:  -> needs patch
superseder:  -> PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
type:  -> behavior
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Wed Jan 13 02:37:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 01:37:09 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1263346629.78.0.390839578234.issue2375@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> needs patch
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Wed Jan 13 02:45:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2010 01:45:23 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263347123.16.0.661832935415.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Running the tests in debug mode gives the following error:
> ... Fatal Python error: Invalid thread state for this thread

I tried all Lib/test/test_thread*py, but not in debug mode :-/

The problem is here: PyThreadState_New() -> _PyGILState_NoteThreadState() -> PyThread_set_key_value() -> find_key() and find_key() calls PyThread_get_thread_ident(), but the ident is not the right ident :-/

PyThreadState_New() should not call _PyGILState_NoteThreadState(), it should be done _in_ the thread.

I wrote a new patch fixing the unit test. PyThreadState_New() is part of the public API, so I can't change its prototype. And _PyGILState_NoteThreadState() is a private function (use the "static" keyword). Because of that, I introduced two new functions:

 - PyThreadState_Prealloc(): like PyThreadState_New() but for thread preallocation, can be called outside the new state (from another thread)

 - PyThreadState_Init(): have to be called in the new thread to finish the thread state initialization, only required for state created by PyThreadState_Prealloc() (not for PyThreadState_New())

I tried all Lib/test/test_thread*.py tests in debug mode and all test now pass ;-)

----------
Added file: http://bugs.python.org/file15848/thread_prealloc_pystate-2.patch

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

From report at bugs.python.org  Wed Jan 13 02:49:39 2010
From: report at bugs.python.org (Jeremy Kloth)
Date: Wed, 13 Jan 2010 01:49:39 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1263347379.2.0.256810617572.issue4870@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

I have developed a patch that adds the ability to disable SSLv2, SSlv3 and TLSv1 when using the SSLv23 method. It changes Modules/_ssl.c, Lib/ssl.py and Doc/library/ssl.rst.

----------
keywords: +patch
nosy: +jeremy.kloth
Added file: http://bugs.python.org/file15849/issue4870.diff

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

From report at bugs.python.org  Wed Jan 13 02:53:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 01:53:19 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263347599.1.0.102200575621.issue3426@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You could use assertIsInstance(s, unicode, '%r is not unicode' % s) in the tests instead of your assertTrue.

I think the rest of it looks good. Works for me.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Wed Jan 13 02:56:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 01:56:20 +0000
Subject: [issue4870] ssl module is missing SSL_OP_NO_SSLv2
In-Reply-To: <1231351904.48.0.546979538917.issue4870@psf.upfronthosting.co.za>
Message-ID: <1263347780.63.0.547500566126.issue4870@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan 13 02:58:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 01:58:56 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1263347936.89.0.120014296738.issue2694@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7 -Python 2.5

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

From report at bugs.python.org  Wed Jan 13 03:01:54 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:01:54 +0000
Subject: [issue444582] Finding programs in PATH, addition to os
Message-ID: <1263348114.77.0.847496433179.issue444582@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage: test needed -> patch review

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

From report at bugs.python.org  Wed Jan 13 03:03:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:03:33 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1263348213.14.0.858230081517.issue5115@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan 13 03:04:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:04:36 +0000
Subject: [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1263348276.39.0.417374762122.issue7579@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Wed Jan 13 03:05:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:05:27 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1263348327.16.0.234449061822.issue4772@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Wed Jan 13 03:05:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:05:59 +0000
Subject: [issue7306] Patch - skip winsound tests if no default sound is
	configured
In-Reply-To: <1257953885.18.0.603136766884.issue7306@psf.upfronthosting.co.za>
Message-ID: <1263348359.09.0.465590473057.issue7306@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan 13 03:07:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:07:00 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1263348420.24.0.630974314753.issue7347@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Wed Jan 13 03:08:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:08:03 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1263348483.51.0.842161266343.issue4722@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Jan 13 03:08:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:08:33 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1263348513.63.0.642257577848.issue7301@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan 13 03:09:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:09:07 +0000
Subject: [issue5774] _winreg.OpenKey() is documented with keyword arguments,
	but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1263348547.86.0.471339066833.issue5774@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Wed Jan 13 03:54:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:54:40 +0000
Subject: [issue5774] _winreg.OpenKey() is documented with keyword arguments,
	but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1263351280.48.0.185401308667.issue5774@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15262/issue5774_20091104_v1.patch

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

From report at bugs.python.org  Wed Jan 13 03:56:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 02:56:08 +0000
Subject: [issue5774] _winreg.OpenKey() is documented with keyword arguments,
	but doesn't take them
In-Reply-To: <1239908773.0.0.157202779439.issue5774@psf.upfronthosting.co.za>
Message-ID: <1263351368.05.0.844373325025.issue5774@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
Added file: http://bugs.python.org/file15850/issue5774.patch

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

From report at bugs.python.org  Wed Jan 13 04:00:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 03:00:26 +0000
Subject: [issue5116] expose _CrtSetReportMode via the msvcrt module
In-Reply-To: <1233384774.63.0.198719185318.issue5116@psf.upfronthosting.co.za>
Message-ID: <1263351626.11.0.48326895223.issue5116@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +26backport -needs review, patch, patch
stage:  -> needs patch
versions:  -Python 3.0, Python 3.1

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

From report at bugs.python.org  Wed Jan 13 04:01:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 03:01:08 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1263351668.64.0.320187934325.issue7588@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> needs patch

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

From report at bugs.python.org  Wed Jan 13 04:01:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 03:01:39 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1263351699.79.0.513164955118.issue1222585@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan 13 04:26:35 2010
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 13 Jan 2010 03:26:35 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263353195.14.0.756046339956.issue7672@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Martin, I'm thinking that the module object has a __del__ method, and we could un-register the callbacks there.  But I don't know if that method would ever get called.  How does the act of "unloading a library" interact with the initialized Python interpreter?

----------

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

From report at bugs.python.org  Wed Jan 13 04:31:13 2010
From: report at bugs.python.org (Sean Soria)
Date: Wed, 13 Jan 2010 03:31:13 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263353473.68.0.962375413688.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

Simply unloading the callbacks wouldn't be wise. Callbacks are necessary for proper thread safety with libcrypto (man pages says random crashing could occur without them). So setting them to NULL could cause random crashing which is even worse than what's there now. Restoring the existing callbacks is one option. It's also not thread safe to be chaing the callbacks all the time. Is it critical that Python install its own callbacks over whatever the app has provided?

----------

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

From report at bugs.python.org  Wed Jan 13 04:50:29 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Jan 2010 03:50:29 +0000
Subject: [issue7681] Incorrect division in [wave.py]
In-Reply-To: <1263297683.02.0.967810713174.issue7681@psf.upfronthosting.co.za>
Message-ID: <1263354629.5.0.976154312455.issue7681@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Applied in r77459.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 05:33:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 04:33:48 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263357228.68.0.0675119918575.issue2846@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here tadek's patch updated for trunk, with a test added to it. 

I feel like this should be documented somewhere, but Doc/Library/gzip.rst doesn't feel right. Maybe it just needs a mention in the "What's new" or something?

----------
assignee:  -> brian.curtin
keywords: +needs review
nosy: +brian.curtin
priority:  -> normal
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file15851/issue2846.diff

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

From report at bugs.python.org  Wed Jan 13 06:12:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 05:12:48 +0000
Subject: [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: <1263359568.48.0.837997098761.issue7686@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

With 2.7 I can reproduce the issue on Windows 7 (i.e. I get a ValueError).
However I'm not sure how common is to add a 'b' indiscriminately:
1) most of the times the modes are written as strings, and not generated automatically;
2) even if generated, checking if there's a 'b' is as easy as doing "if 'b' not in mode: mode = mode + 'b'".

For consistency both Windows and Linux should have the same behavior, and if the extra 'b' is not so common I think it's better if both raise an error.

----------
components: +Interpreter Core, Windows
nosy: +ezio.melotti
stage: needs patch -> test needed

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

From report at bugs.python.org  Wed Jan 13 06:13:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 05:13:44 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263359624.92.0.57572448098.issue2846@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15851/issue2846.diff

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

From report at bugs.python.org  Wed Jan 13 06:14:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 05:14:57 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263359697.37.0.697173102898.issue2846@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Updated patch with some documentation

----------
Added file: http://bugs.python.org/file15852/issue2846.diff

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

From report at bugs.python.org  Wed Jan 13 06:22:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 05:22:47 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1263360167.39.0.766607411868.issue7588@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Wed Jan 13 06:27:02 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Jan 2010 05:27:02 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263360422.46.0.925444951111.issue7658@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks, Ronald.  The patch looks good. I've got a patch in progress for the LIPO flags part: looks like the key is 'ppc' for DEPLOYMENT_TARGET <= 10.4 and 'ppc7400' for DEPLOYMENT_TARGET >= 10.5 for either gcc-4.0 or -4.2.  I'll test the two together on the various platforms tomorrow.

----------

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

From report at bugs.python.org  Wed Jan 13 06:42:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 05:42:30 +0000
Subject: [issue2758] arg 2 of PyErr_SetFromErrnoWithFilename should be const
In-Reply-To: <1209922929.05.0.442409778711.issue2758@psf.upfronthosting.co.za>
Message-ID: <1263361350.27.0.324306868618.issue2758@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This is already fixed in trunk and the various 3.x branches.

----------
nosy: +brian.curtin
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 06:46:40 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 13 Jan 2010 05:46:40 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263361600.09.0.0124139507559.issue7658@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Ronald, with your patch I see this on 10.4 (Xcode 2.5):

[...]
lipo -extract ppc7400 -extract i386 -output /Users/apy/rrun/build/activepython-DEV/build/pyhg_trunk-macosx-hgtip27-rrun/image/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32 pythonw
lipo: -extract ppc7400 specified but fat file: pythonw does not contain that architecture
[...]

----------

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

From report at bugs.python.org  Wed Jan 13 06:48:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Jan 2010 05:48:00 +0000
Subject: [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: <1263361680.17.0.667239812036.issue7686@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

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

From report at bugs.python.org  Wed Jan 13 06:57:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Jan 2010 05:57:15 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263362235.86.0.754843793014.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Bill: unloading the shared probably means he does dlclose() (after having done dlopen initially). Furthermore, it probably means he does that on libpythonxy.so. I'm a bit puzzled that it also affects _ssl.so (unless he dlcloses that as well) - Python, on its own, will never dlclose any library.

In any case, calling dlclose to unload a shared library has no effect on Python whatsoever. No callback is triggered, and no interpreter code gets executed in that process.

----------

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

From report at bugs.python.org  Wed Jan 13 07:03:26 2010
From: report at bugs.python.org (Sean Soria)
Date: Wed, 13 Jan 2010 06:03:26 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263362606.71.0.820503940848.issue7672@psf.upfronthosting.co.za>


Sean Soria <bugs.python at seansoria.com> added the comment:

You are correct, dlclose is called on libpythonXY.so and all .so modules loaded by it.

----------

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

From report at bugs.python.org  Wed Jan 13 07:06:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Jan 2010 06:06:18 +0000
Subject: [issue7672] _ssl module causes segfault
In-Reply-To: <1263156723.76.0.110794213005.issue7672@psf.upfronthosting.co.za>
Message-ID: <1263362778.09.0.482047611476.issue7672@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As for the module's __del__: that is already implemented in moduleobject.c:module_dealloc. It doesn't give the module implementation a hook to execute custom code. In Py3k, you can implemenent the m_free hook of the PyModuleDef.

----------

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

From report at bugs.python.org  Wed Jan 13 08:11:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 07:11:26 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1263366686.96.0.969097311316.issue6837@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This can be reconsidered now that the DeprecationWarnings are silenced by default (see #7319).

----------
nosy: +ezio.melotti
priority:  -> normal
resolution: wont fix -> 
status: closed -> open

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

From report at bugs.python.org  Wed Jan 13 08:13:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 07:13:23 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263366803.0.0.380874569006.issue2846@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There is no need to write:

       try:
           [...]
       except IOError as err:
           self.fail(err)

Just let the exception be raised and produce an error.

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Jan 13 08:24:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 07:24:17 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1263367457.14.0.963390683416.issue4772@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"makesockaddr" shouldn't be mentioned in the exception message, since it's just an internal helper function.

----------
nosy: +pitrou

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

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: [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:34:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 07:34:01 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1263368041.1.0.404573120915.issue6058@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority:  -> high
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan 13 08:47:01 2010
From: report at bugs.python.org (Frank Millman)
Date: Wed, 13 Jan 2010 07:47:01 +0000
Subject: [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 09:09:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 08:09:57 +0000
Subject: [issue7622] [patch] improve unicode methods: split() rsplit() and
	replace()
In-Reply-To: <1262538585.9.0.444437883838.issue7622@psf.upfronthosting.co.za>
Message-ID: <1263370197.97.0.80943987121.issue7622@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r77461 (trunk), r77462 (py3k). Thank you very much!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 09:11:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 08:11:07 +0000
Subject: [issue7607] stringlib fastsearch could be improved on 64-bit builds
In-Reply-To: <1262211799.19.0.0827970391862.issue7607@psf.upfronthosting.co.za>
Message-ID: <1263370267.91.0.96357684111.issue7607@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 09:18:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 08:18:39 +0000
Subject: [issue7494] _lsprof (cProfile): Profiler.clear() keeps references to
	detroyed nodes
In-Reply-To: <1260731142.01.0.0589092375643.issue7494@psf.upfronthosting.co.za>
Message-ID: <1263370719.65.0.524582011537.issue7494@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Wed Jan 13 09:19:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 08:19:43 +0000
Subject: [issue7688] TypeError: __name__ must be set to a string object
In-Reply-To: <1263368820.05.0.872831790778.issue7688@psf.upfronthosting.co.za>
Message-ID: <1263370783.21.0.606657860358.issue7688@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jnoller
nosy: +jnoller
priority:  -> normal
stage:  -> needs patch
type: crash -> behavior
versions: +Python 2.7

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

From report at bugs.python.org  Wed Jan 13 09:32:50 2010
From: report at bugs.python.org (lekma)
Date: Wed, 13 Jan 2010 08:32:50 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1263371570.6.0.184435661325.issue7523@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

> lekma, do you have a real name that we should add to the ACKS file?
no, lekma is fine (that's a nick I carry since childhood)

> Looking at it again, there's the question of accept() behaviour. [...]
Sorry for not having seen that earlier and thanks for pointing it out to me.
Unfortunately, I don't think there is a portable solution. We could restrict the patch to linux 2.6.28 and above (there is already an awful lot of ifdefs in this file).
If you think that's the way to go, I can rework the patch, otherwise I think it's better to close the issue (maybe reopen when bsds catch up, if ever).
Ideas?

----------

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

From report at bugs.python.org  Wed Jan 13 09:33:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Jan 2010 08:33:22 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263371602.22.0.311470757138.issue7658@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

@Sridhar: that's the part that's not fixed yet. We'll have a patch for that shortly.

----------

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

From report at bugs.python.org  Wed Jan 13 10:30:52 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 13 Jan 2010 09:30:52 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263375052.03.0.531142373651.issue7658@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned and Sridhar: IMO we need a configure test to detect which argument should be used to extract ppc code (ppc or ppc7400).

----------

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

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: [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 10:51:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 09:51:22 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1263376282.47.0.0764960161712.issue7671@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It triggers some Windows buildbot failures.

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

----------

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

From report at bugs.python.org  Wed Jan 13 11:07:59 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 13 Jan 2010 10:07:59 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263377279.85.0.707210747097.issue5683@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

You can fix it if you are dumping to a file, however if you are calling dumps() you are kind of screwed if dumping large objects.  There's no place to flush the buffer.

I have a fix to Unladen Swallow's cPickle module.  I'm run it by them before submitting it here.

----------

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

From report at bugs.python.org  Wed Jan 13 11:10:57 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Jan 2010 10:10:57 +0000
Subject: [issue5516] equality not symmetric for subclasses of datetime.date
	and datetime.datetime
In-Reply-To: <1237423886.27.0.985547007127.issue5516@psf.upfronthosting.co.za>
Message-ID: <1263377457.26.0.160025922433.issue5516@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

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

From report at bugs.python.org  Wed Jan 13 11:13:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 10:13:15 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263377595.37.0.106859445549.issue5683@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Do we need an intermediate buffer at all when called from dumps()? How about allocating the buffer as a PyStringObject, so that it can be used directly for the result in that case?
(IIRC there's a handy _PyString_Resize function)

----------

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

From report at bugs.python.org  Wed Jan 13 11:20:53 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Jan 2010 10:20:53 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1263378053.54.0.679615843035.issue5178@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Building a collection of issues I want to take a look at for 2.7

----------
assignee:  -> ncoghlan
versions: +Python 3.2 -Python 3.1

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

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: [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 13:06:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 12:06:39 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263384399.35.0.619713005148.issue7661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've merged the first patch. The other one is a bit more controversial because it modifies a file from the original libffi. Besides, "configure" is auto-generated so you should modify configure.ac instead.

----------

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

From report at bugs.python.org  Wed Jan 13 13:06:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 12:06:44 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263384404.63.0.238343511744.issue7661@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15816/issue7661_ctypes_path.diff

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

From report at bugs.python.org  Wed Jan 13 13:21:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Jan 2010 12:21:03 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1263385263.28.0.871603472383.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've not had any success tracking the cause of this failure down, and no longer have the resources to do so.  It does appear that curses itself is broken on FreeBSD:  it's not just a problem with the tests.

Adding Andrew Kuchling to the nosy in case he has any ideas what's wrong here.

Since the test_curses crash is currently aborting the test run, and so preventing us from getting feedback from the other tests on the FreeBSD buildbots, I propose that test_curses be skipped with a "the curses module is broken on FreeBSD" message.

----------
assignee:  -> mark.dickinson
nosy: +akuchling
priority:  -> normal
title: test_curses crash on FreeBSD buildbots -> curses crash on FreeBSD

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

From report at bugs.python.org  Wed Jan 13 13:41:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Jan 2010 12:41:46 +0000
Subject: [issue1266] segfault in curses when calling redrawwin() before
	refresh()
In-Reply-To: <1192126484.51.0.25368750134.issue1266@psf.upfronthosting.co.za>
Message-ID: <1263386506.58.0.231165404531.issue1266@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I wonder whether issue 7384 (test_curses crash on FreeBSD) is related to this.  There does seem to be some sort of readline interaction going on in that issue.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Jan 13 13:48:43 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 13 Jan 2010 12:48:43 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263386923.47.0.33160058355.issue5683@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Perhaps.  Let's take it one step at a time though.  If I change your
large pickle example to use dumps() instead of dump() in an unsullied
Python2.5 I get a MemoryError.  In general, I think you have to be
careful using dumps().  Any attempt to solve that problem will likely
be independent of the Unladen Swallow patches.

----------

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

From report at bugs.python.org  Wed Jan 13 13:52:17 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 13 Jan 2010 12:52:17 +0000
Subject: [issue5683] Speed up cPickle's pickling generally
In-Reply-To: <1238803338.21.0.932870288543.issue5683@psf.upfronthosting.co.za>
Message-ID: <1263387137.84.0.516147412115.issue5683@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Oh, BTW, the proposed fix is in Rietveld: http://codereview.appspot.com/189051

----------

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

From report at bugs.python.org  Wed Jan 13 13:58:22 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 13 Jan 2010 12:58:22 +0000
Subject: [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: <1263387502.24.0.356063393935.issue7686@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

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

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: [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 14:45:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2010 13:45:09 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263390309.85.0.0981299030537.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another problem with my patch! If initsite() calls PyGILState_Ensure(): assert(autoInterpreterState) fails because autoInterpreterState is NULL.

_PyGILState_Init() have to be called before initsite(). I don't know where it should be called exactly. Why not just after the PyThreadState_New() (in Py_InitializeEx())?

----------

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

From report at bugs.python.org  Wed Jan 13 14:47:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2010 13:47:43 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263390463.95.0.348076442878.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If initsite() calls PyGILState_Ensure() (...)

Note: I was using gdb to track a bug on a debug build (--with-pydebug). I used "pyo" macro which calls _PyObject_Dump(), and _PyObject_Dump() calls PyGILState_Ensure() => assertion error.

----------

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

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: [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:24 2010
From: report at bugs.python.org (Peter Bienstman)
Date: Wed, 13 Jan 2010 14:08:24 +0000
Subject: [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 15:10:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Jan 2010 14:10:15 +0000
Subject: [issue7692] Pointless comparision of unsigned integer with zero
In-Reply-To: <1263391285.46.0.0470280640961.issue7692@psf.upfronthosting.co.za>
Message-ID: <1263391815.93.0.0576248420025.issue7692@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report.

This was already fixed for the trunk in r76740 (and merged to py3k in r76741);  it doesn't particularly seem worth backporting the fix to the maintenance branches, since there's no real bug here.

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 15:17:04 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Jan 2010 14:17:04 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1263392224.96.0.941327247372.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

As a first step in unifying test_decimal.py and test_cdecimal.py I
would like to patch test_decimal.py in trunk and py3k. This is to
minimize differences between py3k and py3k-cdecimal.

(1) Remove test that Decimal(x) generates a copy.

(2) Add test case to formatting test.

(3) Extend threading test.

(4) Use Emax of 425000000 instead of 999999999 where possible.
    (The 32-bit version of cdecimal has the official limit of
    425000000, even though 999999999 works in almost all cases.)


If I get an OK for the two patches, I can commit them to py3k and
trunk. If you don't want to apply (1), I'll make new patches.

----------
keywords: +patch
Added file: http://bugs.python.org/file15854/py3k_help_unify.diff

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

From report at bugs.python.org  Wed Jan 13 15:17:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Jan 2010 14:17:29 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1263392249.19.0.851090117112.issue7652@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file15855/trunk_help_unify.diff

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

From report at bugs.python.org  Wed Jan 13 15:21:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 14:21:49 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263392509.08.0.880629300623.issue2846@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15852/issue2846.diff

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

From report at bugs.python.org  Wed Jan 13 15:23:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Jan 2010 14:23:00 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263392580.18.0.9740250383.issue2846@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks for taking a look! Patch updated with that try/except removed.

----------
Added file: http://bugs.python.org/file15856/issue2846.diff

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

From report at bugs.python.org  Wed Jan 13 15:42:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 14:42:18 +0000
Subject: [issue2846] Gzip cannot handle zero-padded output + patch
In-Reply-To: <1210716983.8.0.306490627236.issue2846@psf.upfronthosting.co.za>
Message-ID: <1263393738.16.0.754781518333.issue2846@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Brian. I've committed the patch into trunk and py3k. I haven't backported it to 2.6 and 3.1, since it's more a new feature than a bug fix.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 15:59:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jan 2010 14:59:51 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1263394791.12.0.0859615471603.issue7384@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Given your diagnosis so far, +1 on the skip.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Jan 13 16:04:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jan 2010 15:04:02 +0000
Subject: [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: <1263395042.84.0.534623295002.issue7625@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in trunk (r77475) and py3k (r77476).
Thank you.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jan 13 16:18:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jan 2010 15:18:54 +0000
Subject: [issue1571841] email module does not complay with RFC 2046: CRLF issue
Message-ID: <1263395934.25.0.675094352316.issue1571841@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 16:20:12 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 15:20:12 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1263396012.76.0.812601584021.issue2375@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Setting up specific environments for each Python version is outside the scope of Python.

This is something the user needs to handle using a virtualenv setup, an env-setup shell script or similar approach.

----------
nosy: +lemburg
resolution:  -> rejected
status: open -> closed

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

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: [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 18:15:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jan 2010 17:15:52 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1263402952.06.0.240441806765.issue2375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I disagree with the closing of this bug on the following grounds: currently, and for the foreseeable future, there will be two python commands on many systems, 'python' and 'python3'.  This is unlike the superficially similar situation with different versions of the 2 line.

I think this issue should be discussed on python-dev before being closed, and will post a pointer there.

----------
nosy: +r.david.murray
status: closed -> open

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

From report at bugs.python.org  Wed Jan 13 18:30:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 17:30:54 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1263402952.06.0.240441806765.issue2375@psf.upfronthosting.co.za>
Message-ID: <4B4E034B.3000806@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> I disagree with the closing of this bug on the following grounds: currently, and for the foreseeable future, there will be two python commands on many systems, 'python' and 'python3'.  This is unlike the superficially similar situation with different versions of the 2 line.
> 
> I think this issue should be discussed on python-dev before being closed, and will post a pointer there.

You can easily have python3 implemented as shell script setting up
PYTHONPATH to whatever your particular Python installation uses.

Python itself does not install as python3, so this is not a configuration
supported by Python anyway.

Also note that it's easy to write a sitecustomize.py which takes
care of whatever platform specific side-by-side installation
you want to support with an OS or distribution.

----------

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

From report at bugs.python.org  Wed Jan 13 18:46:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jan 2010 17:46:41 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1263404801.42.0.242176119703.issue2375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, it does:

rdmurray at maestro:~/python/py3k>ls -l ../ptest/p3/bin total 7328
-rwxr-xr-x 1 rdmurray rdmurray     131 Dec 20 12:22 2to3
-rwxr-xr-x 1 rdmurray rdmurray     119 Dec 20 12:22 idle3
-rwxr-xr-x 1 rdmurray rdmurray     104 Dec 20 12:22 pydoc3
-rwxr-xr-x 2 rdmurray rdmurray 3736249 Jan 13 12:43 python3
lrwxrwxrwx 1 rdmurray rdmurray      16 Jan 13 12:44 python3-config -> python3.2-config
-rwxr-xr-x 2 rdmurray rdmurray 3736249 Jan 13 12:43 python3.2
-rwxr-xr-x 1 rdmurray rdmurray    1421 Jan 13 12:44 python3.2-config

That's a straight 'make install' from my svn checkout of the py3k trunk.

----------

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

From report at bugs.python.org  Wed Jan 13 18:48:18 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 13 Jan 2010 17:48:18 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1263404898.79.0.17473929139.issue2375@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
>
> You can easily have python3 implemented as shell script setting up
> PYTHONPATH to whatever your particular Python installation uses.

yes, and you need to write a python shell script, which resets that
variable in case you're starting a python 2 script from your python3
shell script.

----------

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

From report at bugs.python.org  Wed Jan 13 18:57:30 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 13 Jan 2010 17:57:30 +0000
Subject: [issue6769] in xmlrpclib.py: NameError: global name 'HTTPSConnection'
	is not defined
In-Reply-To: <1251066013.49.0.537044412879.issue6769@psf.upfronthosting.co.za>
Message-ID: <1263405450.38.0.902991016395.issue6769@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 19:18:50 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 18:18:50 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1263404801.42.0.242176119703.issue2375@psf.upfronthosting.co.za>
Message-ID: <4B4E0E87.9020802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Yes, it does:
> 
> rdmurray at maestro:~/python/py3k>ls -l ../ptest/p3/bin total 7328
> -rwxr-xr-x 1 rdmurray rdmurray     131 Dec 20 12:22 2to3
> -rwxr-xr-x 1 rdmurray rdmurray     119 Dec 20 12:22 idle3
> -rwxr-xr-x 1 rdmurray rdmurray     104 Dec 20 12:22 pydoc3
> -rwxr-xr-x 2 rdmurray rdmurray 3736249 Jan 13 12:43 python3
> lrwxrwxrwx 1 rdmurray rdmurray      16 Jan 13 12:44 python3-config -> python3.2-config
> -rwxr-xr-x 2 rdmurray rdmurray 3736249 Jan 13 12:43 python3.2
> -rwxr-xr-x 1 rdmurray rdmurray    1421 Jan 13 12:44 python3.2-config
> 
> That's a straight 'make install' from my svn checkout of the py3k trunk.

Sorry, forgot about that change. The name of the binaries is changed
during installation - after running 'make' you get a 'python' binary.

I wonder whether anyone has ever tried building Python on AIX.
Renaming binaries after linking is a bad idea on AIX, since the
linker then sometimes fails to resolve symbols.

I'm still -1 on the change.

People setting up PYTHONPATH will know what they are doing and also
know which Python version they are going to use with the customized
setting and after the transition from Python 2 to 3 we'd be stuck
with user environment setups using PYTHON3PATH instead of PYTHONPATH,
so removing PYTHON3PATH again won't be easily possible.

Besides, if you change PYTHONPATH, you'd also have to change
PYTHONHOME, PYTHONSTARTUP, and all the other flags to use
the 'PYTHON3' prefix.

----------

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

From report at bugs.python.org  Wed Jan 13 19:47:14 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2010 18:47:14 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1263408434.81.0.928165189625.issue6837@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> release blocker

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

From report at bugs.python.org  Wed Jan 13 19:49:49 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2010 18:49:49 +0000
Subject: [issue7690] Wrong PEP number in importlib module manual page
In-Reply-To: <1263379711.7.0.204631557384.issue7690@psf.upfronthosting.co.za>
Message-ID: <1263408589.94.0.942761489849.issue7690@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: georg.brandl -> brett.cannon
nosy: +brett.cannon

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

From report at bugs.python.org  Wed Jan 13 20:15:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 19:15:19 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1263410119.9.0.470447161219.issue6058@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I created two scripts for exporting the IronPython findings and checking them in CPython.

These are the results:

Checking code Page 28591 against encoding 'iso-8859-1' using file 'iso-8859-1.map'

0 errors

Checking code Page 28592 against encoding 'iso-8859-2' using file 'iso-8859-2.map'

0 errors

Checking code Page 28593 against encoding 'iso-8859-3' using file 'iso-8859-3.map'

0 errors

Checking code Page 28594 against encoding 'iso-8859-4' using file 'iso-8859-4.map'

0 errors

Checking code Page 28595 against encoding 'iso-8859-5' using file 'iso-8859-5.map'

0 errors

Checking code Page 1201 against encoding 'utf-16-be' using file 'utf-16-be.map'

2048 errors

Checking code Page 1200 against encoding 'utf-16-le' using file 'utf-16-le.map'

2048 errors

Checking code Page 65000 against encoding 'utf-7' using file 'utf-7.map'

21 errors

Checking code Page 65001 against encoding 'utf-8' using file 'utf-8.map'

2048 errors

Result:

We can add aliases for the various ISO mappings, but not for the UTF ones. .NET encodes the surrogates differently than Python's codecs and
it also produces different results for UTF-7 than Python's codec.

----------

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

From report at bugs.python.org  Wed Jan 13 20:15:59 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 19:15:59 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1263410159.68.0.97387361975.issue6058@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


Added file: http://bugs.python.org/file15858/export-encodings.py

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

From report at bugs.python.org  Wed Jan 13 20:16:09 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 19:16:09 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1263410169.07.0.0765187544099.issue6058@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


Added file: http://bugs.python.org/file15859/check-encodings.py

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

From report at bugs.python.org  Wed Jan 13 20:18:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 13 Jan 2010 19:18:28 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1263410308.72.0.244710954664.issue6058@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

What we could do is add new codecs based on the .NET tables for cp65000 et al.

However, before doing this, I'd like to know where these code page settings can occur and what exact names are used for them. If they only appear in .NET and IronPython, I don't think it's worth adding extra codecs for the MS UTF variants.

----------

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

From report at bugs.python.org  Wed Jan 13 20:26:17 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2010 19:26:17 +0000
Subject: [issue7690] Wrong PEP number in importlib module manual page
In-Reply-To: <1263379711.7.0.204631557384.issue7690@psf.upfronthosting.co.za>
Message-ID: <1263410777.42.0.385826028385.issue7690@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in r77479 for py3k and r77480 for 3.1. Thanks, Francesco!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Jan 13 20:28:35 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 13 Jan 2010 19:28:35 +0000
Subject: [issue1634034] Show "expected" token on syntax error
Message-ID: <1263410915.53.0.335463011366.issue1634034@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm attaching a new version of the patch, based on Oliver's (from 3 years ago).  This patch is against the py3k branch.

I've introduced a new table of (const) strings: _PyParser_TokenDescs, giving descriptions of each token type, so that you get e.g. "')'" rather than "RPAR"

The patch of pythonrun.c is unchanged other than using the description table, rather than the name table.

I've patched the expected results for the doctests in test_genexps and test_syntax.py so that these files pass: this gives the code the beginnings of a test suite.

The existing patch adds this compiler warning for me (gcc 4.4.2, on Fedora 12):
  Python/pythonrun.c: In function ?err_input?:
  Python/pythonrun.c:1923: warning: embedded ?\0? in format
However I believe that snprintf isn't guaranteed to NUL-terminate the string under all conditions on all platforms, so the '\0' seems a sane failsafe.

How does this look?

I haven't attempted to deal with places where multiple token types are permitted, and it does sometimes simply emit "invalid syntax".

----------
keywords: +patch
nosy: +dmalcolm
Added file: http://bugs.python.org/file15860/syntax-error-hints.patch

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

From report at bugs.python.org  Wed Jan 13 20:45:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 19:45:54 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1263411954.92.0.386832282186.issue3892@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Still occurs, on 2010-01-13.

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20trunk/builds/264

----------
nosy: +flox

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

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: [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 21:18:38 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 13 Jan 2010 20:18:38 +0000
Subject: [issue4555] Smelly exports
In-Reply-To: <1228526950.62.0.716618083363.issue4555@psf.upfronthosting.co.za>
Message-ID: <1263413918.72.0.813773584792.issue4555@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Re: msg #77350:
> I propose to simply filter out init[_a-z]+ from the set of "bad" 
> symbols.

I'm attaching a patch (to trunk) to Makefile.pre.in which filters out such symbols.

Relevant part of output of "make smelly" on my svn build with this patch:
nm -p libpython2.7.a | \
		sed -n "/ [TDB] /s/.* //p" | grep -v "^_*Py" | \
		grep -v -E "^init[_a-z]+" | sort -u; \

_add_one_to_index_C
_add_one_to_index_F
asdl_int_seq_new
asdl_seq_new

----------
keywords: +patch
nosy: +dmalcolm
Added file: http://bugs.python.org/file15861/fix-make-smelly-on-trunk.patch

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

From report at bugs.python.org  Wed Jan 13 21:25:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 20:25:32 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1263414332.82.0.618133092047.issue7385@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

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

From report at bugs.python.org  Wed Jan 13 22:27:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2010 21:27:50 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263418070.38.0.607017031846.issue7693@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type: crash -> behavior
versions: +Python 2.7

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

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: [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 22:38:55 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 13 Jan 2010 21:38:55 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263418735.03.0.683581618609.issue7693@psf.upfronthosting.co.za>


Changes by Lars Gust?bel <lars at gustaebel.de>:


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

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

From report at bugs.python.org  Wed Jan 13 22:57:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2010 21:57:14 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263419834.43.0.683443922275.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file15862/sre_py_decref.patch

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

From report at bugs.python.org  Wed Jan 13 22:57:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2010 21:57:30 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263419850.59.0.699163408258.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file15863/thread_py_decref.patch

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

From report at bugs.python.org  Wed Jan 13 22:58:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jan 2010 21:58:25 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263419905.26.0.433894207773.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is still open, it's still possible to crash Python in debug mode. I updated patches for the _sre and thread modules.

----------

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

From report at bugs.python.org  Wed Jan 13 23:35:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jan 2010 22:35:10 +0000
Subject: [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  Wed Jan 13 23:37:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Jan 2010 22:37:34 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263422254.88.0.555820142934.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just so I don't forget, there are a couple more places in the dtoa.c that look suspicious and need to be checked;  I haven't tried to generate failures for them yet.  Since we're up to bug 5, I'll number these 6 and 7:

(6) at the end of bigcomp, when applying the round-to-even rule for halfway cases, the lsb of rv is checked.  This looks wrong if bc->scale is nonzero.

(7) In the main strtod correction loop, after computing delta and i, there's a block:

                bc.nd = nd;
                i = -1; /* Discarded digits make delta smaller. */

This logic seems invalid if all the discarded digits are zero.  (This is the same logic error as is causing bug5:  the bigcomp comparison code also assumes incorrectly that digit nd-1 of s0 is nonzero.)

----------

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Actually, it is the documented behaviour.
http://docs.python.org/py3k/library/os.html#file-names-command-line-arguments-and-environment-variables

>>> b'\xe7'.decode('utf-8', 'surrogateescape')
'\udce7'

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

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


Philip Jenvey <pjenvey at underboss.org> added the comment:

Right, this is an intentional change in behavior in Python 3.1, non-decodable characters are now decoded to utf8b (via the surrogateescape error handler). The unicode string returned from getcwd furthermore can be passsed around to other fs functions, they simply encode back to the original bytes via surrogateescape on POSIX

See PEP 383

----------
nosy: +pjenvey

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

From report at bugs.python.org  Thu Jan 14 01:11:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jan 2010 00:11:49 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1263427909.01.0.613179712202.issue7267@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed

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

From report at bugs.python.org  Thu Jan 14 01:12:14 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jan 2010 00:12:14 +0000
Subject: [issue7300] Unicode arguments in str.format()
In-Reply-To: <1257861455.06.0.0846130484851.issue7300@psf.upfronthosting.co.za>
Message-ID: <1263427934.13.0.557137810665.issue7300@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

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: [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 01:50:41 2010
From: report at bugs.python.org (Evan Klitzke)
Date: Thu, 14 Jan 2010 00:50:41 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1263430241.66.0.654422938652.issue3445@psf.upfronthosting.co.za>


Evan Klitzke <evan at eklitzke.org> added the comment:

I'm also interested in seeing this fixed. In the current behavior, the following code doesn't work:

<<< start code
from functools import wraps

def magic(func):
	@wraps(func)
	def even_more_magic(*args):
		return func(*args)
	return even_more_magic

class Frob(object):
	@magic
	@classmethod
	def hello(cls):
		print '%r says hello' % (cls,)
>>> end code

It fails because classmethods don't have a __module__ attribute, as commented upon elsewhere in this issue. To fix this, you'd either have to either pass in an `assigned` parameter to the `wraps` function, or swap the order of decorator application (i.e. `classmethod(magic(hello))`).

This seems arbitrary and unnecessarily complex; skipping over a missing __module__ should be just fine. Mixing `functools.wraps` and `classmethod` is a relatively common use case that should be as simple as possible.

I've attached a trivial patch which just ignores missing "assigned" attributes.

----------
keywords: +patch
nosy: +eklitzke
Added file: http://bugs.python.org/file15865/fix.patch

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

From report at bugs.python.org  Thu Jan 14 02:15:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jan 2010 01:15:38 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263431738.72.0.822084287769.issue7693@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

When test.tar is opened, the filename is read as a string, so when os.path.join() is called in self._extract_member(tarinfo, os.path.join(path, tarinfo.name)), path is u'.' and tarinfo.name is '\xea\x80\x80a.ogg'.
tarinfo.name is a byte string, so in os.path.join it is converted implicitly to Unicode using the ascii codec because the path is unicode and since it contains non-ascii chars the error is raised.

----------

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

From report at bugs.python.org  Thu Jan 14 02:16:39 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 14 Jan 2010 01:16:39 +0000
Subject: [issue7698] pystack macro in Misc/gdbinit incorrectly uses
	PyEval_EvalFrame
In-Reply-To: <1263430148.48.0.231391407201.issue7698@psf.upfronthosting.co.za>
Message-ID: <1263431799.39.0.652634009889.issue7698@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Thanks for the heads up.  Should be fixed on trunk (r77484) and py3k
(r77485).

----------
assignee:  -> skip.montanaro
nosy: +skip.montanaro
resolution:  -> fixed
status: open -> closed

_______________________________________
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: [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 03:35:24 2010
From: report at bugs.python.org (Conor Hughes)
Date: Thu, 14 Jan 2010 02:35:24 +0000
Subject: [issue7695] missing termios constants
In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>
Message-ID: <1263436524.58.0.302539180511.issue7695@psf.upfronthosting.co.za>


Conor Hughes <conorh at berkeley.edu> added the comment:

As these aren't POSIX, changing to feature request.

----------
type: behavior -> feature request

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

From report at bugs.python.org  Thu Jan 14 03:41:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 02:41:01 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1263436861.17.0.64754455171.issue7662@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Thu Jan 14 03:43:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 02:43:02 +0000
Subject: [issue2796] Build issues in DragonFly BSD
In-Reply-To: <1210316878.4.0.717885872695.issue2796@psf.upfronthosting.co.za>
Message-ID: <1263436982.57.0.45406047221.issue2796@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan 14 03:55:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jan 2010 02:55:17 +0000
Subject: [issue7699] strptime, strftime documentation
In-Reply-To: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za>
Message-ID: <1263437717.71.0.796520990424.issue7699@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jan 14 03:56:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 02:56:46 +0000
Subject: [issue3035] Removing apparently unwanted functions from Tkinter
In-Reply-To: <1212517969.87.0.228224366447.issue3035@psf.upfronthosting.co.za>
Message-ID: <1263437806.39.0.877362621919.issue3035@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

If this stuff needs to be removed it should probably go through the deprecation process.

----------
keywords: +needs review
nosy: +brian.curtin
priority:  -> low
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2 -Python 3.0

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

From report at bugs.python.org  Thu Jan 14 05:04:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 04:04:02 +0000
Subject: [issue7699] strptime, strftime documentation
In-Reply-To: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za>
Message-ID: <1263441842.84.0.341833762108.issue7699@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Seems reasonable.


Additionally, the block about time.strftime not utilizing date related formats (line 1514 in the patched file) can be removed. It has worked for a long time (forever?).

>>> time.strftime("%Y-%m-%d %H:%M:%S", time.localtime())
'2010-01-13 21:32:52'

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Thu Jan 14 05:06:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 04:06:24 +0000
Subject: [issue7695] missing termios constants
In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za>
Message-ID: <1263441984.8.0.70208712206.issue7695@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.2 -Python 2.5, Python 2.6

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

From report at bugs.python.org  Thu Jan 14 05:58:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jan 2010 04:58:03 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263445083.34.0.802959510404.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I added the fix on ntpath and more tests. I also refactored the tests I added for posixpath.
I don't know what is the situation of os2emxpath and macpath and if they should be fixed too. The code for abspath is currently the same on all 4 the modules but I don't see any easy way to avoid the duplication and move it to genericpath because they call the module-dependent join and normpath.

----------
Added file: http://bugs.python.org/file15867/issue3426-2.diff

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

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


Michael Stephens <me at mikej.st> added the comment:

I think it's referring to:

>>> datetime.time(10, 34, 6).strftime("%Y-%m-%d %H:%M:%S")
'1900-01-01 10:34:06'

and thus still applies. It is wrong about month and day being replaced by '0', however, and I've updated the patch to change that to '1'.

----------
Added file: http://bugs.python.org/file15868/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: [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 11:20:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 10:20:38 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263464438.36.0.91160805583.issue7700@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Interpreter Core
type:  -> behavior

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

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


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Now that the DeprecationWarnings are silenced by default (see #7319) -3 should imply -Wd in order to work.

./python -3 -Wd -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

----------
nosy: +ezio.melotti
priority:  -> high
stage:  -> needs patch

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

From report at bugs.python.org  Thu Jan 14 11:59:02 2010
From: report at bugs.python.org (David Oxley)
Date: Thu, 14 Jan 2010 10:59:02 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1263466742.71.0.191258467206.issue1068268@psf.upfronthosting.co.za>


David Oxley <python at psi.epsilon.org.uk> added the comment:

Another instance of a blocking function within subprocess not being protected against EINTR 

Python 2.6.4, subprocess.py, Popen function, line 1115:
data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB

If a signal arrives while blocked in this read, the EINTR/OSError is passed up to whatever called subprocess.Popen. Retrying the Popen doesn't help because the child process may already have started but the caller has no way to know this nor does the caller have any control over the child process.

===

In the example code, the first subprocess.Popen starts without issue but while in the second Popen call, p1's SIGCHLD is received by the parent. 
p2 is never set, but the second copy of /bin/date starts running anyway.

The "preexec_fn = lambda : time.sleep(2)" in the second Popen is a little contrived but serves to guarantee that the SIGCHLD will break the Popen for the purposes of the demonstration. I have seen this failure mode when using vanilla Popen calls although you have to be lucky/unlucky to see it.

====

This is in python 2.6.4:
> md5sum subprocess.py
2ac8cefe8301eadce87630b230d6fff2  subprocess.py

====

I expect the fix is equivalent to cmiller's trunk-diff-unified.txt

----------
nosy: +mathmodave
Added file: http://bugs.python.org/file15869/bugtest.py

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

From report at bugs.python.org  Thu Jan 14 12:23:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jan 2010 11:23:40 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263468220.86.0.0983953736843.issue7700@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a patch. I'm not sure the approach is correct but it seems to fix at least the problem with "./python -3 -c 'print 1 <> 2, {}.has_key(3)'".

----------
keywords: +patch
nosy: +brett.cannon
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15870/issue7700.diff

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The undocumented "-b" flag behaves correctly.
I would suggest to implement it the same way.

~ $ ./python -b -c "bytearray('') == u''"
-c:1: BytesWarning: Comparsion between bytearray and string

(By the way, this feature is not documented in "--help", and there's a typo in the error message)

----------

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

From report at bugs.python.org  Thu Jan 14 12:36:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jan 2010 11:36:14 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263468974.3.0.825035510456.issue7700@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority: high -> release blocker

_______________________________________
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: [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 13:32:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 12:32:56 +0000
Subject: [issue7701] fix output string length for binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263472376.91.0.856900856571.issue7701@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>>> [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]

How is this the correct estimation? The results are different.

Try the following:

>>> [(2+(bin_len+2)//3*4) for bin_len in xrange(10)]
[2, 6, 6, 6, 10, 10, 10, 14, 14, 14]

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Jan 14 14:15:15 2010
From: report at bugs.python.org (alito)
Date: Thu, 14 Jan 2010 13:15:15 +0000
Subject: [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 14:15:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 13:15:17 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263474917.48.0.840228048221.issue7700@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

A variant, which mimics BytesWarning implementation.

----------
Added file: http://bugs.python.org/file15872/issue7700_variant.diff

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

From report at bugs.python.org  Thu Jan 14 14:17:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Jan 2010 13:17:46 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263475066.8.0.782401282232.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Bug 6 is indeed a bug: an example incorrectly-rounded string is:
        '104308485241983990666713401708072175773165034278685682646111762292409330928739751702404658197872319129036519947435319418387839758990478549477777586673075945844895981012024387992135617064532141489278815239849108105951619997829153633535314849999674266169258928940692239684771590065027025835804863585454872499320500023126142553932654370362024104462255244034053203998964360882487378334860197725139151265590832887433736189468858614521708567646743455601905935595381852723723645799866672558576993978025033590728687206296379801363024094048327273913079612469982585674824156000783167963081616214710691759864332339239688734656548790656486646106983450809073750535624894296242072010195710276073042036425579852459556183541199012652571123898996574563824424330960027873516082763671875e-1075'

It's fixed in r77491.  I'll add tests once the remaining (known) dtoa.c bugs are fixed.

----------

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

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


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> How is this the correct estimation? The results are different.

The estimation have be bigger or equal, but not smaller.

> Try the following:
> >>> [(2+(bin_len+2)//3*4) for bin_len in xrange(10)]
> [2, 6, 6, 6, 10, 10, 10, 14, 14, 14]

Cool, it's not an estimation but the exact result :-) I prefer to leave the resize unchanged. The new patch uses your "estimation" ;-)

----------
Added file: http://bugs.python.org/file15873/binascii_b2a_uu_length-2.patch

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

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: [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 15:19:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 14:19:48 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263478788.67.0.0180854096956.issue7703@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15874/issue7703_binascii_memoryview.diff

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

From report at bugs.python.org  Thu Jan 14 15:20:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 14:20:02 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263478802.29.0.839470436939.issue7703@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15875/issue7703_ctypes_memoryview.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 15:23:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 14:23:35 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263479015.9.0.302117370165.issue7703@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patches attached:
 - partial backport of Modules/binascii.c
 - partial backport of Modules/_ctypes/_ctypes.c (preserving 2.3 compat.)
 - update ctypes tests (buffer -> memoryview)

----------
assignee:  -> theller
components: +ctypes
nosy: +theller
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15876/issue7703_test_ctypes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 15:44:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Jan 2010 14:44:52 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263480292.31.0.859664403808.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Bug 4 fixed in r77492.  This just leaves bugs 5 and 7;  I have a fix for these in the works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Thu Jan 14 15:47:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 14:47:16 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263480436.44.0.149844655492.issue7703@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Does binascii still work with array.array objects? Also, there should be additional tests for compatibility of binascii with memoryview objects.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 15:52:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 14:52:11 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263480731.94.0.940757008723.issue3299@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 16:17:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Jan 2010 15:17:15 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263482235.02.0.933662868364.issue7703@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Additional tests for binascii.

----------
Added file: http://bugs.python.org/file15877/issue7703_test_binascii.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 16:23:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Jan 2010 15:23:16 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263482596.12.0.18544026264.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tests committed in r77493.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Thu Jan 14 16:44:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Jan 2010 15:44:22 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263483862.6.0.689482177111.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixes and tests so far merged to py3k in r77494, release31-maint in r77496.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Thu Jan 14 17:01:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 16:01:56 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263484916.38.0.3894316782.issue7703@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please be careful with the coding style. Stuff like:

+			  if (_PyString_Resize(&rv, 2*out_len) < 0) \
+			    { Py_DECREF(rv); PyBuffer_Release(&pin); return NULL; } \

should be spread out on several lines.
Otherwise, the binascii patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 17:35:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 16:35:39 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263486939.36.0.410363112275.issue7703@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've now committed the binascii patch + tests to trunk, and merged the tests into py3k.

Note: binascii_a2b_hqx() still uses the "t#" argument specifier in py3k as well as in trunk, this would deserve a separate patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 17:35:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 16:35:46 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263486946.05.0.713701799732.issue7703@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15877/issue7703_test_binascii.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 17:35:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 16:35:48 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263486948.88.0.952931979224.issue7703@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15874/issue7703_binascii_memoryview.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:02:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 17:02:28 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263488548.04.0.00271458300198.issue3299@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Victor, your overflow test in the sre patch tests for TypeError, but OverflowError is actually raised:

======================================================================
ERROR: test_dealloc (test.test_re.ReTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/debug/Lib/test/test_re.py", line 711, in test_dealloc
    self.assertRaises(TypeError, _sre.compile, "abc", 0, [long_overflow])
  File "/home/antoine/cpython/debug/Lib/unittest/case.py", line 394, in assertRaises
    callableObj(*args, **kwargs)
OverflowError: regular expression code size limit exceeded

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:09:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 17:09:37 +0000
Subject: [issue7701] fix output string length for binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263488977.33.0.784628498466.issue7701@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch doesn't apply cleanly against trunk (due to today's commits I fear, sorry).
Also, it would be nice to add a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7701>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:10:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:10:25 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263489025.49.0.734953279961.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, your overflow test in the sre patch tests for TypeError, 
> but OverflowError is actually raised: (...)

Oops, fixed.

----------
Added file: http://bugs.python.org/file15878/sre_py_decref-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:10:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:10:34 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263489034.59.0.0944154658834.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file10891/_sre-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:10:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:10:39 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263489039.52.0.791571657109.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15862/sre_py_decref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:25:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:25:41 +0000
Subject: [issue7701] fix output string length for binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263489941.4.0.619899410258.issue7701@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch doesn't apply cleanly against trunk

Because of r77497 (issue #770). No problem, here is the new patch. I'm now using a git-svn repository to keep all my patches. It's much easier to update them to trunk ;-)

> Also, it would be nice to add a test.

done

----------
Added file: http://bugs.python.org/file15879/binascii_b2a_uu_length-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7701>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:25:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:25:44 +0000
Subject: [issue7701] fix output string length for binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263489944.79.0.728665810505.issue7701@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed 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 18:25:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:25:49 +0000
Subject: [issue7701] fix output string length for binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263489949.14.0.933621341357.issue7701@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15873/binascii_b2a_uu_length-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7701>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:33:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:33:02 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263490382.6.0.727462835405.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file15880/_curses_panel_py_decref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:35:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:35:17 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263490517.4.0.874696497596.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update _curses_panel patch. The crash occurs if malloc() fail in insert_lop(). I don't know how to write reliable test for this case. Maybe using http://www.nongnu.org/failmalloc/ library (a little bit overkill, isn't it?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:38:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 17:38:14 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263490694.99.0.943002037993.issue3299@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The sre patch has been committed, thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:38:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 17:38:22 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263490702.72.0.831014057917.issue3299@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15878/sre_py_decref-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:46:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jan 2010 17:46:37 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263491197.99.0.43479686355.issue3299@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't know how to write reliable test for this case. Maybe using
> http://www.nongnu.org/failmalloc/ library (a little bit overkill, isn't > it?).

Yes, it would IMO be overkill.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 18:57:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 17:57:52 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263491872.61.0.0662567996534.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file10892/_curses_panel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 19:46:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 18:46:06 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263494766.79.0.609831450538.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update pyexpat patch. As _curses_panel, the bug is raised on malloc() failure. The patch adds also a dummy test on ExternalEntityParserCreate().

----------
Added file: http://bugs.python.org/file15881/pyexpat_py_decref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 20:03:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Jan 2010 19:03:14 +0000
Subject: [issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH
	for multi-Python environments
In-Reply-To: <1205800495.39.0.697300117462.issue2375@psf.upfronthosting.co.za>
Message-ID: <1263495794.68.0.25700107704.issue2375@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Guido pronounced on this on python-dev, so closing the request again.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2375>
_______________________________________

From report at bugs.python.org  Thu Jan 14 20:44:20 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 14 Jan 2010 19:44:20 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263498260.12.0.192359693373.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I uploaded an update for Python 2.7.

> * you should probably write `n = sys.maxsize` instead of `n = 1 << 31 - 1`

sys.maxsize is 64 bit number on my system but the maximum value accepted by zlib's decompress() seems to be INT_MAX defined in pyport.h which equals the number I used.

> * ZipExtFile.read() should support `n=None` as a synonym to `n=-1` 
> (read everything)

Added

> * `bytes` as a variable name isn't very good since it's the built-in 
> name for bytestrings in py3k

Changed (old habits die hard).

> * in ZipExtFile.read(), it seems you have removed the adjustment for 
> encrypted files (see `adjust read size for encrypted files since the 
> first 12 bytes [etc.]`)

Yes, was moved to the constructor.

> * is there a situation where the decompressor might return less bytes 
> than expected? (after all compression doesn't /always/ compress, in 
> unfavourable chunks of data it might actually expand things a bit)

The documentation of io.BufferedIOBase.read() reads "multiple raw reads may be issued to satisfy the byte count". I understood this language to mean satisfying read size is optional. Isn't it?

----------
Added file: http://bugs.python.org/file15882/zipfile_7610_py27_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 14 21:01:17 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Jan 2010 20:01:17 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263499277.38.0.275042566999.issue7700@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fixed in r77505. I tweaked both patches slightly to minimize the special casing. Thanks for the help, guys!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7700>
_______________________________________

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: [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  Thu Jan 14 21:54:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Jan 2010 20:54:27 +0000
Subject: [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: <1263502467.65.0.981616625728.issue7704@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is not a bug:  Python, like many other computer languages, stores floats in binary.  The values 1.6 and 0.6 aren't exactly representable in the internal format used, so the stored versions of 1.6 and 0.6 are actually just very close approximations to those values.  It just so happens that the approximation for 1.6 is a tiny amount larger than 1.6 (the exact value stored is 1.600000000000000088817841970012523233890533447265625), while the approximation for 0.6 is a tiny amount smaller than 0.6 (the exact value is 0.59999999999999997779553950749686919152736663818359375).

I recommend looking at the appendix to the Python tutorial for more information about floating point:

http://docs.python.org/tutorial/floatingpoint.html

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7704>
_______________________________________

From report at bugs.python.org  Thu Jan 14 22:16:08 2010
From: report at bugs.python.org (Christopher Nelson)
Date: Thu, 14 Jan 2010 21:16:08 +0000
Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in
	<module 'threading'
In-Reply-To: <1201455435.45.0.790953321864.issue1947@psf.upfronthosting.co.za>
Message-ID: <1263503768.35.0.760393490864.issue1947@psf.upfronthosting.co.za>


Christopher Nelson <nadiasvertex at gmail.com> added the comment:

I also experience this problem.  However, I experience it with a version of Python 2.4 that has had http://bugs.python.org/file10154/nondaemon_thread_shutdown.diff applied.  

We have a custom 2.4 build that builds using MS VS 2K5.  We support an application on x86, x64, and ia64, which is why we custom compile.

I get this error everytime when running regretest.py in Lib/test.

----------
nosy: +nadiasvertex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1947>
_______________________________________

From report at bugs.python.org  Thu Jan 14 22:18:28 2010
From: report at bugs.python.org (David D Lowe)
Date: Thu, 14 Jan 2010 21:18:28 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1263503908.97.0.640393726687.issue2504@psf.upfronthosting.co.za>


David D Lowe <daviddlowe.flimm at gmail.com> added the comment:

Same here.

----------
nosy: +Flimm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Thu Jan 14 23:04:46 2010
From: report at bugs.python.org (pedro flores)
Date: Thu, 14 Jan 2010 22:04:46 +0000
Subject: [issue7704] Math calculation problem (1.6-1.0)>0.6, python said TRUE
In-Reply-To: <1263502467.65.0.981616625728.issue7704@psf.upfronthosting.co.za>
Message-ID: <1a6f7efa1001141404v546ac7d5q829a49764c089f6c@mail.gmail.com>


pedro flores <pflores82 at gmail.com> added the comment:

kk, then i cannot use this comparison?, and this not happen
with....8.6-8>0.6 this is false, according to python.

2010/1/14 Mark Dickinson <report at bugs.python.org>

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> This is not a bug:  Python, like many other computer languages, stores
> floats in binary.  The values 1.6 and 0.6 aren't exactly representable in
> the internal format used, so the stored versions of 1.6 and 0.6 are actually
> just very close approximations to those values.  It just so happens that the
> approximation for 1.6 is a tiny amount larger than 1.6 (the exact value
> stored is 1.600000000000000088817841970012523233890533447265625), while the
> approximation for 0.6 is a tiny amount smaller than 0.6 (the exact value is
> 0.59999999999999997779553950749686919152736663818359375).
>
> I recommend looking at the appendix to the Python tutorial for more
> information about floating point:
>
> http://docs.python.org/tutorial/floatingpoint.html
>
> ----------
> nosy: +mark.dickinson
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7704>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15884/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7704>
_______________________________________
-------------- next part --------------
kk, then i cannot use this comparison?, and this not happen with....8.6-8&gt;0.6 this is false, according to python.<br><br><div class="gmail_quote">2010/1/14 Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>
This is not a bug: ??Python, like many other computer languages, stores floats in binary. ??The values 1.6 and 0.6 aren&#39;t exactly representable in the internal format used, so the stored versions of 1.6 and 0.6 are actually just very close approximations to those values. ??It just so happens that the approximation for 1.6 is a tiny amount larger than 1.6 (the exact value stored is 1.600000000000000088817841970012523233890533447265625), while the approximation for 0.6 is a tiny amount smaller than 0.6 (the exact value is 0.59999999999999997779553950749686919152736663818359375).<br>

<br>
I recommend looking at the appendix to the Python tutorial for more information about floating point:<br>
<br>
<a href="http://docs.python.org/tutorial/floatingpoint.html" target="_blank">http://docs.python.org/tutorial/floatingpoint.html</a><br>
<br>
----------<br>
nosy: +mark.dickinson<br>
resolution: ??-&gt; invalid<br>
status: open -&gt; closed<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7704" target="_blank">http://bugs.python.org/issue7704</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Pedro Flores C.<br>Estudiante Memorista de Inform??tica 2009-2010<br>Universidad de Concepci??n, Concepci??n<br>Chile<br>

From report at bugs.python.org  Thu Jan 14 23:09:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 22:09:37 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1263506977.02.0.197315545059.issue1559298@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This has come up recently and Martin's approach seems to work. I updated his patch for trunk, and test_popen passes when I run it with and without a space in the path. 

Russ Gibson's suggestion was already applied to test_popen, so the only code change is to posixmodule.c.

----------
components: +Library (Lib) -Tests
keywords: +needs review
nosy: +brian.curtin
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file15885/issue1559298_trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Thu Jan 14 23:12:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Jan 2010 22:12:05 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1263507125.47.0.427078432626.issue1559298@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a py3k version of the previous patch. os.popen is implemented using subprocess.Popen, so the quoting change was made there.

----------
Added file: http://bugs.python.org/file15886/issue1559298_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Thu Jan 14 23:24:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 22:24:24 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263507864.55.0.956382247271.issue3299@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch for cElementTree:
 * Replace PyObject_Del() by Py_DECREF()
 * Catch element_new_extra() errors
 * parser dealloc: replace Py_DECREF() by Py_XDECREF() because the pointer may be NULL (error in the constructor)
 * set all parser attributes to NULL at the beginning of the constructor to be able to call safetly the destructor
 * element_new(): define tag, text, tail attributes before calling element_new_extra() to be able to call the destructor
 * raise a MemoryError on element_new_extra() failure. element_new() didn't raise any error on element_new_extra() failure. Other functions just forget to catch element_new_extra() error.

----------
Added file: http://bugs.python.org/file15887/celementtree_py_decref.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Thu Jan 14 23:37:42 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 14 Jan 2010 22:37:42 +0000
Subject: [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: <1263508662.41.0.908399474474.issue7704@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

You can use the comparison, provided you understand what it does, and that it does NOT do what you hoped it would do.  Here:

>>> 1.6 - 1.0
0.60000000000000009

That shows quite clearly that subtracting 1 from the binary approximation to 1.6 does not leave exactly 0.6.  If you need that to happen, use the decimal module (which, in return for being slower, emulates decimal floating-point arithmetic).

Your other case (8.6-8.0) does NOT equal (decimal) 0.6 exactly either, but fools you into thinking it's working the way you hope it works because the result is a little /less/ than 0.6:

>>> 8.6 - 8.0
0.59999999999999964

Do read the tutorial appendix Mark invited you to read.  If you don't, you're going to remain hopelessly confused ;-)

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7704>
_______________________________________

From report at bugs.python.org  Thu Jan 14 23:56:41 2010
From: report at bugs.python.org (Naoki INADA)
Date: Thu, 14 Jan 2010 22:56:41 +0000
Subject: [issue1754] WindowsError messages are not properly encoded
In-Reply-To: <1199705072.7.0.841408898872.issue1754@psf.upfronthosting.co.za>
Message-ID: <1263509801.12.0.856291315403.issue1754@psf.upfronthosting.co.za>


Naoki INADA <songofacandy at gmail.com> added the comment:

I think WindowsError's message should be English like other errors.
FormatMessageW() function can take dwLanguageId parameter.
So I think Python should pass `MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US)` to the parameter.

----------
nosy: +naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754>
_______________________________________

From report at bugs.python.org  Fri Jan 15 00:20:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jan 2010 23:20:09 +0000
Subject: [issue3299] Direct calls to PyObject_Del/PyObject_DEL are broken for
	--with-pydebug
In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za>
Message-ID: <1263511209.89.0.305581653682.issue3299@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file10893/pyobject_del.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3299>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:12:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jan 2010 00:12:58 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263514378.77.0.79772800079.issue7544@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file15888/thread_prealloc_pystate-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:13:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jan 2010 00:13:03 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263514383.81.0.62396975897.issue7544@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15805/thread_prealloc_pystate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:13:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jan 2010 00:13:08 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1263514388.04.0.647717311646.issue7544@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15848/thread_prealloc_pystate-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:29:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 00:29:27 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263464421.44.0.487116036695.issue7700@psf.upfronthosting.co.za>
Message-ID: <1263515367.56.0.00437959145527.issue7700@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The committed patch has a C++-style comment. You probably want to fix that.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7700>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:31:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 00:31:40 +0000
Subject: [issue7701] fix output string length for binascii.b2a_uu()
In-Reply-To: <1263470182.49.0.868243378906.issue7701@psf.upfronthosting.co.za>
Message-ID: <1263515500.44.0.311852959179.issue7701@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r77506, r77507, r77508 and r77509. Thank you!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7701>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:39:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 00:39:38 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1263515978.83.0.818898499673.issue7301@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15324/issue7301_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:39:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 00:39:42 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1263515982.69.0.925932676789.issue7301@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15322/issue7301.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Fri Jan 15 01:40:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 00:40:53 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1263516053.19.0.271335265161.issue7301@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

fixed a tab/space issue

----------
Added file: http://bugs.python.org/file15889/issue7301.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7301>
_______________________________________

From report at bugs.python.org  Fri Jan 15 02:32:47 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2010 01:32:47 +0000
Subject: [issue7700] "-3" flag does not work anymore
In-Reply-To: <1263515367.56.0.00437959145527.issue7700@psf.upfronthosting.co.za>
Message-ID: <bbaeab101001141732p22d78108x287a5243db5d47e4@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

Fixed in r77510. Look forward to when we use C99 over C89.

On Thu, Jan 14, 2010 at 16:29, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> The committed patch has a C++-style comment. You probably want to fix that.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7700>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7700>
_______________________________________

From report at bugs.python.org  Fri Jan 15 05:09:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 04:09:46 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263528586.02.0.995949431368.issue3426@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

assertStr and assertUnicode don't exist in test_ntpath so the tests fail on Windows. I copied/pasted the functions over from test_posixpath just to see and test_ntpath passes. Other than that, it looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

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: [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 08:02:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 07:02:26 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263538946.88.0.785428578289.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'll fix the patch. I added Ronald and Andrew to see if they have any opinion about macpath and os2emxpath. The main idea is that abspath should always return unicode if its arg is unicode or str otherwise.

----------
nosy: +aimacintyre, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Fri Jan 15 09:52:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 08:52:21 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1263545541.9.0.901105416318.issue1559298@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It is on Python 2.7a2

>>> os.popen('"C:\\Python27\\python.exe" -c "import sys; print sys.argv" 42').read()
''

>>> os.popen('""C:\\Python27\\python.exe" -c "import sys; print sys.argv" 42"').read()
"['-c', '42']\n"

>>> os.popen3('"C:\\Python27\\python.exe" -c "import sys; print sys.argv" 42')[2].read()
'\'C:\\Python27\\python.exe" -c "import\' est pas reconnu en tant que commande interne ou externe, un programme executable ou un fichier de commandes.\n'

It may be related to the test_popen failure.
Actually, it seems that the outer double quotes are removed before executing the cmdstring:
  C:\Python27\python.exe" -c "import
 ^                                  ^

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Fri Jan 15 11:05:03 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 15 Jan 2010 10:05:03 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263549903.39.0.385433906714.issue7693@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

In the 2.x branch tarfile is not prepared to deal with unicode pathnames at all. This changed in Python 3. The fact that it works anyway (in the majority of cases) to add filenames as unicode objects is pure coincidence - I suppose you have a utf-8 system encoding. On a latin-1 system your script would fail much earlier during the add() call.

Some reading: http://docs.python.org/library/tarfile.html#unicode-issues

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Fri Jan 15 11:31:50 2010
From: report at bugs.python.org (Peter Bienstman)
Date: Fri, 15 Jan 2010 10:31:50 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263551510.42.0.515473092019.issue7693@psf.upfronthosting.co.za>


Peter Bienstman <Peter.Bienstman at UGent.be> added the comment:

So what do suggest then as the best approach if I want to use unicode paths in tar files in Python 2.x in a way that is portable across different systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Fri Jan 15 11:51:24 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 15 Jan 2010 10:51:24 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263552684.53.0.86701699295.issue7693@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

First, use a string pathname for extractall(). Most likely, your script is going to work. Convert all pathnames to strings using sys.getfilesystemencoding() before you add() them. Ensure that all systems you are going to use the archives on have the same filesystem encoding, e.g. utf-8. Pax archives are probably the best choice if you plan to keep the archives for several years. If you simply want to transfer data from one system to the other throwing the archives away afterwards, the format is rather irrelevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Fri Jan 15 12:53:02 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 15 Jan 2010 11:53:02 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263556382.09.0.000591986341243.issue3426@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

abspath is basically dead code in macpath, the module is used to manipulate classic MacOS9-style paths and is no longer used as os.path on any supported platform (it used to be os.path on MacOS9).

BTW. the module itself is not dead, OSX still uses OS9-style paths in a number of older APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Fri Jan 15 12:55:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 11:55:03 +0000
Subject: [issue6352] Compiler warning in unicodeobject.c
In-Reply-To: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>
Message-ID: <1263556503.84.0.407577567491.issue6352@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Interpreter Core
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6352>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:15:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 12:15:17 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1263557717.56.0.0971055028953.issue5905@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, lemburg
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5905>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:16:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 12:16:37 +0000
Subject: [issue5587] vars() no longer has a useful __repr__
In-Reply-To: <1238260121.89.0.108446240417.issue5587@psf.upfronthosting.co.za>
Message-ID: <1263557797.39.0.320213922837.issue5587@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5587>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:22:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 12:22:13 +0000
Subject: [issue5825] Patch to add "remove" method to
	tempfile.NamedTemporaryFile
In-Reply-To: <1240532161.78.0.907773696305.issue5825@psf.upfronthosting.co.za>
Message-ID: <1263558133.96.0.967211712499.issue5825@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5825>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:24:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 12:24:51 +0000
Subject: [issue5684] test_zipfile writes in its test directory
In-Reply-To: <1238833190.77.0.866792563675.issue5684@psf.upfronthosting.co.za>
Message-ID: <1263558291.98.0.763110120618.issue5684@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5684>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:26:20 2010
From: report at bugs.python.org (Peter Bienstman)
Date: Fri, 15 Jan 2010 12:26:20 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263552684.53.0.86701699295.issue7693@psf.upfronthosting.co.za>
Message-ID: <201001151326.19498.Peter.Bienstman@ugent.be>


Peter Bienstman <Peter.Bienstman at UGent.be> added the comment:

On Friday 15 January 2010 11:51:24 am Lars Gust?bel wrote:
> Lars Gust?bel <lars at gustaebel.de> added the comment:
> 
> First, use a string pathname for extractall(). Most likely, your script is
>  going to work. Convert all pathnames to strings using
>  sys.getfilesystemencoding() before you add() them. Ensure that all systems
>  you are going to use the archives on have the same filesystem encoding,
>  e.g. utf-8. 

Unfortunately, that is beyond my control. Am I then totally out of luck? Would 
the implementation of tarfile in 3.0 be useable on 2.6 (perhaps with small 
modifications?)

>  Pax archives are probably the best choice if you plan to keep
>  the archives for several years. If you simply want to transfer data from
>  one system to the other throwing the archives away afterwards, the format
>  is rather irrelevant.

The archives are throw-away, transfer only, but they could be used on any 
system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:26:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jan 2010 12:26:47 +0000
Subject: [issue5609] Create Unit Tests for nturl2path module
In-Reply-To: <1238434174.72.0.622903214477.issue5609@psf.upfronthosting.co.za>
Message-ID: <1263558407.71.0.970141125506.issue5609@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5609>
_______________________________________

From report at bugs.python.org  Fri Jan 15 13:57:23 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Jan 2010 12:57:23 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1263560243.28.0.697614270067.issue5905@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The reason for this is that the strftime() C lib API is used to build localized month names. With your setting, you'll get French Latin-1 month names and those cannot be coerced to UTF-8 due to the accented characters in them.

This works in Python 2.x since PyUnicode_FromString() et al. convert Latin-1 strings to Unicode.

Apparently, this was changed in Python 3.x without looking at the header file or looking at the Python 2.x implementation which mandate Latin-1 as input encoding. Even the Python 3.x header still says that PyUnicode_FromString() will convert from Latin-1 to Unicode.

No idea why time.strptime() even bothers with these month names, though, since neither the format string nor the string being parsed contains literal month names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5905>
_______________________________________

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: [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 14:14:30 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 15 Jan 2010 13:14:30 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263561270.0.0.451273813189.issue7693@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I suppose you do not have a real problem here. I thought your problem was that you want to use unicode pathnames as input and output to tarfile. You don't need that.

You want to transfer an archive from one system to another. You can do that with tarfile already. Python 3.x's tarfile does the same as Python 2.x's tarfile, except that in 3.x *all* strings are unicode strings.

If you have different encodings on these systems, that should not be a problem unless these encodings are not compatible with each other. If you want to use a tar archive created on a utf-8 system on a iso-8859-1 system that is no problem, as long as you use the pax format and all the utf-8 characters used are also valid iso-8859-1 characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Fri Jan 15 14:36:47 2010
From: report at bugs.python.org (Peter Bienstman)
Date: Fri, 15 Jan 2010 13:36:47 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263561270.0.0.451273813189.issue7693@psf.upfronthosting.co.za>
Message-ID: <201001151436.46975.Peter.Bienstman@ugent.be>


Peter Bienstman <Peter.Bienstman at UGent.be> added the comment:

On Friday 15 January 2010 02:14:30 pm Lars Gust?bel wrote:
> Lars Gust?bel <lars at gustaebel.de> added the comment:
> 
> I suppose you do not have a real problem here. I thought your problem was
>  that you want to use unicode pathnames as input and output to tarfile. You
>  don't need that.
> 
> You want to transfer an archive from one system to another. You can do that
>  with tarfile already. Python 3.x's tarfile does the same as Python 2.x's
>  tarfile, except that in 3.x *all* strings are unicode strings.
> 
> If you have different encodings on these systems, that should not be a
>  problem unless these encodings are not compatible with each other. If you
>  want to use a tar archive created on a utf-8 system on a iso-8859-1 system
>  that is no problem, as long as you use the pax format and all the utf-8
>  characters used are also valid iso-8859-1 characters.

I think I *do* have a problem. I want to create a tar archive on one system, 
where the filenames could contain non latin characters. I'm sending this tar 
file over a socket to a different system (with potentially a different encoding), 
where I want to extract it to a directory which name could contain non-latin 
characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Fri Jan 15 15:01:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 14:01:32 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1263564092.92.0.291111537437.issue2775@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Modules "hotshot" and "xmllib" give deprecation warnings. But they are not part of PEP 3108 or PEP 4.

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Fri Jan 15 15:50:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 14:50:39 +0000
Subject: [issue5825] Patch to add "remove" method to
	tempfile.NamedTemporaryFile
In-Reply-To: <1240532161.78.0.907773696305.issue5825@psf.upfronthosting.co.za>
Message-ID: <1263567039.96.0.928315312451.issue5825@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You should use assertFalse in your test, as failIf is deprecated starting in 2.7.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5825>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:04:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 15:04:55 +0000
Subject: [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: <1263567895.74.0.748052424519.issue7705@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7705>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:20:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2010 15:20:41 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263568841.46.0.704041614931.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I was considering downgrading this to 'normal'.  Then I found Bug 8, and it's a biggie:

>>> 10.900000000000000012345678912345678912345
10.0

Now I'm thinking it should be upgraded to release blocker instead.

The cause is in the _Py_strtod block that starts: 'if (nd > STRTOD_DIGLIM) {'...  It truncates the input to 18 digits, and then deletes trailing zeros.  But the code that deletes the zeros is buggy, and passes over the digit '9' just before the point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:28:45 2010
From: report at bugs.python.org (Tim Peters)
Date: Fri, 15 Jan 2010 15:28:45 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263569325.98.0.547744492138.issue7632@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Mark, I agree that last one should be a release blocker -- it's truly dreadful.

BTW, did you guess in advance just how many bugs there could be in this kind of code?  I did ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:32:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2010 15:32:16 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263569536.5.0.843827011716.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Upgrading to release blocker.  It'll almost certainly be fixed before the weekend is out.  (And I will, of course, report it upstream.)

----------
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:40:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 15:40:50 +0000
Subject: [issue5825] Patch to add "remove" method to
	tempfile.NamedTemporaryFile
In-Reply-To: <1240532161.78.0.907773696305.issue5825@psf.upfronthosting.co.za>
Message-ID: <1263570050.8.0.0185243440278.issue5825@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What is the point besides to "reduce the need to import os.unlink", which sounds a bit futile to me?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5825>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:50:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 15:50:00 +0000
Subject: [issue7689] Pickling of classes with a metaclass and copy_reg
In-Reply-To: <1263375134.71.0.434114641669.issue7689@psf.upfronthosting.co.za>
Message-ID: <1263570600.02.0.653139997833.issue7689@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7689>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:50:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 15:50:56 +0000
Subject: [issue1634034] Show "expected" token on syntax error
Message-ID: <1263570656.0.0.945165621108.issue1634034@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1634034>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:53:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 15:53:22 +0000
Subject: [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: <1263570802.67.0.496026156052.issue7691@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
resolution:  -> duplicate
stage: test needed -> 
status: open -> closed
superseder:  -> Windows buildbot occasional DBFileExistsError failures in test_bsddb3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7691>
_______________________________________

From report at bugs.python.org  Fri Jan 15 16:59:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 15:59:09 +0000
Subject: [issue7269] Windows buildbot occasional DBFileExistsError failures in
	test_bsddb3
In-Reply-To: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
Message-ID: <1263571149.74.0.0217401934005.issue7269@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

#7691 marked duplicate of this bug.

I've set the current directory read-only to track this bug.

There's a single TestCase which creates the file in the current directory instead of /tmp. All other bsddb tests use either "get_new_environment_path" or "get_new_database_path".

----------
keywords: +patch
nosy: +flox
stage: needs patch -> patch review
Added file: http://bugs.python.org/file15892/issue7269_bsddb3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7269>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:26:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 16:26:30 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1263572790.35.0.887620053111.issue1559298@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:26:50 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 15 Jan 2010 16:26:50 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263572810.08.0.434207474687.issue1670765@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

Let's get some traction here, please!

Attached is a test case which will demonstrate the issue. It includes the content of test5.eml as a string so that it won't require additional files. It produces both human-readable output and a suitable exit status. Turning it into a unit test should be easy as well.

It doesn't do signature verification, but uses simple string comparison instead. The rationale is that anything changing the string would break the signature as well. That should be enough for unit tests.

Please change stage to "patch review".

----------
Added file: http://bugs.python.org/file15893/issue1670765a.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:29:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 16:29:31 +0000
Subject: [issue7668] test_httpservers fails with non-ascii path
In-Reply-To: <1263147324.56.0.696076411083.issue7668@psf.upfronthosting.co.za>
Message-ID: <1263572971.79.0.772828016766.issue7668@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +buildbot
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7668>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:31:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 16:31:07 +0000
Subject: [issue7667] test_doctest fails with non-ascii path
In-Reply-To: <1263147113.71.0.132140640007.issue7667@psf.upfronthosting.co.za>
Message-ID: <1263573067.3.0.028320154768.issue7667@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +buildbot
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7667>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:33:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 16:33:04 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263573184.92.0.490717293434.issue1670765@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
stage: test needed -> patch review
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

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: [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 17:35:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 16:35:58 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263573358.01.0.244210484129.issue3426@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:38:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 16:38:08 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1263573488.1.0.175602609014.issue5207@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 655194.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:40:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 16:40:31 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263573631.78.0.0693180282394.issue1670765@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Martin, can you provide a true unit test? Lib\email\test\test_email.py has many examples, and something like this would fit in there.

----------
nosy: +brian.curtin
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:49:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 16:49:20 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1263574160.34.0.626033170049.issue5207@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I mean issue 665194.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Fri Jan 15 17:59:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 16:59:03 +0000
Subject: [issue6961] test_distutils failure
In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
Message-ID: <1263574743.35.0.550235196467.issue6961@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

There's still similar failures on 3.1 branch only.
Some buildbots which have reported the error:
  AMD64 Ubuntu
  ia64 Ubuntu
  alpha Debian
  AMD64 Gentoo

http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%203.1/builds/194
http://www.python.org/dev/buildbot/all/builders/ia64%20Ubuntu%203.1/builds/227

test test_distutils failed -- Traceback (most recent call last):
  File "/home/buildbot/slave/py-build/3.1.norwitz-amd64/build/Lib/distutils/tests/test_util.py", line 99, in test_get_platform
    self.assertEquals(get_platform(), 'macosx-10.3-i386')
AssertionError: 'macosx-10.3-x86_64' != 'macosx-10.3-i386'

----------
keywords: +buildbot
nosy: +flox
resolution: invalid -> 
status: closed -> open
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6961>
_______________________________________

From report at bugs.python.org  Fri Jan 15 18:03:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 17:03:12 +0000
Subject: [issue6961] test_distutils failure
In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
Message-ID: <1263574992.72.0.70027470976.issue6961@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

whoops... I missed #7591 which is a report for the same issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6961>
_______________________________________

From report at bugs.python.org  Fri Jan 15 18:05:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 17:05:30 +0000
Subject: [issue7591] test_distutils: test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1263575130.62.0.317519650666.issue7591@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Some buildbots which have reported the error:
  AMD64 Ubuntu
  ia64 Ubuntu
  alpha Debian
  AMD64 Gentoo

----------
nosy: +flox
title: test_get_platform fails on 3.1 -> test_distutils: test_get_platform fails on 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Fri Jan 15 18:20:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 17:20:39 +0000
Subject: [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 18:26:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 17:26:15 +0000
Subject: [issue7707] multiprocess.Queue operations during import can lead to
	deadlocks
In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za>
Message-ID: <1263576375.03.0.98927484143.issue7707@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +brett.cannon, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7707>
_______________________________________

From report at bugs.python.org  Fri Jan 15 18:28:06 2010
From: report at bugs.python.org (Peter Hansen)
Date: Fri, 15 Jan 2010 17:28:06 +0000
Subject: [issue6252] logging midnight rotation
In-Reply-To: <1244622655.82.0.22543923389.issue6252@psf.upfronthosting.co.za>
Message-ID: <1263576486.72.0.985217917073.issue6252@psf.upfronthosting.co.za>


Peter Hansen <peter at engcorp.com> added the comment:

In the NEWS file, this was recorded as fixed using the wrong issue number.  The entry reads "Issue #5262: Fixed bug in next rollover time computation in TimedRotatingFileHandler." rather than "Issue #6252".

----------
nosy: +peter9477

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6252>
_______________________________________

From report at bugs.python.org  Fri Jan 15 18:45:48 2010
From: report at bugs.python.org (Wilfredo Sanchez)
Date: Fri, 15 Jan 2010 17:45:48 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1263577548.72.0.549210688202.issue4111@psf.upfronthosting.co.za>


Changes by Wilfredo Sanchez <wsanchez at wsanchez.net>:


----------
nosy: +wsanchez

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Jan 15 19:11:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 18:11:54 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1263579114.1.0.495831150933.issue3445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should come with an unit test (in Lib/test/test_functools.py).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Fri Jan 15 19:18:33 2010
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Fri, 15 Jan 2010 18:18:33 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1263579513.19.0.263476149428.issue4111@psf.upfronthosting.co.za>


Changes by Glyph Lefkowitz <glyph at divmod.com>:


----------
nosy: +glyph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Jan 15 19:32:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 18:32:33 +0000
Subject: [issue6897] imaplib fails during login
In-Reply-To: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za>
Message-ID: <1263580353.14.0.703539503346.issue6897@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Imap lib implicit conversion from bytes to string
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6897>
_______________________________________

From report at bugs.python.org  Fri Jan 15 19:38:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 18:38:27 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1263498260.12.0.192359693373.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263580770.25822.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The documentation of io.BufferedIOBase.read() reads "multiple raw
> reads may be issued to satisfy the byte count". I understood this
> language to mean satisfying read size is optional. Isn't it?

It's the reverse actually. It means that `BufferedIOBase.read` itself
may (or perhaps should) issue multiple raw reads in order to satisfy the
byte count.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Fri Jan 15 19:44:18 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 15 Jan 2010 18:44:18 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263581058.5.0.737705273731.issue1670765@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

OK, here is a patch providing both two test cases and the fix for current trunk. Will probably hack something for python 3 as well, although there the Message.as_string approach works due to the new headerlength argument defaulting to 0. So there I'd adjust the patch 

I also included a second test e-mail together with two disabled test cases in order to address the whitespace issue I mentioned. Would be nice to have a fix for these as well, but I assume you don't want known to fail test cases without a fix in trunk unless it's really serious, right?

In any case, the fact that there should be at least four tests, maybe more in the future, all dealing with signature preservation, led me to have a class dedicated to them, instead of only adding methods to one of the existing classes. I hope you agree with that decision.

----------
Added file: http://bugs.python.org/file15895/issue1670765_python2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Fri Jan 15 19:46:02 2010
From: report at bugs.python.org (Charles Cazabon)
Date: Fri, 15 Jan 2010 18:46:02 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1263581162.38.0.300449853622.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Ping... two alphas into 2.7.  Have you had a chance to review this functionality?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

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: [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 19:55:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 18:55:45 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1263581745.25.0.0455269176719.issue6963@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Fri Jan 15 20:01:51 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 15 Jan 2010 19:01:51 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263582111.4.0.568008370815.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Is there anything I can do to help this patch making its way to the trunk ?
I guess it'd be better if Python2.7 benefited from it, so that users don't run anymore the risk of relying of this undocumented and non-canonical "truncate" behaviour.

Regards, 
Pascal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 20:05:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 19:05:20 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263582320.34.0.159826282919.issue6939@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15763/Buggy patch - to be forgotten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 20:06:31 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 15 Jan 2010 19:06:31 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1263582391.4.0.966462060649.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm fine with the functionality; I'm going to test it out and look at committing it by mid-week next week. I apologize, I've been pretty maxed out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Fri Jan 15 20:17:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 19:17:13 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263583033.24.0.985262750884.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looking at the patches:
- if you want to remove code, please remove it; don't comment it out
- please don't use C++-style comments (it will break on some compilers, produce warnings on others)
- code lines should generally not be wider than 80 chars (although this is not really a hard rule)
- I don't understand the purpose of "self.seek(0, os.SEEK_CUR)"; shouldn't it be a no-op? If not, please add a comment to explain why.
- you are not decrefinf objects properly when you are done with them (posobj, oldposobj), which will certainly produce memory leaks
- some tests seem to be missing from the 2.7 patch, compared to the 2.6 one
- if you want to test BytesIO and StringIO, tests can be added to Lib/test/test_memoryio.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 20:23:52 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 15 Jan 2010 19:23:52 +0000
Subject: [issue843590] 'macintosh' encoding alias for 'mac_roman'
Message-ID: <1263583432.85.0.705846903571.issue843590@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

Find attached (issue843590_rfc.patch) an implementation of the macintosh encoding as the RFC defines it. I don't suggest its inclusion; I would prefer the alias of this implementation, but either one is better than no 'macintosh' encoding at all. So if you really want that, here it is.

----------
keywords: +patch
Added file: http://bugs.python.org/file15896/issue843590_rfc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue843590>
_______________________________________

From report at bugs.python.org  Fri Jan 15 20:27:06 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 15 Jan 2010 19:27:06 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263583626.53.0.852780949492.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

May be a good idea to clear this up in the documentation.

http://en.wiktionary.org/wiki/may#Verb
"(modal auxiliary verb, defective) To have permission to. Used in granting permission and in questions to make polite requests."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

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: [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  Fri Jan 15 20:36:56 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 15 Jan 2010 19:36:56 +0000
Subject: [issue843590] 'macintosh' encoding alias for 'mac_roman'
Message-ID: <1263584216.28.0.309656506955.issue843590@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

And this patch (issue84359_alias.patch) is the alternative, 'macintosh' as an alias to 'mac_roman' as originally requested, along with a bunch of aliases registered with IANA. I'd prefer this approach over the preceding one, and hope someone will maybe review this for inclusion.

----------
Added file: http://bugs.python.org/file15897/issue843590_alias.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue843590>
_______________________________________

From report at bugs.python.org  Fri Jan 15 21:26:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 20:26:24 +0000
Subject: [issue7710] Inconsistent Exception for int() conversion
In-Reply-To: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>
Message-ID: <1263587184.17.0.101808805133.issue7710@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The null byte gives UnicodeEncodeError for other conversions too.

Python 3:
 int('\0'), float('\0'), complex('\0')

Python 2:
 int(u'\0'), long(u'\0'), float(u'\0'), complex(u'0')


Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character u'\x00' in position 1: invalid decimal Unicode string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7710>
_______________________________________

From report at bugs.python.org  Fri Jan 15 21:28:12 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 15 Jan 2010 20:28:12 +0000
Subject: [issue7710] Inconsistent Exception for int() conversion
In-Reply-To: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>
Message-ID: <1263587292.78.0.345848798498.issue7710@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Loosely related to issue4221.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7710>
_______________________________________

From report at bugs.python.org  Fri Jan 15 21:32:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 20:32:20 +0000
Subject: [issue2927] expose html.parser.unescape
In-Reply-To: <1211262235.18.0.705526453605.issue2927@psf.upfronthosting.co.za>
Message-ID: <1263587540.58.0.67701509557.issue2927@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2927>
_______________________________________

From report at bugs.python.org  Fri Jan 15 21:38:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 20:38:20 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1263587900.92.0.955714754156.issue4221@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Fri Jan 15 21:50:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Jan 2010 20:50:10 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1263588610.1.0.557215100216.issue4221@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Python 3 gives same confusing error:

>>> int(b'\0', 999)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 999: b'\x00'

>>> int(b'x', 999)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: int() arg 2 must be >= 2 and <= 36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Fri Jan 15 21:51:54 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 15 Jan 2010 20:51:54 +0000
Subject: [issue7639] bdist_msi fails on files with long names
In-Reply-To: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>
Message-ID: <1263588714.61.0.352640604854.issue7639@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

I can confirm this issue. It prevents building a IPython msi installer on Python 2.6 for Windows. 

A patch to the Directory.make_short function in msilib\__init__.py is attached. It falls back to generating prefix~pos filenames when a short name is already taken and also generates short names more similar to Windows/NTFS.

----------
keywords: +patch
nosy: +cgohlke
Added file: http://bugs.python.org/file15898/msilib_make_short.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7639>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:05:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 21:05:38 +0000
Subject: [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: <1263589538.47.0.503950824328.issue7709@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are looking for this:

http://docs.python.org/dev/py3k/library/unittest.html#unittest.TestCase.longMessage

I wish it were the default, but at least it exists in 2.7 and 3.x. (It can't be the default for backward compatibility reasons.)

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7709>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:08:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 21:08:30 +0000
Subject: [issue7639] bdist_msi fails on files with long names
In-Reply-To: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>
Message-ID: <1263589710.19.0.476942138856.issue7639@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7639>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:10:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 21:10:21 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263589821.3.0.625891741976.issue1670765@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray
stage: test needed -> patch review
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:10:44 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2010 21:10:44 +0000
Subject: [issue7707] multiprocess.Queue operations during import can lead to
	deadlocks
In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za>
Message-ID: <1263589844.87.0.184973598991.issue7707@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Without looking at the multiprocessing code I am willing to guess that some code in that run() function is launching some code that runs in a thread that is performing an import, deadlocking on the import lock. Jesse, is that what could be happening? If so we should probably add a note to the multiprocessing docs to not do this sort of stuff, ala http://docs.python.org/library/threading.html#importing-in-threaded-code .

----------
assignee:  -> jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7707>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:14:40 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2010 21:14:40 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1263590080.83.0.331758231147.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't know why hotshot was deprecated specifically for Python 3 as that was never directly part of the discussion for PEP 3108. As for xmllib, that is most likely an oversight. Either way they should get added to the relevant PEPs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:18:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jan 2010 21:18:20 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263590300.86.0.593411260675.issue7610@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I do not find the existing phrasing in the IO docs ambiguous, but since it is obviously possible to misinterpret it it would be good to clarify it.  Can you suggest an alternate phrasing that would be clearer?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:20:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Jan 2010 21:20:48 +0000
Subject: [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: <1263590448.53.0.293935664649.issue7709@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7709>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:21:29 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 15 Jan 2010 21:21:29 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263590489.29.0.622751301386.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, I shall fix all this asap.

But it seems the C code for truncate is actually buggy in the current 2.6 _fileio.c, around line 680.
CF code below :

posobj = portable_lseek(fd, posobj, 0); -> don't we lose the reference to the old "posobj" there, doing a memory leak ?

if (PyErr_Occurred()) return NULL; -> same thing, we return Null without caring about the posobj reference which should be non-Null there ??

If I've understood a little reference counting, "portable_lseek" returns a reference that we own and must Py_DECREF, isn't that so ?



--------
	if (posobj == Py_None || posobj == NULL) {
		/* Get the current position. */
                posobj = portable_lseek(fd, NULL, 1);
                if (posobj == NULL)
			return NULL;
        }
        else {
		/* Move to the position to be truncated. */
                posobj = portable_lseek(fd, posobj, 0);
        }

#if defined(HAVE_LARGEFILE_SUPPORT)
	pos = PyLong_AsLongLong(posobj);
#else
	pos = PyLong_AsLong(posobj);
#endif
	if (PyErr_Occurred())
		return NULL;

------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:21:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2010 21:21:39 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263590499.92.0.531099522792.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch for the release blocker.

Eric, would you be interested in double checking the logic for this patch? 

Tim:  No, I have to admit I didn't forsee quite this number of bugs.  :)

----------
title: dtoa.c: oversize b in quorem -> dtoa.c: oversize b in quorem, and a menagerie of other bugs
Added file: http://bugs.python.org/file15899/issue7632_bug8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Fri Jan 15 22:26:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Jan 2010 21:26:42 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263590802.5.0.175304047355.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

issue7632_bug8.patch uploaded to Rietveld:

http://codereview.appspot.com/186168

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:06:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Jan 2010 22:06:16 +0000
Subject: [issue1722] Undocumented urllib functions
In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za>
Message-ID: <1263593176.72.0.505739472879.issue1722@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:09:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 15 Jan 2010 22:09:35 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263593375.89.0.588174932485.issue7632@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It looks correct to me, assuming this comment is correct:

     /* scan back until we hit a nonzero digit.  significant digit 'i'
        is s0[i] if i < nd0, s0[i+1] if i >= nd0. */

I didn't verify the comment itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:15:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 22:15:21 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1263590489.29.0.622751301386.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263593783.25822.12.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> posobj = portable_lseek(fd, posobj, 0); -> don't we lose the reference
> to the old "posobj" there, doing a memory leak ?

It's a bit more subtle.
Here, the first reference to "posobj" that you get is through the
function arguments. You don't own that reference, so must not decref it
when you are done with it. Moreover, if you return that very same
reference, you should incref it first (which your patch doesn't do when
posobj is non-None, and therefore loses a reference, see below).

However, when you get a new "posobj" from portable_lseek() (or most
other C API functions), you own this new reference and therefore must
decref it when you are done with it.

To sum it up and if I'm not mistaken, you must:
- add a Py_INCREF(posobj) when posobj is non-NULL and non-None.
- Py_DECREF the first posobj, as well as oldposobj, in the
Windows-specific path.

If you wanna witness reference counting behaviour, you should build
Python in debug mode (--with-pydebug if under Linux). Right now under
Linux your patch produces the following behaviour:

[39542 refs]
>>> f.truncate()
0L
[39547 refs]
>>> f.truncate()
0L
[39547 refs]
>>> f.truncate(2)
2
[39545 refs]
>>> f.truncate(2)
2
[39544 refs]

As you see, when posobj is non-None, we actually lose a reference
because a Py_INCREF is missing.
If you do this too often the small integer object "2" gets wrongly
destroyed and the interpreter crashes:

... 
[snip]
Erreur de segmentation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:17:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 22:17:39 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263593859.56.0.243466641946.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

He, roundup ate part of the code I pasted. Here it is again:

>>> import io
[39516 refs]
>>> f = io.open("foo", "wb", buffering=0)
[39542 refs]
>>> f.truncate()
0L
[39544 refs]
>>> f.truncate()
0L
[39544 refs]
>>> f.truncate(2)
2
[39543 refs]
>>> f.truncate(2)
2
[39542 refs]
>>> while True: f.truncate(2)
... 
[snip]
Erreur de segmentation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:19:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 22:19:16 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263593956.56.0.442322026943.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, you witness the issue (less clearly though) by running the tests in debug mode, too:

$ ./python -m test.regrtest -v test_io
test_io
test_BufferedIOBase_destructor (test.test_io.CIOTest) ... ok
test_IOBase_destructor (test.test_io.CIOTest) ... ok
test_RawIOBase_destructor (test.test_io.CIOTest) ... ok
test_TextIOBase_destructor (test.test_io.CIOTest) ... ok
test_append_mode_tell (test.test_io.CIOTest) ... ok
test_array_writes (test.test_io.CIOTest) ... ok
test_buffered_file_io (test.test_io.CIOTest) ... ok
test_close_flushes (test.test_io.CIOTest) ... ok
test_closefd (test.test_io.CIOTest) ... ok
test_closefd_attr (test.test_io.CIOTest) ... ok
test_destructor (test.test_io.CIOTest) ... ok
test_garbage_collection (test.test_io.CIOTest) ... ok
test_invalid_operations (test.test_io.CIOTest) ... ok
test_large_file_ops (test.test_io.CIOTest) ... Fatal Python error: Python/ceval.c:4058 object at 0x2572448 has negative ref count -1
Abandon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:41:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jan 2010 22:41:45 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263595305.01.0.536419842471.issue6690@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

No, you can't rely on the repr of a frozenset with multiple items. You should find another way of testing (if you are brave you could match the "frozenset(...)" with a regex and eval() it).

Some comments on the patch:
- there's a line or two in peephole.c which seems to use spaces for indentation; please always use tabs (for this file anyway)
- instead of `self.assertTrue(X in Y)`, you can use `self.assertIn(X, Y)` (and `self.assertNotIn(X, Y)` for the negation)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Fri Jan 15 23:42:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 15 Jan 2010 22:42:13 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263595333.01.0.282584850176.issue7632@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I have a few minor comments posted on Rietveld, but nothing that would keep you from checking this in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 01:13:39 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 16 Jan 2010 00:13:39 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263600819.51.0.110789021745.issue6690@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks for the suggestions.

Attached is a revised version of the patch. 
  - I believe I've fixed all tab/space issues in this version of the patch, though I may have missed some (http://www.python.org/dev/tools/ doesn't recommend an automated way of checking this).
  - I've rewritten the selftests as you suggested, using re and eval
  - I've rewritten the new selftests to use assertIn, assertNotIn

The existing tests don't use assertIn/assertNotIn; I'm working on a patch for that, but I'll file that as a separate bug.

----------
Added file: http://bugs.python.org/file15900/optimize-BUILD_SET-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sat Jan 16 02:44:50 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Jan 2010 01:44:50 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263606290.39.0.712053986502.issue6690@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Nice looking patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sat Jan 16 04:00:04 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 16 Jan 2010 03:00:04 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1263610804.53.0.737510267542.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100116.zip is a new version of the regex module.

I've given up on the breadth-wise matching - it was too difficult finding a pattern structure that would work well for both depth-first and breadth-wise. It probably still needs some tweaks and tidying up, but I thought I might as well release something!

----------
Added file: http://bugs.python.org/file15901/issue2636-20100116.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Jan 16 04:52:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jan 2010 03:52:50 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263613970.98.0.618953315775.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

For consistency I updated all 4 the modules. If the tests pass on both Windows and Mac the patch should be ready to go in.

----------
Added file: http://bugs.python.org/file15902/issue3426-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Sat Jan 16 05:11:32 2010
From: report at bugs.python.org (Evan Klitzke)
Date: Sat, 16 Jan 2010 04:11:32 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1263615092.06.0.815943779902.issue3445@psf.upfronthosting.co.za>


Evan Klitzke <evan at eklitzke.org> added the comment:

New patch included, with a test case.

I had wanted to check the classmethod __module__ thing directly, but that proved to be elusive, since the classmethod gets the __module__ attribute if the module is '__main__', and you can't delete that attribute. My test just tries to assign another attribute which doesn't exist.

I just tried to copy the style of the rest of the module, lmk if there are any problems.

----------
Added file: http://bugs.python.org/file15903/fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sat Jan 16 05:35:51 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 16 Jan 2010 04:35:51 +0000
Subject: [issue5063] python-2.6.spec doesn't build properly
In-Reply-To: <1232939250.95.0.104379121936.issue5063@psf.upfronthosting.co.za>
Message-ID: <1263616551.83.0.0661064284173.issue5063@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Committed to release26-maint as 77514.
Committed to trunk as 77515.
Committed to 3k as 77516.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5063>
_______________________________________

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: [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:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jan 2010 05:42:31 +0000
Subject: [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 06:43:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jan 2010 05:43:03 +0000
Subject: [issue5684] test_zipfile writes in its test directory
In-Reply-To: <1238833190.77.0.866792563675.issue5684@psf.upfronthosting.co.za>
Message-ID: <1263620583.84.0.968915993186.issue5684@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
dependencies: +Add a context manager to change cwd in test.test_support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5684>
_______________________________________

From report at bugs.python.org  Sat Jan 16 06:43:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jan 2010 05:43:38 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263620618.29.0.0579602069421.issue3426@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
dependencies: +Add a context manager to change cwd in test.test_support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Sat Jan 16 10:15:21 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Sat, 16 Jan 2010 09:15:21 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263633321.41.0.458058664822.issue1670765@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

Here is the corresponding path for python3 (py3k branch). It's mostly the same, except for one additional test which ensures header preservation even if the maxheaderlen argument to Message.as_string is greater than 0. It's called test_long_headers_as_string_maxheaderlen.

----------
Added file: http://bugs.python.org/file15905/issue1670765_python3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Sat Jan 16 11:10:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 10:10:59 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263636659.14.0.561643890487.issue7703@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch for the last "t#" format string in binascii module.
And provide additional tests.

PS: I removed this comment. IMHO, it is a wrong assertion:
        "# The hqx test is in test_binhex.py"

----------
Added file: http://bugs.python.org/file15906/issue7703_binascii_a2b_hqx.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 11:46:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 10:46:22 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263638782.31.0.031908266739.issue7703@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think the bytes -> bytearray changes are useful, e.g.:

-        fillers = ""
+        fillers = bytearray()

As for:

+            try:
+                f(empty)
+            except SystemError, err:
+                self.fail("{}({!r}) raises SystemError: {}".format(func, empty, err))
+            except Exception, err:
+                self.fail("{}({!r}) raises {!r}".format(func, empty, err))

The "except SystemError" is pointless, since "except Exception" will catch SystemError anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 11:49:36 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 16 Jan 2010 10:49:36 +0000
Subject: [issue6943] setup.py fails to find headers of system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1263638976.38.0.73999494367.issue6943@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

this patch looks wrong, as it only works with libffi >= 3.0 (the standalone libffi releases, which introduces the pkg-config stuff).

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________

From report at bugs.python.org  Sat Jan 16 12:06:15 2010
From: report at bugs.python.org (sorin)
Date: Sat, 16 Jan 2010 11:06:15 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263639975.09.0.108564108958.issue1578269@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

If you could provide a build I could run the tests on Windows 7 x64. 

This is a very old bug that I would like to see it solved.

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jan 16 12:42:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 11:42:34 +0000
Subject: [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: <1263642154.87.0.0508839370667.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

A patch which provides a context manager and a decorator.
(with ideas from Ezio and Antoine)

Sample usages:

with temp_cwd() as cwd:
  assert cwd == os.getcwd()


@writablecwd
def test_zipfile():
  # do something useful
  print os.path.abspath('.')

----------
nosy: +pitrou
Added file: http://bugs.python.org/file15907/temp_cwd_decorator.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sat Jan 16 12:45:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 11:45:09 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263642309.34.0.552826268125.issue7703@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15906/issue7703_binascii_a2b_hqx.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 12:45:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 11:45:40 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263642340.25.0.783260901969.issue7703@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Changed.

----------
Added file: http://bugs.python.org/file15908/issue7703_binascii_a2b_hqx_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 13:03:42 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 16 Jan 2010 12:03:42 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263643422.35.0.868245830034.issue6939@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file15765/python26_full_truncate_patch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sat Jan 16 13:03:46 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 16 Jan 2010 12:03:46 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263643426.64.0.784585120293.issue6939@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file15766/python27_full_truncate_bugfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sat Jan 16 13:09:59 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 16 Jan 2010 12:09:59 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263643799.71.0.653830079599.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Thanks for the detailed feedback.

According to what you said (and to details found in python docs), the current _fileio.truncate is actually quite buggy -> no reference counting ops were done on posobj, even though it's sometimes retrieved from _portable_seek, and returned or not depending on rare error cases (SetEndOfFile failing etc.).

Here is a patch fixing all that for python2.6, I've tested it manually in debug mode, and against memoryio/io/fileio tests ; hope it will be OK.

As soon as this one is certified, I'll prepare a patch for python2.7

----------
Added file: http://bugs.python.org/file15909/patch26_truncate_pos_refcounts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sat Jan 16 13:14:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 12:14:15 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263644055.03.0.942973156651.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied the bug 8 patch in r77519 (thanks Eric for reviewing!).  For safety, I'll leave this as a release blocker until fixes have been merged to py3k and release31-maint.

I've uploaded a fix for bugs 5 and 7 to Rietveld:

http://codereview.appspot.com/186182

I still don't like the parsing code much:  I'm tempted to pull out the calculation of y and z and do it after the parsing is complete.  It's probably marginally less efficient that way, but it would help make the code clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 14:04:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 13:04:25 +0000
Subject: [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: <1263647065.46.0.267230261119.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sat Jan 16 14:07:42 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 16 Jan 2010 13:07:42 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263647262.5.0.583537272048.issue7693@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

So, use the pax format. It stores the filenames as utf-8 and this way you will be on the safe side.

I hope we both agree that the solution to your particular problem is nothing tarfile.py can provide. So, I am going to close this issue now.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Sat Jan 16 14:11:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 13:11:53 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263647513.15.0.389087802837.issue7703@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15908/issue7703_binascii_a2b_hqx_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 14:13:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Jan 2010 13:13:39 +0000
Subject: [issue6352] Compiler warning in unicodeobject.c
In-Reply-To: <1246161475.84.0.16800767496.issue6352@psf.upfronthosting.co.za>
Message-ID: <1263647619.67.0.215389161518.issue6352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r76197 fixed the warning (Nov 10 2009, 2 months ago).

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6352>
_______________________________________

From report at bugs.python.org  Sat Jan 16 14:14:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 13:14:20 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263647660.38.0.414085560975.issue7703@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Removed no-op str("...") conversions.

----------
Added file: http://bugs.python.org/file15910/issue7703_binascii_a2b_hqx_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 14:25:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 13:25:34 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263648334.78.0.315843026344.issue7661@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Still failing: buildbot "AMD64 Ubuntu wide 2.6"

Revisions r77466 and r77467 need backport.

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7661>
_______________________________________

From report at bugs.python.org  Sat Jan 16 16:00:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Jan 2010 15:00:35 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263654035.89.0.635922480812.issue1670765@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've committed fix and the non-disabled tests to trunk in r77517.  I updated the comments to point to the relevant RFC and note that the problem is not fixed, just mitigated.

I've made a note of the additional tests in my issues list for the email package.  I'm not sure we can fix the whitespace problem in the 2.x email package.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

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: [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 16:36:32 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 16 Jan 2010 15:36:32 +0000
Subject: [issue7711] csv error name incorrect
In-Reply-To: <1263618920.78.0.558103176688.issue7711@psf.upfronthosting.co.za>
Message-ID: <1263656192.34.0.161949230049.issue7711@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

This is to be expected.  The Error Exception is actually defined in the
underlying _csv extension module.  The higher level csv Python module
imports it.  The two are the same object:

>>> import csv, _csv
>>> csv.Error
<class _csv.Error at 0x818517c>
>>> _csv.Error
<class _csv.Error at 0x818517c>
>>> csv.Error is _csv.Error
True

So, continue to use

    try:
       ...
    except csv.Error:
       ...

and ignore the leading underscore.

----------
nosy: +skip.montanaro
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7711>
_______________________________________

From report at bugs.python.org  Sat Jan 16 17:00:59 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Sat, 16 Jan 2010 16:00:59 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263657659.1.0.0879221652245.issue1670765@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

You missed a digit in the test comment:
s/See issue 96843/See issue 968430/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Sat Jan 16 17:25:12 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 16:25:12 +0000
Subject: [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: [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 18:42:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 17:42:46 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263663766.27.0.386827178308.issue7703@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

When the following snippet is taken:

	if (_PyString_Resize(&rv,
			   (bin_data -
			    (unsigned char *)PyString_AS_STRING(rv))) < 0) {
		PyBuffer_Release(&pascii);
		Py_DECREF(rv);
		rv = NULL;
	}

pascii will get released a second time at the end of function. The rest is fine, I'm gonna fix it myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 18:54:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 17:54:39 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263664479.4.0.406008812146.issue6690@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sat Jan 16 18:57:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 17:57:45 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263664665.57.0.747086191958.issue7703@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The a2b_hqx() patch was committed in r77528 (trunk) and r77529 (py3k). Thanks again!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 18:57:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 17:57:49 +0000
Subject: [issue7703] Replace buffer()-->memoryview() in Lib/ctypes/test/
In-Reply-To: <1263478631.19.0.286064580539.issue7703@psf.upfronthosting.co.za>
Message-ID: <1263664669.5.0.487020321214.issue7703@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15910/issue7703_binascii_a2b_hqx_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7703>
_______________________________________

From report at bugs.python.org  Sat Jan 16 18:59:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jan 2010 17:59:07 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263391703.94.0.0768397922167.issue7693@psf.upfronthosting.co.za>
Message-ID: <1263664747.56.0.969112893373.issue7693@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Lars, I think the situation can still be improved. If tarfile works with bytes strings it should accept only bytes strings or unicode strings that can be encoded in ASCII, and encode them as soon as it gets them.
In the problem reported by Peter, he was passing u"." that is a unicode ASCII-only string. Later in the program this string gets mixed with a byte string and this causes an implicit decoding, i.e. it turns the byte strings to unicode (and possibly fails if the filename is non-ASCII). Even if the decoding succeeds, eventually tarfile will have to convert the unicode string to a byte string again.

A better approach would be to encode using the ASCII codec all the unicode strings that are passed.
If the unicode strings are ASCII-only (like the u"." Peter was passing), they can be encoded without problems. When they get mixed with other strings they are all bytes strings so no implicit decoding happens.
If the unicode strings are non-ASCII, the encoding will fail immediately and warn the user that he will have to encode the unicode string before passing it to the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:00:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 18:00:26 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263664826.29.0.585693239711.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've applied a minimal fix for bugs 5 and 7 in r77530 (trunk).  (I wasn't able to produce any strings that trigger bug 7, so it may not technically be a bug.)

I'm continuing to review, comment, and clean up the remainder of the _Py_dg_strtod.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:15:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 18:15:43 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263665743.28.0.409476682825.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixes merged to py3k and release31-maint in r77535 and r77537.

----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:17:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 18:17:39 +0000
Subject: [issue7661] compiling ctypes fails with non-ascii path
In-Reply-To: <1262993097.31.0.894971013662.issue7661@psf.upfronthosting.co.za>
Message-ID: <1263665859.96.0.960653139571.issue7661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've merged the ctypes fix to 2.6. As for 3.1, it doesn't seem to need the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7661>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:24:37 2010
From: report at bugs.python.org (Bert Hughes)
Date: Sat, 16 Jan 2010 18:24:37 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1263666277.58.0.772311276525.issue2531@psf.upfronthosting.co.za>


Bert Hughes <b.hughes at fmpco.com> added the comment:

Expressions like "Decimal('100.0') < .01" being silently wrong (True!) is *very* dangerous behavior, it should raise exception like any other Decimal-float operation, and hopefully will be back-ported to 2.7. 

Eg: 3rd party module kinterbasdb, which provides access to Firebird database, returns floats from firebird large-int types (eg NUMERIC 18,2) in versions of kinrebasdb 3.2 or less, but in versions 3.3+ kinterbasdb retrieves large-int as type Decimal. This means if python/kinterbasdb users upgrade kinterbasdb they must be aware of this python bug, because all existing code must be inspected for "(retrieved Decimal value) compare (float)" statements, which before upgrade were Ok (retrieved float value) compare (float)) statements.

I'm new to this tracker, I hope this simply is added as an additional comment & squawk of dismay to the "float compared to decimal is silently incorrec" issue.

----------
nosy: +bertchughes
versions: +Python 2.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

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: [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 19:25:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 18:25:56 +0000
Subject: [issue4770] binascii module,
	inconsistent behavior: some functions accept unicode string input
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1263666356.84.0.434907233239.issue4770@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15563/issue4770_binascii_py3k_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:27:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 18:27:51 +0000
Subject: [issue4770] binascii module,
	inconsistent behavior: some functions accept unicode string input
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1263666471.12.0.545584201779.issue4770@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch updated, after 7703 is merged in py3k.

----------
Added file: http://bugs.python.org/file15914/issue4770_binascii_py3k_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:37:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 18:37:38 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1263667058.81.0.0125119336282.issue2531@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:38:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 18:38:16 +0000
Subject: [issue6690] BUILD_SET followed by COMPARE_OP (in) can be optimized if
	all items are consts
In-Reply-To: <1250112728.26.0.437991636315.issue6690@psf.upfronthosting.co.za>
Message-ID: <1263667096.87.0.0482009987204.issue6690@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch was committed in r77543 (py3k), thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6690>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:42:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Jan 2010 18:42:56 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263667376.14.0.231926771239.issue1670765@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I actually had the wrong message number entirely.  I was trying to reference this one, since it has the additional tests.  Fixed in r77525.

I backported the fix to 2.6 in r77526 and r77527, forwarded ported to py3k in r77542 (with the addition of the new test), and backported to 3.1 in r77546.

I'm going to close this issue, but we aren't forgetting about the whitespace issues.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Sat Jan 16 19:59:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 18:59:53 +0000
Subject: [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: <1263668393.29.0.551450699179.issue7716@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Build
keywords: +needs review
priority:  -> normal
type:  -> behavior
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7716>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:03:55 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:03:55 +0000
Subject: [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:04:13 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:04:13 +0000
Subject: [issue7717] Compilation fixes for IRIX
In-Reply-To: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>
Message-ID: <1263668653.2.0.515178682685.issue7717@psf.upfronthosting.co.za>


Changes by Fabian Groffen <grobian at gentoo.org>:


Added file: http://bugs.python.org/file15916/python-2.6.4-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: [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:07:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 19:07:21 +0000
Subject: [issue7717] Compilation fixes for IRIX
In-Reply-To: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>
Message-ID: <1263668841.54.0.598254160592.issue7717@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7717>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:16:46 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:16:46 +0000
Subject: [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 20:24:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Jan 2010 19:24:25 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1263669865.56.0.262367903007.issue2531@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:34:14 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:34:14 +0000
Subject: [issue1471934] Python libcrypt build problem on Solaris 8, 9,
	10 and OpenSolaris
Message-ID: <1263670454.88.0.476012173105.issue1471934@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

I use this patch, which just always uses crypt_i on Solaris to work around the problem.

----------
keywords: +patch
nosy: +grobian
title: Python libcrypt build problem on Solaris 8 -> Python libcrypt build problem on Solaris 8, 9, 10 and OpenSolaris
versions: +Python 2.7
Added file: http://bugs.python.org/file15919/python-2.7-solaris64-crypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471934>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:34:41 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:34:41 +0000
Subject: [issue1471934] Python libcrypt build problem on Solaris 8, 9,
	10 and OpenSolaris
Message-ID: <1263670481.28.0.97583637146.issue1471934@psf.upfronthosting.co.za>


Changes by Fabian Groffen <grobian at gentoo.org>:


Added file: http://bugs.python.org/file15920/python-2.6.2-solaris64-crypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471934>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:36:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 19:36:24 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1263670584.21.0.623926183797.issue7719@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7719>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:39:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 19:39:23 +0000
Subject: [issue1471934] Python libcrypt build problem on Solaris 8, 9,
	10 and OpenSolaris
Message-ID: <1263670763.89.0.428277845371.issue1471934@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1471934>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:45:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jan 2010 19:45:55 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263671155.68.0.759868901608.issue7718@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm worried about this "on behalf of" contribution. Does Stuart Shelton actually approve this contribution? Would he be willing to sign a contributor agreement?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:52:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 19:52:11 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263671531.58.0.895081704832.issue7718@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

#7717 also contains code "on behalf of" other people.

----------
nosy: +brian.curtin
priority:  -> normal
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:56:57 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:56:57 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263671817.86.0.808317828694.issue7718@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

I think so.  From my experience he's mainly not willing to sign up to each and every bugtracking system, which I fully understand.

Do you guys need signed contracts for each and every (even single line) patch?  Is it better to report the problem and how it can possibly be redone by one of the python devs?  In this case that would be something like "take the linux case, and change LD_LIBRARY_PATH to LD_LIBRARYN32_PATH".

I'm really in favour of getting rid of these 35 patches against Python :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sat Jan 16 20:57:45 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 19:57:45 +0000
Subject: [issue6308] termios fix for QNX breaks HP-UX
In-Reply-To: <1245342143.83.0.0806702305005.issue6308@psf.upfronthosting.co.za>
Message-ID: <1263671865.53.0.545354241239.issue6308@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

still applies to 2.7

----------
nosy: +grobian
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6308>
_______________________________________

From report at bugs.python.org  Sat Jan 16 21:03:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jan 2010 20:03:05 +0000
Subject: [issue7717] Compilation fixes for IRIX
In-Reply-To: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>
Message-ID: <1263672185.56.0.40256790465.issue7717@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Same issue as with 7718: I'm worried about this "on behalf of" contribution. Does Stuart Shelton actually approve this contribution? Would he be willing to sign a contributor agreement?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7717>
_______________________________________

From report at bugs.python.org  Sat Jan 16 21:11:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jan 2010 20:11:32 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263672692.14.0.722625607799.issue7718@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the patch in its current form is then, unfortunately, not acceptable - unless Stuart Shelton actually signs a contributor agreement. I don't know what makes you believe that he actually meant to contribute the code to Python, but I just don't want to take the risk that he comes back later and says that the contribution was unauthorized (or perhaps not even his own work).

For trivial patches, redoing them might be reasonable. It might then be useful to record (e.g. in a comment) how they had been done, and to also indicate how the submitter has tested them.

Rejecting this patch.

----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sat Jan 16 21:14:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jan 2010 20:14:04 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263672844.46.0.779550618178.issue7718@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution: postponed -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sat Jan 16 21:16:00 2010
From: report at bugs.python.org (Fabian Groffen)
Date: Sat, 16 Jan 2010 20:16:00 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263672960.24.0.308677659322.issue7718@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

I've asked Stuart to sign up and comment on this bug to get his opinion.  Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:16:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 21:16:59 +0000
Subject: [issue7714] configure GCC version detection fix for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1263676619.44.0.222763993661.issue7714@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7714>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:20:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 21:20:01 +0000
Subject: [issue7713] implement ability to disable automatic search path
	additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1263676801.67.0.735964640844.issue7713@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7713>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:21:22 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 21:21:22 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263676882.34.0.207912486048.issue7715@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7715>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:24:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 21:24:41 +0000
Subject: [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: <1263677081.97.0.808254852962.issue7712@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:31:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 21:31:17 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263677477.5.0.80828633163.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One of the buildbots just produced a MemoryError from test_strtod:

http://www.python.org/dev/buildbot/all/builders/i386%20Ubuntu%203.x/builds/411

It looks as though there's a memory leak somewhere in dtoa.c.  It's a bit difficult to tell, though, since the memory allocation functions in that file deliberately hold on to small pieces of memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:39:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 21:39:39 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1263677979.69.0.592406854517.issue3445@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

In your test, the more common convention is to use assertFalse(foo) instead of assert_(not foo).

----------
keywords: +needs review
nosy: +brian.curtin
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

From report at bugs.python.org  Sat Jan 16 22:42:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 21:42:56 +0000
Subject: [issue3445] Ignore missing attributes in functools.update_wrapper
In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za>
Message-ID: <1263678176.53.0.202883882001.issue3445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think it would be better to test with some of the real world examples given in this issue: str.split, and a functools.partial object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3445>
_______________________________________

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: [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:48:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jan 2010 21:48:54 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263678534.47.0.761246379979.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

First, I get the following compilation warnings under Linux:
/home/antoine/cpython/26/Modules/_fileio.c: In function ?fileio_truncate?:
/home/antoine/cpython/26/Modules/_fileio.c:651: attention : unused variable ?tempposobj?
/home/antoine/cpython/26/Modules/_fileio.c:650: attention : unused variable ?oldposobj?

The two variables should be declared at the beginning of the Windows-specific block instead.

Second, there's a test failure in test_io:

======================================================================
FAIL: test_large_file_ops (test.test_io.IOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/26/Lib/test/test_io.py", line 221, in test_large_file_ops
    self.large_file_ops(f)
  File "/home/antoine/cpython/26/Lib/test/test_io.py", line 154, in large_file_ops
    self.assertEqual(f.tell(), self.LARGE + 1)
AssertionError: 2147483650L != 2147483649

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

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: [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  Sat Jan 16 23:01:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 22:01:48 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263679308.9.0.882573530117.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Most of the patch is outdated, but I could check out an updated patch on my Win7 64 machine.

----------
keywords: +needs review
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jan 16 23:04:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Jan 2010 22:04:16 +0000
Subject: [issue7714] configure GCC version detection fix for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1263679456.69.0.667937888144.issue7714@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7714>
_______________________________________

From report at bugs.python.org  Sat Jan 16 23:05:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Jan 2010 22:05:18 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263679518.12.0.729862182047.issue7715@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7715>
_______________________________________

From report at bugs.python.org  Sat Jan 16 23:38:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 22:38:21 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263681501.75.0.750727504285.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, so there's a memory leak for overflowing values:  if an overflow is detected in the main correction loop of _Py_dg_strtod, then 'references' to bd0, bd, bb, bs and delta aren't released.

There may be other leaks;  I'm trying to come up with a good way to detect them reliably.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 23:43:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Jan 2010 22:43:58 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263681838.25.0.344789048137.issue7632@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is what Valgrind complains about:

==4750== 3,456 (1,440 direct, 2,016 indirect) bytes in 30 blocks are definitely lost in loss record 3,302 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C286E: _Py_dg_strtod (dtoa.c:1675)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)
==4750==    by 0x47F1CF: call_function (ceval.c:3891)

==4750== 9,680 bytes in 242 blocks are still reachable in loss record 3,369 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0875: i2b (dtoa.c:556)
==4750==    by 0x4C2906: _Py_dg_strtod (dtoa.c:1687)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

==4750== 270,720 bytes in 1,692 blocks are indirectly lost in loss record 3,423 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0F97: diff (dtoa.c:825)
==4750==    by 0x4C2BED: _Py_dg_strtod (dtoa.c:1779)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

==4750== 382,080 bytes in 2,388 blocks are indirectly lost in loss record 3,424 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0C82: lshift (dtoa.c:730)
==4750==    by 0x4C2BA9: _Py_dg_strtod (dtoa.c:1771)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

==4750== 414,560 bytes in 2,591 blocks are indirectly lost in loss record 3,425 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0C82: lshift (dtoa.c:730)
==4750==    by 0x4C2AD1: _Py_dg_strtod (dtoa.c:1744)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

==4750== 414,960 (414,768 direct, 192 indirect) bytes in 2,604 blocks are definitely lost in loss record 3,426 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0929: mult (dtoa.c:592)
==4750==    by 0x4C0B90: pow5mult (dtoa.c:691)
==4750==    by 0x4C2B1A: _Py_dg_strtod (dtoa.c:1753)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)

==4750== 890,720 (532,960 direct, 357,760 indirect) bytes in 3,331 blocks are definitely lost in loss record 3,428 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0C82: lshift (dtoa.c:730)
==4750==    by 0x4C2AD1: _Py_dg_strtod (dtoa.c:1744)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

==4750== 1,021,280 (566,080 direct, 455,200 indirect) bytes in 3,538 blocks are definitely lost in loss record 3,429 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0C82: lshift (dtoa.c:730)
==4750==    by 0x4C2BA9: _Py_dg_strtod (dtoa.c:1771)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

==4750== 1,465,280 (676,640 direct, 788,640 indirect) bytes in 4,229 blocks are definitely lost in loss record 3,430 of 3,430
==4750==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==    by 0x41B7B5: PyMem_Malloc (object.c:1740)
==4750==    by 0x4C03CF: Balloc (dtoa.c:352)
==4750==    by 0x4C0F97: diff (dtoa.c:825)
==4750==    by 0x4C2BED: _Py_dg_strtod (dtoa.c:1779)
==4750==    by 0x4BEDF2: _PyOS_ascii_strtod (pystrtod.c:103)
==4750==    by 0x4BEF61: PyOS_string_to_double (pystrtod.c:345)
==4750==    by 0x543968: PyFloat_FromString (floatobject.c:192)
==4750==    by 0x546E74: float_new (floatobject.c:1569)
==4750==    by 0x42B5C9: type_call (typeobject.c:664)
==4750==    by 0x516442: PyObject_Call (abstract.c:2160)
==4750==    by 0x47FDAE: do_call (ceval.c:4088)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sat Jan 16 23:47:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 16 Jan 2010 22:47:11 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263682031.1.0.815107850273.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't see where the patch is outdated.

I'm attaching an updated patch 18 that works cleanly against r77557. It also fixes an unterminated comment.

XP runs correctly (without the new functionality) with this patch. However, on Windows 7 as a normal user I get a permission issue:

Python 3.2a0 (py3k, Jan 16 2010, 17:26:22) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.symlink('python.exe', 'python-test.exe')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 1314] A required privilege is not held by the client: 'python.exe'

This is in a directory that I own, with a file that I own.

Jason: Is there something obvious that I'm missing? Or is some special (not out-of-the-box) permission really required?

----------
Added file: http://bugs.python.org/file15921/windows symlink draft 18.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sat Jan 16 23:56:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 22:56:38 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263682598.26.0.525809432495.issue7721@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed. The snippet works for 3.1 and 2.7a2.

from itertools import count, islice
irange = lambda start, stop, step: islice(count(start, step), (stop-start+step-1)//step)


The documentation needs update for 2.6 only.

This kind of snippet seems backward compatible for 2.6:
irange = lambda start, stop, step: islice(count(start), 0, stop, step)

----------
nosy: +flox
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 00:07:17 2010
From: report at bugs.python.org (Martin Manns)
Date: Sat, 16 Jan 2010 23:07:17 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263683237.53.0.81809008988.issue7721@psf.upfronthosting.co.za>


Martin Manns <mmanns at gmx.net> added the comment:

The new snippet does not work for me:

>>> list(irange(-12, 20, 4))
[-12, -8, -4, 0, 4]

I have attached code that seems to work.
It is more than a snipped though.

----------
Added file: http://bugs.python.org/file15922/irange.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 00:28:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 23:28:17 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263684497.5.0.244284116581.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, thanks for that!  I'm not entirely sure how to make use of it, though.  Is there a way to tell Valgrind that some leaks are expected?

The main problem with leak detection is that dtoa.c deliberately keeps hold of any malloc'ed chunks less than a certain size (which I think is something like 2048 bytes, but I'm not sure).  These chunks are never freed in normal use;  instead, they're added to a bunch of free lists for the next time that strtod or dtoa is called.  The logic isn't too complicated:  it's in the functions Balloc and Bfree in dtoa.c.

So the right thing to do is just to check that for each call to strtod, the total number of calls to Balloc matches the total number of calls to Bfree with non-NULL argument.  And similarly for dtoa, except that in that case one of the Balloc'd blocks gets returned to the caller (it's the caller's responsibility to call free_dtoa to free it when it's no longer needed), so there should be a difference of 1.

And there's one further wrinkle:  dtoa.c maintains a list of powers of 5 of the form 5**2**k, and this list is automatically extended with newly allocated Bigints when necessary:  those Bigints are never freed either, so calls to Balloc from that source should be ignored.  Another way round this is just to ignore any leak from the first call to strtod, and then do a repeat call with the same parameters;  the second call will already have all the powers of 5 it needs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sun Jan 17 00:29:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 16 Jan 2010 23:29:04 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263684544.28.0.00129894101331.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Upgrading to release blocker again:  the memory leak should be fixed for 2.7 (and more immediately, for 3.1.2).

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sun Jan 17 00:37:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jan 2010 23:37:37 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263685057.48.0.599982740584.issue7721@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Right. Insufficient test.

This snippet looks better, if we provide a replacement for 2.6.

>>> irange = lambda start, stop, step: islice(count(start), 0, stop-start, step)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 00:50:22 2010
From: report at bugs.python.org (Martin Manns)
Date: Sat, 16 Jan 2010 23:50:22 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263685822.28.0.594281105399.issue7721@psf.upfronthosting.co.za>


Martin Manns <mmanns at gmx.net> added the comment:

The new snippet works better.

>>> list(irange(-12, 20, 4))
[-12, -8, -4, 0, 4, 8, 12, 16]

However, it does not like large or negative slices:

>>> list(irange(-2**65,2**65,2**61))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
OverflowError: long int too large to convert to int

>>> list(irange(32,2,-3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
ValueError: Indices for islice() must be non-negative integers or None.

Perhaps the documentation can mention that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 00:59:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 16 Jan 2010 23:59:12 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263686352.59.0.944503863093.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm getting failures in test_glob, test_os, test_platform, test_posixpath, test_shutil, and test_tarfile. failures.txt is attached with the results I see on Win 7 with a 64 bit build.

I'm not seeing the exception Eric saw. That worked for me as both an admin and regular user.

----------
Added file: http://bugs.python.org/file15923/failures.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 01:01:11 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 00:01:11 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <1263682031.1.0.815107850273.issue1578269@psf.upfronthosting.co.za>
Message-ID: <028E0E32-B2D3-44F1-9CD0-1A0E64C6C78F@jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I haven't seen this error. My first guess is its a regression due to  
win 7 or updates to the python code. I'll look into it.

Sent from my comm

On Jan 16, 2010, at 17:47, "Eric Smith" <report at bugs.python.org> wrote:

>
> Eric Smith <eric at trueblade.com> added the comment:
>
> I don't see where the patch is outdated.
>
> I'm attaching an updated patch 18 that works cleanly against r77557.  
> It also fixes an unterminated comment.
>
> XP runs correctly (without the new functionality) with this patch.  
> However, on Windows 7 as a normal user I get a permission issue:
>
> Python 3.2a0 (py3k, Jan 16 2010, 17:26:22) [MSC v.1500 32 bit  
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os
>>>> os.symlink('python.exe', 'python-test.exe')
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> WindowsError: [Error 1314] A required privilege is not held by the  
> client: 'python.exe'
>
> This is in a directory that I own, with a file that I own.
>
> Jason: Is there something obvious that I'm missing? Or is some  
> special (not out-of-the-box) permission really required?
>
> ----------
> Added file: http://bugs.python.org/file15921/windows symlink draft  
> 18.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1578269>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 01:25:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 00:25:51 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263687951.09.0.159008172411.issue7721@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

You will prefer this one. It is as fast as the 2.7 version.

from itertools import count, takewhile
irange = lambda start, stop, step: takewhile(lambda x: x<stop, (start+i*step for i in count()))

>>> list(irange(-2**65,2**65,2**61))
[-36893488147419103232L, -34587645138205409280L, ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 01:33:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 00:33:51 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263688431.52.0.191937691683.issue7721@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

You will prefer this one. It is as fast as the 2.7 version.
The restrictions are described in the itertools documentation.


from itertools import count, takewhile
irange = lambda start, stop, step: takewhile(lambda x: x<stop, (start+i*step for i in count()))

>>> list(irange(-2**65,2**65,2**61))
[-36893488147419103232L, ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 02:09:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 01:09:40 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263690580.05.0.267718676186.issue7721@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

If you need also negative steps:

from itertools import count, takewhile
def irange(start, stop, step):
    if step < 0:
        cond = lambda x: x > stop
    else:
        cond = lambda x: x < stop
    return takewhile(cond, (start + i * step for i in count()))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 02:19:11 2010
From: report at bugs.python.org (Martin Manns)
Date: Sun, 17 Jan 2010 01:19:11 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263691151.25.0.211192139466.issue7721@psf.upfronthosting.co.za>


Martin Manns <mmanns at gmx.net> added the comment:

Great solution!

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 02:27:54 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Jan 2010 01:27:54 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263691674.46.0.675240481045.issue7715@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note that with current trunk and in-the-pipeline proposed changes, configure is depending on using the Apple-supplied enhanced version of arch on 10.5+ (e.g. to force execution in 32-bit mode) so, while the patch here doesn't harm anything, it points to another potential problem: configure should probably ensure it *is* using the Apple arch.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7715>
_______________________________________

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: [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 08:26:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Jan 2010 07:26:01 +0000
Subject: [issue1722] Undocumented urllib functions
In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za>
Message-ID: <1263713161.04.0.337685822004.issue1722@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722>
_______________________________________

From report at bugs.python.org  Sun Jan 17 09:31:35 2010
From: report at bugs.python.org (Peter Bienstman)
Date: Sun, 17 Jan 2010 08:31:35 +0000
Subject: [issue7693] tarfile.extractall can't have unicode extraction path
In-Reply-To: <1263647262.5.0.583537272048.issue7693@psf.upfronthosting.co.za>
Message-ID: <201001170932.06139.Peter.Bienstman@ugent.be>


Peter Bienstman <Peter.Bienstman at UGent.be> added the comment:

> Lars Gust?bel <lars at gustaebel.de> added the comment:
> 
> So, use the pax format. It stores the filenames as utf-8 and this way you
>  will be on the safe side.
> 
> I hope we both agree that the solution to your particular problem is
>  nothing tarfile.py can provide.

If I want to extract a pax archive to a unicode path with non-latin 
characters, how should I encode the path before passing it to 'extractall'? 
would utf-8 be OK?

Peter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7693>
_______________________________________

From report at bugs.python.org  Sun Jan 17 09:31:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Jan 2010 08:31:45 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1263717105.57.0.574725129688.issue7721@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sun Jan 17 09:33:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Jan 2010 08:33:26 +0000
Subject: [issue7722] calendar.{HTMLCalendar,
	TextCalendar}.formatyear have incorrect definition
In-Reply-To: <1263699327.27.0.112532747824.issue7722@psf.upfronthosting.co.za>
Message-ID: <1263717206.56.0.113790479183.issue7722@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That was already fixed on trunk, but not yet merged to 2.6.  I've done so now in r77559.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7722>
_______________________________________

From report at bugs.python.org  Sun Jan 17 09:33:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Jan 2010 08:33:43 +0000
Subject: [issue6837] Mark the compiler package as deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1263717223.69.0.101826920658.issue6837@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6837>
_______________________________________

From report at bugs.python.org  Sun Jan 17 09:34:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Jan 2010 08:34:45 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1263717285.58.0.96989144337.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'll try to find time to look at this again before 2.7 beta.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Sun Jan 17 12:42:39 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 11:42:39 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263728559.15.0.170066944166.issue7715@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with Ned: the correct patch is to hardcode usage of /usr/bin/arch, because that's the one the build environment is expecting to use and the only one I care to support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7715>
_______________________________________

From report at bugs.python.org  Sun Jan 17 12:45:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 11:45:22 +0000
Subject: [issue7714] configure GCC version detection fix for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1263728722.64.0.588940079659.issue7714@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thanks for the patch, I didn't know of the -dumpversion flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7714>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:00:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 12:00:03 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1263729603.84.0.721716457644.issue7561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. A static empty string is used in case PyByteArray_AS_STRING() is asked on an empty bytearray, instead of returning NULL.

Another possibility would be to implement tp_new for bytearray and always allocate a new 1-byte string, but this would make the patch slightly more complicated.

(the patch also removes "nullstring", which was unused since Florent's recent patches)

----------
Added file: http://bugs.python.org/file15924/bytearray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:20:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 12:20:50 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1263730850.63.0.784276070719.issue7561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The posixmodule was committed with a test in r77571 (py3k) and r77572 (3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:21:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 12:21:02 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1263730862.69.0.943641940276.issue7561@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15660/posixmodule_fn_bytearray_fix_01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:21:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 12:21:06 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1263730866.46.0.924348272482.issue7561@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15663/release_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:21:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 12:21:22 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1263730882.59.0.917229167635.issue7561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I meant the posixmodule fix, of course)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:39:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 12:39:12 +0000
Subject: [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: <1263731952.21.0.782736385028.issue7679@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Steve: the "report this..." message is generated by the configure script and is added by autoconf, AFAIK we cannot change that message.

That said: there is a problem on your system with a python build: configure now thinks that is has found a workable libintl.h, even though the file doesn't work when you try to compile.

The best workaround is to temporarily move /usr/local aside during the build.

I've added some text about this to Mac/README.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7679>
_______________________________________

From report at bugs.python.org  Sun Jan 17 13:44:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 12:44:19 +0000
Subject: [issue7561] PyByteArray_AS_STRING used unsafely
In-Reply-To: <1261467103.65.0.513251554155.issue7561@psf.upfronthosting.co.za>
Message-ID: <1263732259.14.0.163660524834.issue7561@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The bytearray fix has been committed in r77573 (trunk), r77574 (2.6), r77576 (py3k), r77577 (3.1). The issue can now be closed.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7561>
_______________________________________

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: [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 14:49:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 13:49:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263736148.04.0.757164394354.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I've created issue7723 for sqlite3 module using buffer().
It's not so simple.

----------
dependencies: +sqlite only accept buffer() for BLOB objects (input/output)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 14:51:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 13:51:49 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263736309.37.0.386766791333.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15794/issue7092_json_sqlite_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 14:53:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2010 13:53:31 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263736411.54.0.134187263766.issue7632@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Mark, thanks for the explanation! - You can generate suppressions for the Misc/valgrind-python.supp file, but you have to know exactly which errors can be ignored.

Going through the Valgrind output again, it looks like most of it is about what you already mentioned (bd0, bd, bb, bs and delta not being released).

Would it be much work to provide Valgrind-friendly versions of Balloc, Bfree and pow5mult? Balloc and Bfree are already mentioned in an XXX
comment, pow5mult should be a slow version that doesn't cache anything. Perhaps these could be ifdef'd with Py_USING_MEMORY_DEBUGGER.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sun Jan 17 14:54:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 13:54:51 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263736491.9.0.863332533444.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15925/issue7092_json.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 14:58:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Jan 2010 13:58:25 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263736705.18.0.893534700277.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, I'm not particularly familiar with Valgrind:  can you tell me what would need to be done?  Is a non-caching version of pow5mult all that's required?

Here's the patch that I'm using to detect leaks at the moment.  (It includes a slow pow5mult version.)

----------
Added file: http://bugs.python.org/file15926/dtoa_detect_leaks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sun Jan 17 15:05:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 14:05:46 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB objects
	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263737146.04.0.833482421206.issue7723@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ghaering
nosy: +ghaering
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sun Jan 17 15:22:29 2010
From: report at bugs.python.org (Enrico Carlesso)
Date: Sun, 17 Jan 2010 14:22:29 +0000
Subject: [issue6683] smtplib authentication - try all mechanisms
In-Reply-To: <1250007436.58.0.446313092376.issue6683@psf.upfronthosting.co.za>
Message-ID: <1263738149.25.0.454352589609.issue6683@psf.upfronthosting.co.za>


Enrico Carlesso <enricocarlesso at gmail.com> added the comment:

This affects tophost.it too. Unable to login with CRAM-MD5 but plain login (as described in referenced workaround) work fine.

----------
nosy: +Enrico.Carlesso

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6683>
_______________________________________

From report at bugs.python.org  Sun Jan 17 15:23:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 14:23:15 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB objects
	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263738195.68.0.175097274894.issue7723@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sun Jan 17 15:48:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 14:48:36 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB objects
	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263739716.73.0.111911054909.issue7723@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Sidenotes:
 - documentation for Python 3 is outdated
 - it may be a release blocker, since there's no alternative:
   currently it uses exclusively buffer() for BLOB object

----------

_______________________________________
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: [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 16:07:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 15:07:40 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263740860.43.0.747707466713.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15787/issue7092_syntax_imports.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 16:07:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 15:07:45 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263740865.76.0.895795123726.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15789/issue7092_filterwarnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 16:09:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 15:09:07 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263740947.1.0.579368195696.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patches updated against trunk.

----------
Added file: http://bugs.python.org/file15927/issue7092_syntax_imports_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 16:09:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 15:09:34 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263740974.92.0.527570720864.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15928/issue7092_filterwarnings_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 16:27:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 15:27:54 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263742074.01.0.991636957605.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15927/issue7092_syntax_imports_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 16:28:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 15:28:58 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263742138.82.0.39145225372.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Re-uploaded "syntax_imports_v2" with patch for test_bsddb.py

----------
Added file: http://bugs.python.org/file15929/issue7092_syntax_imports_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 16:42:00 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jan 2010 15:42:00 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263742920.65.0.0449831148544.issue7632@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

With the latest dtoa.c, your non-caching pow5mult and a quick hack for Balloc and Bfree I get zero (dtoa.c related) Valgrind errors.

So the attached memory_debugger.diff is pretty much all what's needed for Valgrind.

----------
Added file: http://bugs.python.org/file15930/memory_debugger.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sun Jan 17 17:16:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 16:16:48 +0000
Subject: [issue1865] Bytes alias for 2.6
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1263745008.14.0.417214847773.issue1865@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

IMHO, this feature should be documented.

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +flox, georg.brandl
status: closed -> open
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1865>
_______________________________________

From report at bugs.python.org  Sun Jan 17 17:26:51 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 16:26:51 +0000
Subject: [issue7714] configure GCC version detection fix for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1263745611.61.0.937405479078.issue7714@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed this in 77585 (trunk) and will port this to the other branches soon.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7714>
_______________________________________

From report at bugs.python.org  Sun Jan 17 17:27:03 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 16:27:03 +0000
Subject: [issue7714] configure GCC version detection fix for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1263745623.46.0.305896368024.issue7714@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7714>
_______________________________________

From report at bugs.python.org  Sun Jan 17 17:28:23 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 16:28:23 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263745703.57.0.814641353688.issue7658@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed a fix for this in r77585, please test.

I can now compile python-trunk on OSX 10.6 while targetting the 10.4 SDK, and have compiled on OSX 10.4 as well.

I will forward port this to 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7658>
_______________________________________

From report at bugs.python.org  Sun Jan 17 17:28:38 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 16:28:38 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1263745718.32.0.436828076066.issue7658@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7658>
_______________________________________

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: [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: [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 18:51:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 17 Jan 2010 17:51:56 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB objects
	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263750716.46.0.081651757892.issue7723@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

buffer() is only deprecated in Python 3.x, not in Python 2.7, so the current implementation is perfectly valid for Python 2.7.

Note that buffer() has long been the preferred type for passing binary objects to and from a database.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sun Jan 17 19:12:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Jan 2010 18:12:44 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1263751964.0.0.413738284483.issue7724@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See also newly opened Issue7713 which expands the issue to other platforms .

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sun Jan 17 19:14:25 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Jan 2010 18:14:25 +0000
Subject: [issue7713] implement ability to disable automatic search path
	additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1263752065.56.0.567860352959.issue7713@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See also Issue7724 which addresses the particular case of building with OS X SDKs.

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7713>
_______________________________________

From report at bugs.python.org  Sun Jan 17 19:34:05 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 18:34:05 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1263753245.53.0.027109438474.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Issue7713 is not the same: it asks for a way to affect the hardcoded paths in setup.py, this issue asks to honor the SDK-root by setup.py.

I've done some further research and this affects distutils in general: the compiler has methods to look for files and those need to honor the SDK root as well.

The hard part will be to describe correctly how Apple's compilers behave when -isysroot is present. Replicating that in our build environment should then be straightforward.   The reason that the specification part is hard is that Apple's document don't fully describe how -isysroot works. That is, '-isysroot,/Some/SDK -I/Users/ronald/OpenSource' works and will look in /Users/ronald/OpenSource, even though '/Users' is not in the SDK directory. This means it is just prepending $UNIVERSALSDK to every filename is not a correct fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sun Jan 17 19:59:39 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Jan 2010 18:59:39 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1263754779.07.0.754388739717.issue7724@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's not exactly the same issue but I think it is closely related since effectively both document the need for setup.py to build with a non-default system root (or SDK) and some of the hardcoded paths should be being satisfied from the SDK.  So at least parts of the more general solution should apply to OS X builds and potentially vice versa.

Yes, Apple's documentation of -isysroot, -syslibroot, and --sysroot leave a lot to be desired. My guess is that --sysroot was added independently by GNU and doesn't seem to be useful here.  And, as best I can tell on 10.4 to 10.6, -syslibroot gets added automatically when -isysroot is supplied. Is that your understanding as well?  I also see the man page for gcc discusses -isystem which sounds like it might be helpful if it actually works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:02:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 19:02:50 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB objects
	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263754970.69.0.236489509817.issue7723@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is not exact. buffer() doesn't exist at all in 3.x, and it issues a warning in 2.x when used with the -3 flag:

$ ./python -3
Python 2.7a2+ (trunk:77580M, Jan 17 2010, 16:51:51) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> buffer('abc')
__main__:1: DeprecationWarning: buffer() not supported in 3.x
<read-only buffer for 0x7f913ac79800, size -1, offset 0 at 0x7f913aba8570>

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:04:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 17 Jan 2010 19:04:45 +0000
Subject: [issue1760357] ZipFile.write fails with bad modification time
Message-ID: <1263755085.93.0.930657317934.issue1760357@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
stage:  -> test needed
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/issue1760357>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:05:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:05:54 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1263755154.12.0.337472082225.issue7724@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree, our usage of -isysroot seems to be correct.

What's rather annoying is that the documentation seems to claim that the sysroot value gets prepended to every search location, while that is obviously not try.  My guess is that it is only prepended for built-in locations (/usr/{include,lib}, /System/Library/Frameworks, /usr/local/{include,lib} and /Library/Frameworks), but I haven't found documentation yet that confirms this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:08:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:08:43 +0000
Subject: [issue7184] build failures on Snow Leopard
In-Reply-To: <1256170580.09.0.19194872492.issue7184@psf.upfronthosting.co.za>
Message-ID: <1263755323.85.0.58735376201.issue7184@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7184>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:12:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:12:37 +0000
Subject: [issue7226] IDLE right-clicks don't work on Mac OS 10.5
In-Reply-To: <1256693718.71.0.813168523679.issue7226@psf.upfronthosting.co.za>
Message-ID: <1263755557.08.0.916012637741.issue7226@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

(I've removed 3.0 from the list because we no longer do maintenance releases for that).

My gut feeling is that this an issue with Tkinter.

----------
resolution:  -> accepted
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7226>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:13:11 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 17 Jan 2010 19:13:11 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263755591.8.0.191286125214.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright - sorry for the failure - I've cleaned my hdd enough to launch large_file tests too.

The thing is - are there platforms available to test a patch against the whole test suite of python, and against several OSes ? I've found no such thing around build bots, and since I'm kind of stuck on win32 without a full compilation environment (sqlite, zlib etc. lack some setup), I miss vision depth concerning testing...

Anyway, here is a corrected patch, passing the full io-related test suites on win32 (and visibly ready for unix too).

----------
Added file: http://bugs.python.org/file15931/patch26_largefile_tested.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:13:27 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 17 Jan 2010 19:13:27 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1263755607.77.0.14435210026.issue6939@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file15909/patch26_truncate_pos_refcounts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:15:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:15:28 +0000
Subject: [issue3432] Mac, 2.6 framework install error
In-Reply-To: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za>
Message-ID: <1263755728.34.0.722948507826.issue3432@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3432>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:17:14 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:17:14 +0000
Subject: [issue892707] debuggable/profileable Python framework
Message-ID: <1263755834.7.0.973854955854.issue892707@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue892707>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:27:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jan 2010 19:27:02 +0000
Subject: [issue3599] test_pydoc after test_urllib2 causes exception in
	Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1263756422.44.0.293631569051.issue3599@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3599>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:28:21 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Jan 2010 19:28:21 +0000
Subject: [issue7724] setup.py ignores SDK root on OSX
In-Reply-To: <1263740773.9.0.498921408121.issue7724@psf.upfronthosting.co.za>
Message-ID: <1263756501.94.0.845146430036.issue7724@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I suppose all of the relevant setup.py build-time tests could be restructured as autoconf-style tests using gcc & friends with consistent arguments (with the build and with Distutils) so there wouldn't need to be special knowledge in setup.py or configure about what paths are "system directories".  That might also solve the problems for other platforms as well.  A bit messy but maybe the right solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7724>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:29:54 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:29:54 +0000
Subject: [issue4834] Trouble configuring with icc on Mac OS X 10.5
In-Reply-To: <18784.64250.252843.484595@montanaro.dyndns.org>
Message-ID: <1263756594.71.0.482616410757.issue4834@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed a small change in r77587 (trunk) that disables usage of the 10.4u SDK when that SDK is not present.

That may or may not fix this issue. I'm not going to do anything more to this issue and am therefore closing it.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4834>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:33:16 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 17 Jan 2010 19:33:16 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263756796.84.0.0408367628943.issue7715@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied a patch to use /usr/bin/arch instead of just 'arch' in r7715 (trunk). 

I will port this to the other branches soonish.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7715>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:35:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 17 Jan 2010 19:35:38 +0000
Subject: [issue775964] fix test_grp failing on RedHat 6.2
Message-ID: <1263756938.33.0.803843391324.issue775964@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Ping. Anyone know if this is still an issue? I don't have access to RH.

----------
nosy: +brian.curtin
stage:  -> patch review
type:  -> behavior
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:54:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Jan 2010 19:54:13 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1263758053.58.0.622150673047.issue7092@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 17 20:54:43 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Jan 2010 19:54:43 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1263758083.28.0.888992337352.issue7715@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

BTW, I believe there is a problem with ARCH_RUN_32BIT as it stands: as far as I can tell, unlike lipo, /usr/bin/arch requires -ppc and rejects -ppc7400 regardless if the executable is -arch ppc7400 or -arch ppc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7715>
_______________________________________

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: [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 21:17:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 17 Jan 2010 20:17:37 +0000
Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 )
In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>
Message-ID: <1263759457.06.0.500475002818.issue7727@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +loewis
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7727>
_______________________________________

From report at bugs.python.org  Sun Jan 17 21:28:45 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sun, 17 Jan 2010 20:28:45 +0000
Subject: [issue775964] fix test_grp failing on RedHat 6.2
Message-ID: <1263760125.43.0.00565068325112.issue775964@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Sun Jan 17 22:09:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Jan 2010 21:09:46 +0000
Subject: [issue7632] dtoa.c: oversize b in quorem,
	and a menagerie of other bugs
In-Reply-To: <1262609405.67.0.856486016948.issue7632@psf.upfronthosting.co.za>
Message-ID: <1263762586.88.0.279967615229.issue7632@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Stefan.  Applied in r77589 (trunk), r77590 (py3k), r77591 (release31-maint) with one small change:  I moved the freelist and p5s declarations inside the #ifndef Py_USING_MEMORY_DEBUGGER conditionals.

The leak itself was fixed in revisions r77578 through r77580; from Stefan's Valgrind report, and my own refcount testing, it looks as though that was the only leak point.

I haven't finished reviewing/testing the _Py_dg_strtod code yet, but I'm going to close this issue;  if anything new turns up I'll open another one.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________

From report at bugs.python.org  Sun Jan 17 22:13:24 2010
From: report at bugs.python.org (Nir Aides)
Date: Sun, 17 Jan 2010 21:13:24 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263762804.14.0.400164376394.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> I do not find the existing phrasing in the IO docs ambiguous, but since 
> it is obviously possible to misinterpret it it would be good to clarify 
> it.  Can you suggest an alternate phrasing that would be clearer?

Replace 'may' with 'will' or 'shall' everywhere the context indicates a mandatory requirement.

Since this possibly affects the entire Python documentation, does it make sense to discuss this on python-dev?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

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: [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  Sun Jan 17 22:28:50 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sun, 17 Jan 2010 21:28:50 +0000
Subject: [issue7720] Errors in tests and C implementation of raw FileIO
In-Reply-To: <1263678361.41.0.947080196973.issue7720@psf.upfronthosting.co.za>
Message-ID: <1263763730.08.0.604188566413.issue7720@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hum, it seems that in python2.6, the C API for PyArg_ParseTuple isn't yet ready for bytes and bytearrays, is it ? "y"-like argument parsers don't exist, so I guess we can't easily patch the C api on this, only tests (replacing "xxx" by b"xxx")...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7720>
_______________________________________

From report at bugs.python.org  Sun Jan 17 22:29:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jan 2010 21:29:54 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1263762804.14.0.400164376394.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263763857.3361.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Replace 'may' with 'will' or 'shall' everywhere the context indicates
> a mandatory requirement.
> 
> Since this possibly affects the entire Python documentation, does it
> make sense to discuss this on python-dev?

Either that, or open a separate tracker issue. I'm not a documentation
specialist and would prefer to gather other opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Sun Jan 17 22:42:31 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 21:42:31 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263764551.36.0.238869044645.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Eric: I'm guessing the error you're seeing might be due to a UAC issue (http://en.wikipedia.org/wiki/User_Account_Control). I've been developing with UAC disabled (because working with the command-line in a UAC environment is a bit**).

Can you confirm that you're running your python.exe with Administrative privileges (and not just an Administrators account that's been demoted)? If you're launching Python.exe from a command-prompt, you may want to launch the prompt with "Run as Administrator".

I'm hoping that will straighten out this permission issue. I look forward to your reply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 22:44:15 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 21:44:15 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263764655.4.0.580371228598.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Brian: That's interesting. Many of those failures look very much like failures I've encountered and fixed, though I have been developing in a 32-bit environment. I'll run the tests on my 64-bit system and see if I can replicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 23:16:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 17 Jan 2010 22:16:44 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263766604.12.0.490402929034.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Yes, "Run as administrator" solves the permissions problem, leaving an error in test_posixpath that I'll investigate.

What's the expectations with the buildbots? Will these tests work there? We could create a branch and run a buildbot test if need be.

It would probably be best to find a way to skip these tests if they would fail with a permissions error.

----------
title: Add os.link() and os.symlink() and os.path.islink()	support for Windows -> Add os.link() and os.symlink() and os.path.islink() support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 23:26:40 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 22:26:40 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263767200.48.0.829970090933.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Brian: I applied the draft 18 patch to the latest version of /branches/py3k (77592). I compiled the release x64 build and ran a few tests using the following syntax:

PS C:\Users\jaraco\projects\public\python-core-py3k> .\pcbuild\amd64\python .\lib\test\test_glob.py

I found one failure in test_platform and 6 failures in test_posixpath, but no failures in the other modules you mentioned. Also, the failure in test_posixpath I'm seeing is different in nature from what you failure report indicates.

Can you reconsider if you may have missed some detail of the patch, as I seem to be unable to recreate the bulk of the issues you encountered. It seems Eric and I are getting similar results. I'm attaching the failures output from the tests as I encountered them.

----------
Added file: http://bugs.python.org/file15932/failures.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 23:28:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 17 Jan 2010 22:28:55 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263767335.04.0.523731393392.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm indeed seeing the same test_posixpath errors that Jason reported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 23:30:39 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 22:30:39 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263767439.83.0.732626709313.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15616/windows symlink draft 17.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 23:30:48 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 22:30:48 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263767448.6.0.993946422443.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Eric: The failures I'm seeing in test_posixpath indicate that realpath isn't working properly. Are you getting the same results?

As for the buildbot issue - I'm unfamiliar with the buildbot configuration. I think it would be worth creating the branch and letting the buildbot attempt the tests and see what things fail.

Let me see if I can track down the realpath and test_platform issues and devise a resolution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Sun Jan 17 23:49:50 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jan 2010 22:49:50 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263768590.19.0.573873860878.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This new patch (draft 19) addresses the outstanding test failures in test_posixpath.py and test_platform.py (by essentially disabling tests that were previously-disabled but became enabled on Windows by adding symlink support).

----------
Added file: http://bugs.python.org/file15933/windows symlink draft 19.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 00:22:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 17 Jan 2010 23:22:53 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263754970.69.0.236489509817.issue7723@psf.upfronthosting.co.za>
Message-ID: <4B539BC9.5040106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> This is not exact. buffer() doesn't exist at all in 3.x, and it issues a warning in 2.x when used with the -3 flag:
> 
> $ ./python -3
> Python 2.7a2+ (trunk:77580M, Jan 17 2010, 16:51:51) 
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> buffer('abc')
> __main__:1: DeprecationWarning: buffer() not supported in 3.x
> <read-only buffer for 0x7f913ac79800, size -1, offset 0 at 0x7f913aba8570>

Sorry, that's what I meant. It's not deprecated in the 2.x branch of Python.

----------
title: sqlite only accept buffer() for BLOB objects (input/output) -> sqlite only accept buffer() for BLOB objects	(input/output)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Mon Jan 18 00:31:57 2010
From: report at bugs.python.org (dontbugme)
Date: Sun, 17 Jan 2010 23:31:57 +0000
Subject: [issue7680] pythonw crash while attempting to start() a thread object
In-Reply-To: <1263270141.77.0.964688204265.issue7680@psf.upfronthosting.co.za>
Message-ID: <1263771117.06.0.386191082396.issue7680@psf.upfronthosting.co.za>


dontbugme <pythonbugsbugmenot at spamavert.com> added the comment:

After asking at the IRC channel, posborne resolved the error:

<posborne> Also, the behaviour of exiting the main thread before all threads has exited is undefined.  Is the behaviour different if you add t.join() to the end of the script?

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()
t.join()

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7680>
_______________________________________

From report at bugs.python.org  Mon Jan 18 04:02:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 03:02:42 +0000
Subject: [issue762963] timemodule.c: Python loses current timezone
Message-ID: <1263783762.31.0.313345314214.issue762963@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's an updated version of the previous patches with the test included in test_time.py. The test fails on Linux before the timemodule.c file is changed, then it passes once applied.

----------
keywords: +needs review
nosy: +brian.curtin
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file15934/issue762963.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________

From report at bugs.python.org  Mon Jan 18 04:35:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 03:35:28 +0000
Subject: [issue7720] Errors in tests and C implementation of raw FileIO
In-Reply-To: <1263678361.41.0.947080196973.issue7720@psf.upfronthosting.co.za>
Message-ID: <1263785728.69.0.764903612355.issue7720@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Tests
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7720>
_______________________________________

From report at bugs.python.org  Mon Jan 18 04:40:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 03:40:14 +0000
Subject: [issue7680] pythonw crash while attempting to start() a thread object
In-Reply-To: <1263270141.77.0.964688204265.issue7680@psf.upfronthosting.co.za>
Message-ID: <1263786014.74.0.784883739321.issue7680@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7680>
_______________________________________

From report at bugs.python.org  Mon Jan 18 05:25:26 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 04:25:26 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263788726.46.0.756977170467.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've confirmed that in fact a security policy permission is required to create a symbolic link, and that by default, that permission is only granted to administrators (see http://en.wikipedia.org/wiki/Symbolic_link#Windows_Vista_symbolic_link). Given this finding, I hope the buildbot can run the symlink tests as administrator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 05:44:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 04:44:32 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1263789872.84.0.696512201175.issue1596321@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

FWIW, Amaury's example runs without error on trunk and py3k (OS X 10.5).

2.6 prints the following:
"Exception in thread Thread-1 (most likely raised during interpreter shutdown)"

3.1 seg faults

----------
nosy: +brian.curtin
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1 -Python 2.4, Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Mon Jan 18 06:33:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 05:33:53 +0000
Subject: [issue7720] Errors in tests and C implementation of raw FileIO
In-Reply-To: <1263678361.41.0.947080196973.issue7720@psf.upfronthosting.co.za>
Message-ID: <1263792833.23.0.943769565619.issue7720@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7720>
_______________________________________

From report at bugs.python.org  Mon Jan 18 06:39:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Jan 2010 05:39:53 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263793193.64.0.456666143489.issue1578269@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The buildslaves most definitely will *not* execute any code under administrator privileges; doing so would put the machine under a serious threat.

The tests should be skipped if the privilege is not held; it may be reasonable to grant the privilege to the account the build slave runs under.

I'd appreciate if some piece of text explained how the privilege can be activated, other than invoking "run as administrator".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 06:43:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 05:43:59 +0000
Subject: [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: <1263793439.26.0.835225789398.issue7725@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7725>
_______________________________________

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: [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:42:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 08:42:00 +0000
Subject: [issue7729] min() working incorrectly for decimal and float values
In-Reply-To: <1263803679.58.0.0245965950297.issue7729@psf.upfronthosting.co.za>
Message-ID: <1263804120.68.0.635853886617.issue7729@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing as duplicate of #2531.

----------
nosy: +ezio.melotti, mark.dickinson
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
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: [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 09:50:22 2010
From: report at bugs.python.org (djc)
Date: Mon, 18 Jan 2010 08:50:22 +0000
Subject: [issue7730] ssl has bad coding style
In-Reply-To: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>
Message-ID: <1263804622.68.0.610315023487.issue7730@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7730>
_______________________________________

From report at bugs.python.org  Mon Jan 18 09:59:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Jan 2010 08:59:19 +0000
Subject: [issue4137] update SIG web pages
In-Reply-To: <1224230964.55.0.983457546691.issue4137@psf.upfronthosting.co.za>
Message-ID: <1263805159.94.0.744376762573.issue4137@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

By the way, where is the tracker for python.org websites?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4137>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:00:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 09:00:30 +0000
Subject: [issue7730] ssl has bad coding style
In-Reply-To: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>
Message-ID: <1263805230.18.0.108986671775.issue7730@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There should be no space between the name of the function and the '(' in both the cases. However the PEP 8 also says that "Consistency within one module or function is most important" and we usually avoid this kind of refactoring because they just make svn blame harder to use without having any real advantage.

----------
nosy: +ezio.melotti
priority:  -> low
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7730>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:02:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Jan 2010 09:02:49 +0000
Subject: [issue7730] ssl has bad coding style
In-Reply-To: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>
Message-ID: <1263805369.19.0.742718088668.issue7730@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think dropping the spaces after the function names is fine in this case; the module is inconsistent in this matter.

----------
nosy: +loewis
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7730>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:03:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 09:03:15 +0000
Subject: [issue4137] update SIG web pages
In-Reply-To: <1224230964.55.0.983457546691.issue4137@psf.upfronthosting.co.za>
Message-ID: <1263805395.91.0.271421358567.issue4137@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There's no bug tracker for the website, but you can send emails to <webmaster at python dot org> [1].

[1]: http://wiki.python.org/moin/PythonWebsiteCreatingNewTickets

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4137>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:17:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 09:17:19 +0000
Subject: [issue7730] ssl has bad coding style
In-Reply-To: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>
Message-ID: <1263806239.57.0.574288361316.issue7730@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Ok, done in r77595 (trunk), r77596 (release26-maint), r77597 (py3k) and r77598 (release31-maint).

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7730>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:20:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 18 Jan 2010 09:20:10 +0000
Subject: [issue7729] min() working incorrectly for decimal and float values
In-Reply-To: <1263803679.58.0.0245965950297.issue7729@psf.upfronthosting.co.za>
Message-ID: <1263806410.67.0.583619973376.issue7729@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
superseder:  -> float compared to decimal is silently incorrect.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7729>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:28:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Jan 2010 09:28:27 +0000
Subject: [issue3341] "Suggest a change" link
In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za>
Message-ID: <1263806907.38.0.739282706783.issue3341@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This functionality is specific request for python documentation, so adjustments should be made to Sphinx customization layer for docs.python.org if Sphinx itself doesn't provide such feature.

Is there a bug tracker for python.org infrastructure?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3341>
_______________________________________

From report at bugs.python.org  Mon Jan 18 10:34:14 2010
From: report at bugs.python.org (djc)
Date: Mon, 18 Jan 2010 09:34:14 +0000
Subject: [issue7730] ssl has bad coding style
In-Reply-To: <1263804609.87.0.315842318006.issue7730@psf.upfronthosting.co.za>
Message-ID: <1263807254.1.0.643804262682.issue7730@psf.upfronthosting.co.za>


djc <dirkjan at ochtman.nl> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7730>
_______________________________________

From report at bugs.python.org  Mon Jan 18 12:20:22 2010
From: report at bugs.python.org (sorin)
Date: Mon, 18 Jan 2010 11:20:22 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263813622.63.0.635646995841.issue1578269@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Maybe it's useful to know that Administrator privileges are not required in order be able to create symlinks. You just need a specific permission that by default is assigned only to Administrators.

How to set SeCreateSymbolicLinkPrivilege on Windows Vista or newer:
http://stackoverflow.com/questions/815472/how-do-i-grant-secreatesymboliclink-on-windows-vista-home-edition/2085468#2085468

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

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: [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 12:22:42 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 11:22:42 +0000
Subject: [issue7708] test_xmlrpc fails with non-ascii path
In-Reply-To: <1263576038.96.0.565214554799.issue7708@psf.upfronthosting.co.za>
Message-ID: <1263813762.41.0.816993759522.issue7708@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7708>
_______________________________________

From report at bugs.python.org  Mon Jan 18 12:43:37 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Jan 2010 11:43:37 +0000
Subject: [issue7731] Search is sluggish
In-Reply-To: <1263813756.21.0.177298019547.issue7731@psf.upfronthosting.co.za>
Message-ID: <1263815017.59.0.820603316266.issue7731@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It appears the doctools project is outdated and development for documentation generation tools moved to Sphinx project. Patch for Sphinx is in Sphinx bug tracker at http://bitbucket.org/birkenfeld/sphinx/issue/322/improve-search-responsiveness

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7731>
_______________________________________

From report at bugs.python.org  Mon Jan 18 12:49:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 11:49:24 +0000
Subject: [issue7731] Search is sluggish
In-Reply-To: <1263813756.21.0.177298019547.issue7731@psf.upfronthosting.co.za>
Message-ID: <1263815364.41.0.789322914357.issue7731@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Since you opened a new ticket in the sphinx bug tracker I'll close this one.

----------
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7731>
_______________________________________

From report at bugs.python.org  Mon Jan 18 12:58:33 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Jan 2010 11:58:33 +0000
Subject: [issue843590] 'macintosh' encoding alias for 'mac_roman'
Message-ID: <1263815913.95.0.104458193294.issue843590@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Here's another reference I found:

http://developer.apple.com/legacy/mac/library/documentation/mac/Text/Text-30.html

It appears that the "macintosh" encoding is the same as the MacRoman one, but without the character D9-FF. The document also suggests that it's a really old encoding.

Here's a comparison of various Mac Roman mappings:

http://www.haible.de/bruno/charsets/conversion-tables/Mac-Roman.html

These include the "macintosh" charset name as well.

For all practical purposes, it appears to be safe to alias "macintosh" to "mac-roman" and also add the other suggested aliases from the IANA registry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue843590>
_______________________________________

From report at bugs.python.org  Mon Jan 18 13:02:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Jan 2010 12:02:48 +0000
Subject: [issue7731] Search is sluggish
In-Reply-To: <1263813756.21.0.177298019547.issue7731@psf.upfronthosting.co.za>
Message-ID: <1263816168.89.0.0916210743687.issue7731@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I would keep this ticket open until the issue is fixed for docs.python.org

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7731>
_______________________________________

From report at bugs.python.org  Mon Jan 18 13:07:07 2010
From: report at bugs.python.org (Trundle)
Date: Mon, 18 Jan 2010 12:07:07 +0000
Subject: [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: [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 13:42:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 18 Jan 2010 12:42:45 +0000
Subject: [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: <1263818565.67.0.580543609197.issue7732@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed on trunk.

~ $ mkdir foo.py
~ $ ./python -c 'import imp;imp.find_module("foo", ["."])'
*** glibc detected *** ./python: double free or corruption (!prev): 0x00000000024a7390 ***
======= Backtrace: =========
(...)

----------
nosy: +flox
stage:  -> needs patch
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:29:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2010 13:29:46 +0000
Subject: [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: <1263821386.98.0.540435438486.issue7732@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Confirmed that this does not affect py3k.

----------
nosy: +brett.cannon, r.david.murray
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:34:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 18 Jan 2010 13:34:47 +0000
Subject: [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: <1263821687.93.0.275287968225.issue7732@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch proposed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:35:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 18 Jan 2010 13:35:27 +0000
Subject: [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: <1263821727.18.0.724835597455.issue7732@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file15936/issue7732_find_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:40:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 18 Jan 2010 13:40:28 +0000
Subject: [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: <1263822028.75.0.735085516545.issue7732@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15936/issue7732_find_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:40:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 18 Jan 2010 13:40:49 +0000
Subject: [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: <1263822049.05.0.652573864862.issue7732@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Removed the EnvironmentVarGuard from the test. It does not make sense.

----------
Added file: http://bugs.python.org/file15937/issue7732_find_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:47:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Jan 2010 13:47:07 +0000
Subject: [issue6095] os.curdir as the default argument for os.listdir
In-Reply-To: <1243122886.86.0.888741323334.issue6095@psf.upfronthosting.co.za>
Message-ID: <1263822427.81.0.914597677647.issue6095@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6095>
_______________________________________

From report at bugs.python.org  Mon Jan 18 14:56:37 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 13:56:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263822997.54.0.935658682658.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

When I consider that the buildslaves are probably donated and not designated exclusively for Python testing, it makes good sense that they typically run under a restricted account.

Given that there is a specific permission that can be assigned to the buildslave user, it seems appropriate that the tests that attempt to create symlinks should fail if the user does not have that permission.

Martin, do you still prefer something that wraps tests that call symlink and only executes those tests if the current user context has that permission?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:31:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 14:31:58 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1263825118.25.0.505790701809.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You could use the test skipping functionality present in trunk and beyond. Write a function to test whether the user has the necessary privileges, then use @unittest.skipUnless(has_admin_privs(), "can't test as regular user")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:35:19 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 14:35:19 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <1263825118.25.0.505790701809.issue1578269@psf.upfronthosting.co.za>
Message-ID: <DCBCF460-63DE-4F5B-87AD-E85C9FC5EDD0@jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Great suggestion. I'll do that.

----------
title: Add os.link() and os.symlink() and os.path.islink() support for Windows -> Add os.link() and os.symlink() and os.path.islink()	support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:40:37 2010
From: report at bugs.python.org (sorin)
Date: Mon, 18 Jan 2010 14:40:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263825637.72.0.969470798228.issue1578269@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

BTW, Is there any hope to add this to Python 2.6? - this is the standard on Windows and I see this issue more like a bug resolution than a new feature ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:42:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Jan 2010 14:42:04 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263825724.63.0.495546040771.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

No, it won't be backported to 2.6. It's clearly a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:44:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Jan 2010 14:44:35 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1263825875.84.0.779055985194.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

My concern about testing is that we're adding a feature that won't be tested by the buildbots. Although I don't have any suggestions (other than possibly adding the specific permission to the buildbots).

If there is a skip test, it should be dependent on the specific permission required. That is, it shouldn't test if the user is an administrator, it should test if the user has the permission to create links.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:44:50 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 14:44:50 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <1263825637.72.0.969470798228.issue1578269@psf.upfronthosting.co.za>
Message-ID: <D67B8A86984F00488D0776065BA56DBD5BB79E6324@Teach.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

If you want support for symlinks in Python 2.6, see 
http://pypi.python.org/pypi/jaraco.windows . It even has a method to monkey 
patch the os module to provide forward compatibility to the 3.2 functionality.

----------
Added file: http://bugs.python.org/file15938/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6890 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100118/f30ca5f7/attachment-0001.bin>

From report at bugs.python.org  Mon Jan 18 15:46:17 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 14:46:17 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <1263825875.84.0.779055985194.issue1578269@psf.upfronthosting.co.za>
Message-ID: <D67B8A86984F00488D0776065BA56DBD5BB79E6325@Teach.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Eric: I concur. The function to skip tests will test for the presence of the 
particular permission.

----------
Added file: http://bugs.python.org/file15939/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6890 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100118/6b1cba6f/attachment.bin>

From report at bugs.python.org  Mon Jan 18 15:51:35 2010
From: report at bugs.python.org (Stuart Shelton)
Date: Mon, 18 Jan 2010 14:51:35 +0000
Subject: [issue7718] Build shared libpythonX.Y.so on IRIX
In-Reply-To: <1263668830.38.0.370210056705.issue7718@psf.upfronthosting.co.za>
Message-ID: <1263826295.24.0.0985380710863.issue7718@psf.upfronthosting.co.za>


Stuart Shelton <srcshelton at gmail.com> added the comment:

I've no objection to signing the relevant paperwork if that's what's needed to get this committed - if someone could point me in the direction of what I needed to do in order to do so?

----------
nosy: +srcshelton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7718>
_______________________________________

From report at bugs.python.org  Mon Jan 18 15:56:35 2010
From: report at bugs.python.org (Stuart Shelton)
Date: Mon, 18 Jan 2010 14:56:35 +0000
Subject: [issue7717] Compilation fixes for IRIX
In-Reply-To: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>
Message-ID: <1263826595.14.0.347529769562.issue7717@psf.upfronthosting.co.za>


Stuart Shelton <srcshelton at gmail.com> added the comment:

As-per 7718 I'm happy to complete any relevant paperwork: these patches (which are by now of my own creation: Frank Everdij helped sort out the N32.s fixes, but these were no longer required by 2.6.4 and 2.7) are already posted in the public Gentoo bug-tracker, and clearly having them merged is the best solution all around.

Let me know what I need to do and I'll get on it.

----------
nosy: +srcshelton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7717>
_______________________________________

From report at bugs.python.org  Mon Jan 18 16:08:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 15:08:18 +0000
Subject: [issue7717] Compilation fixes for IRIX
In-Reply-To: <1263668634.91.0.221076005955.issue7717@psf.upfronthosting.co.za>
Message-ID: <1263827298.03.0.47354599357.issue7717@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

http://www.python.org/psf/contrib/ has the relevant contributor agreement.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7717>
_______________________________________

From report at bugs.python.org  Mon Jan 18 17:26:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2010 16:26:00 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263831960.71.0.30534386435.issue1670765@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See issue 1670765 for more discussion of the whitespace issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Mon Jan 18 17:29:12 2010
From: report at bugs.python.org (Daniel)
Date: Mon, 18 Jan 2010 16:29:12 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1263832152.26.0.776329845181.issue2698@psf.upfronthosting.co.za>


Daniel <daniel.mondon at free.fr> added the comment:

Sorry, I am on others problems and i don't have any time to look at a solution 
:(

Daniel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
_______________________________________

From report at bugs.python.org  Mon Jan 18 17:49:34 2010
From: report at bugs.python.org (Martin von Gagern)
Date: Mon, 18 Jan 2010 16:49:34 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263833374.96.0.332365113567.issue1670765@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

Wrong issue number again, or did you deliberately try to catch me in an infinite see-also loop? ;-)
I've tried to work out what issue you meant, but failed so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Mon Jan 18 18:06:05 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Mon, 18 Jan 2010 17:06:05 +0000
Subject: [issue5753] CVE-2008-5983 python: untrusted python modules search path
In-Reply-To: <1239709179.65.0.173847743531.issue5753@psf.upfronthosting.co.za>
Message-ID: <1263834365.61.0.375445781017.issue5753@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

Has anyone else had an opportunity to have a look at the change proposed in #msg90336?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5753>
_______________________________________

From report at bugs.python.org  Mon Jan 18 20:07:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2010 19:07:26 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1263841646.57.0.318185220219.issue1670765@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Heh.  Copy and paste error.  I copied the issue number I wanted to reference, then copied the issue number I needed to open in order to paste the reference, and then promptly forgot that I had to recopy the issue number to paste it...

Anyway, the correct cross reference is to issue 968430.  Thanks for keeping me accurate, again.  (Hopefully I did the copy and paste right this time....:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Mon Jan 18 21:28:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Jan 2010 20:28:32 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
In-Reply-To: <1263822997.54.0.935658682658.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4B54C46C.6050701@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Given that there is a specific permission that can be assigned to the
> buildslave user, it seems appropriate that the tests that attempt to
> create symlinks should fail if the user does not have that
> permission.

No, the test should *not* fail. A failing test means "the test has
completed, and the outcome was not expected, due to a bug somewhere
(the operating system, Python, or the test case proper)". This is not
the case if the link cannot be created - the resulting behavior is
exactly the correct, and expected one (under the circumstances).

> Martin, do you still prefer something that wraps tests that call
> symlink and only executes those tests if the current user context has
> that permission?

Most definitely. That's what the notion of a "skipped" test is for
(as opposed to a "failed" one).

----------
title: Add os.link() and os.symlink() and os.path.islink()	support for Windows -> Add os.link() and os.symlink() and os.path.islink() support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 21:33:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Jan 2010 20:33:57 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
In-Reply-To: <1263825875.84.0.779055985194.issue1578269@psf.upfronthosting.co.za>
Message-ID: <4B54C5B3.6020802@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If there is a skip test, it should be dependent on the specific permission required.

Terminology: it's a "privilege", not a "permission". Permissions (in
Windows) are stored in ACLs on objects, granted by the owner of the
object. Privileges are held by users, granted by the system
administrator.

----------
title: Add os.link() and os.symlink() and os.path.islink() support for Windows -> Add os.link() and os.symlink() and	os.path.islink() support for Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 21:40:09 2010
From: report at bugs.python.org (Christian Walther)
Date: Mon, 18 Jan 2010 20:40:09 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
	thread
Message-ID: <1263847209.29.0.854125082814.issue1596321@psf.upfronthosting.co.za>


Christian Walther <cwalther at users.sourceforge.net> added the comment:

I have the impression we're tracking two completely unrelated problems in this tracker item.

As to "needs patch" regarding my problem: Here's the solution I proposed in my original post in patch form - I'm just not sure if it is correct. I don't recommend applying this until someone who is familiar with the workings of the threading module has confirmed that removing self from _active is the right thing to do (and that what I'm doing is the accepted pythonic way of removing a dictionary entry by value).

Index: Lib/threading.py
===================================================================
--- Lib/threading.py    (revision 77598)
+++ Lib/threading.py    (working copy)
@@ -611,7 +611,11 @@
 
         try:
             with _active_limbo_lock:
-                del _active[_get_ident()]
+                for k, v in _active.iteritems():
+                    if v is self: break
+                else:
+                    assert False, "thread instance not found in _active"
+                del _active[k]
                 # There must not be any python code between the previous line
                 # and after the lock is released.  Otherwise a tracing function
                 # could try to acquire the lock again in the same thread, (in

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Mon Jan 18 21:47:12 2010
From: report at bugs.python.org (Charles Cazabon)
Date: Mon, 18 Jan 2010 20:47:12 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1263847632.84.0.1394084747.issue6963@psf.upfronthosting.co.za>


Changes by Charles Cazabon <charlesc-python at pyropus.ca>:


Removed file: http://bugs.python.org/file14987/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Mon Jan 18 21:48:54 2010
From: report at bugs.python.org (Charles Cazabon)
Date: Mon, 18 Jan 2010 20:48:54 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1263847734.0.0.92055814674.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

No problem, Jesse, I realize you're busy.  

I've updated the patch very slightly to handle an issue I had where the worker maintainer hung once.

----------
Added file: http://bugs.python.org/file15940/worker-lifetime-python2.6.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Mon Jan 18 22:14:28 2010
From: report at bugs.python.org (Nir Aides)
Date: Mon, 18 Jan 2010 21:14:28 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263849268.14.0.0692319616273.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Uploaded an updated patch with read() which calls underlying stream enough times to satisfy required read size.

----------
Added file: http://bugs.python.org/file15941/zipfile_7610_py27_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Mon Jan 18 23:02:25 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 22:02:25 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1263852145.58.0.792145835001.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15938/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Mon Jan 18 23:02:30 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 18 Jan 2010 22:02:30 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1263852150.89.0.0440211777726.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15939/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

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: [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:17:36 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Jan 2010 22:17:36 +0000
Subject: [issue7734] discuss mark-as-invalid trick in heapq docs
In-Reply-To: <1263852467.57.0.690062730163.issue7734@psf.upfronthosting.co.za>
Message-ID: <1263853056.96.0.0104662829775.issue7734@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Assigning to Raymond, per his request in the c.l.p. thread.

----------
assignee: georg.brandl -> rhettinger
nosy: +eric.smith

_______________________________________
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: [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:13:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Jan 2010 23:13:48 +0000
Subject: [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: <1263856428.22.0.927998470373.issue7735@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you propose a patch?

I personally consider this not worth the effort. Unless there is a DNS problem, this cases shouldn't really be noticable, as the socket module will immediately report that IPv6 is not supported (without even consulting the operating system). So if there is a problem, it must be with DNS, in which case I would rather recommend to fix the DNS setup.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7735>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:15:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 23:15:23 +0000
Subject: [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: <1263856523.12.0.989707007342.issue7735@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib) -None
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7735>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:24:12 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:24:12 +0000
Subject: [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:49 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 18 Jan 2010 23:24:49 +0000
Subject: [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 00:24:50 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:24:50 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263857090.97.0.733608863589.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file15943/call_hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:24:57 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:24:57 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263857097.48.0.384793705145.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file15944/hello_ll.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:25:05 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:25:05 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263857105.69.0.791719511774.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file15945/libfuse26.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:25:12 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:25:12 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263857112.26.0.589164283392.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file15946/libfuse28.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:39:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Jan 2010 23:39:28 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263857968.52.0.686434103376.issue7610@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks rather good. Is `self.MAX_N` still necessary in read()? I guess it's rare to read more than 2GB at once, though...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:42:02 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:42:02 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263858122.69.0.957882934786.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file15947/call_hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:42:11 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:42:11 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263858131.16.0.941465633296.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Removed file: http://bugs.python.org/file15943/call_hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:45:28 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:45:28 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263858328.43.0.582284595499.issue7736@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Reproduced with Python 3.1

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:46:21 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:46:21 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263858381.86.0.138495593718.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Removed file: http://bugs.python.org/file15947/call_hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:46:27 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 18 Jan 2010 23:46:27 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263858387.61.0.69298654665.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file15948/call_hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 00:51:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jan 2010 23:51:37 +0000
Subject: [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: <1263858697.7.0.632723645003.issue7737@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
nosy: +brian.curtin
priority:  -> low
stage:  -> patch review
type:  -> feature request
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7737>
_______________________________________

From report at bugs.python.org  Tue Jan 19 01:13:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Jan 2010 00:13:15 +0000
Subject: [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: <1263859995.0.0.758681529471.issue7737@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Applied in r77604.

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7737>
_______________________________________

From report at bugs.python.org  Tue Jan 19 03:12:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2010 02:12:02 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1263867122.32.0.871631813698.issue7472@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I suspect that that typo is fortunate rather than the source of a bug.  As far as I can see, if a message contains valid iso-2022 characters, it will always encode to ASCII successfully and therefore be given a content-transfer-encoding of 7bit.  If on the other hand it contains 8 bit characters, it should be marked as 8bit, even if it claims to be iso-2022.  (Well, actually it should throw an error, but that's a different bug.)

In other words, I think the correct thing to do is to delete that if test.

Do you have a case where the code produces incorrect behavior that your patch turns into correct behavior?

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7472>
_______________________________________

From report at bugs.python.org  Tue Jan 19 03:12:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jan 2010 02:12:27 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1263867147.52.0.490030138351.issue7472@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7472>
_______________________________________

From report at bugs.python.org  Tue Jan 19 04:22:17 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jan 2010 03:22:17 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1263871337.4.0.110422955518.issue3426@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Passes on Windows, Mac, and Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Tue Jan 19 04:30:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jan 2010 03:30:23 +0000
Subject: [issue6293] Have regrtest.py echo back sys.flags
In-Reply-To: <1245173731.34.0.991251966726.issue6293@psf.upfronthosting.co.za>
Message-ID: <1263871823.5.0.776812853104.issue6293@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Seems like a good idea to me, but maybe not as the default?

----------
keywords: +needs review
nosy: +brian.curtin
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6293>
_______________________________________

From report at bugs.python.org  Tue Jan 19 07:55:42 2010
From: report at bugs.python.org (Nir Aides)
Date: Tue, 19 Jan 2010 06:55:42 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1263884142.87.0.233168838374.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Right, removed MAX_N from read(); remains in read1().
If good, what versions of Python is this patch desired for?

----------
Added file: http://bugs.python.org/file15949/zipfile_7610_py27_v6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Tue Jan 19 09:14:07 2010
From: report at bugs.python.org (Yukihiro Nakadaira)
Date: Tue, 19 Jan 2010 08:14:07 +0000
Subject: [issue7472] email.encoders.encode_7or8bit(): typo "iso-2202".
	"iso-2022" is correct.
In-Reply-To: <1260466982.74.0.0519719914389.issue7472@psf.upfronthosting.co.za>
Message-ID: <1263888847.52.0.450629285423.issue7472@psf.upfronthosting.co.za>


Yukihiro Nakadaira <yukihiro.nakadaira at gmail.com> added the comment:

> In other words, I think the correct thing to do is to delete that if test.

I think so too.

> Do you have a case where the code produces incorrect behavior that your patch turns into correct behavior?

No, I don't.  I just found a typo.

The code for "iso-2022" was added by issue #804885.  But I don't know why it was requested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7472>
_______________________________________

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: [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: [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 10:59:20 2010
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 19 Jan 2010 09:59:20 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1263895160.09.0.623148449067.issue4194@psf.upfronthosting.co.za>


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


----------
nosy: +guettli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Tue Jan 19 11:07:54 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 19 Jan 2010 10:07:54 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263895674.73.0.855261657965.issue7723@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

As far as I can see the docs for Python 3.x need to be adjusted. In particular http://docs.python.org/3.1/library/sqlite3.html#sqlite-and-python-types

buffer should then there probably be replaced by memoryview. As far as I can see, the Python 3 definition of the old "buffer" interface is "anything that I can apply memoryview to". At least that was my interpretation when doing the Python 3 port of the sqlite3 module.

Correct?

When returning BLOBs, the sqlite3 module now returns bytes objects. I think this could be changed to memoryview without causing any problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Tue Jan 19 14:09:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jan 2010 13:09:55 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1263906595.83.0.607210271058.issue7723@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello Gerhard,

> As far as I can see, the Python 3 definition of the old "buffer"
> interface is "anything that I can apply memoryview to".

Roughly, yes.

> When returning BLOBs, the sqlite3 module now returns bytes objects. I
> think this could be changed to memoryview without causing any problems.

No, returning bytes objects is the right thing to do under py3k. This "bug" report is only about 2.x, where "bytes" is the same as "str" and therefore doesn't allow to distinguish text from binary data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

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: [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 14:50:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jan 2010 13:50:32 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1263909032.36.0.172184603624.issue4194@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can someone check if this still applies to Python 3.1/3.2?
By the way, I see no reason not to buffer at least the subprocess's stdout and stderr streams.

----------
versions:  -Python 2.4, Python 2.5, Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Tue Jan 19 14:51:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 19 Jan 2010 13:51:41 +0000
Subject: [issue7740] Complete your registration to Jython tracker --
	key9LzwsWHYNjTaULhZpojHxtdciVg1jFYL
Message-ID: <1263909101.74.0.824336683397.issue7740@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7740>
_______________________________________

From report at bugs.python.org  Tue Jan 19 14:54:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 19 Jan 2010 13:54:01 +0000
Subject: [issue7740] was spam
Message-ID: <1263909241.54.0.994696844161.issue7740@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: Complete your registration to Jython tracker -- key9LzwsWHYNjTaULhZpojHxtdciVg1jFYL -> was spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7740>
_______________________________________

From report at bugs.python.org  Tue Jan 19 14:54:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jan 2010 13:54:48 +0000
Subject: [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: <1263909288.12.0.590965641347.issue7739@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You might want to investigate which C library call opens this file, and propose a patch to release the GIL before doing that call. As far as I can tell, Python itself does not open /etc/localtime in any place.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Tue Jan 19 15:03:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jan 2010 14:03:28 +0000
Subject: [issue7738] IDLE hang when tooltip comes up in Linux
In-Reply-To: <1263889833.11.0.812168606755.issue7738@psf.upfronthosting.co.za>
Message-ID: <1263909808.98.0.0469675337248.issue7738@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7738>
_______________________________________

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: [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 15:58:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jan 2010 14:58:57 +0000
Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push
In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za>
Message-ID: <1263913137.68.0.987073134196.issue7741@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7741>
_______________________________________

From report at bugs.python.org  Tue Jan 19 16:06:35 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 19 Jan 2010 15:06:35 +0000
Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push
In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za>
Message-ID: <1263913595.54.0.980193095319.issue7741@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Note, there are no regression tests for the code module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7741>
_______________________________________

From report at bugs.python.org  Tue Jan 19 16:09:08 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 19 Jan 2010 15:09:08 +0000
Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push
In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za>
Message-ID: <1263913748.62.0.306440480764.issue7741@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is how to test this manually:
from code import InteractiveConsole
c = InteractiveConsole()
s = "if True:\n  print 1\nprint 2"
c.push(s)  #fails
c.push(s, "exec")  #succeeds

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7741>
_______________________________________

From report at bugs.python.org  Tue Jan 19 16:12:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 19 Jan 2010 15:12:34 +0000
Subject: [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: <1263913954.47.0.478613131166.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15907/temp_cwd_decorator.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Tue Jan 19 16:15:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 19 Jan 2010 15:15:01 +0000
Subject: [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: <1263914101.79.0.767589805983.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Changed, after review from Ezio and other developpers.

----------
Added file: http://bugs.python.org/file15951/temp_cwd_decorator_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Tue Jan 19 16:42:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jan 2010 15:42:03 +0000
Subject: [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: <1263915723.98.0.849829308999.issue7712@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

with_writable_cwd should probably use functools.wraps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Tue Jan 19 16:47:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Jan 2010 15:47:13 +0000
Subject: [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: <1263916033.04.0.683890696135.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch looks good, I'd just move _test_cwd inside the function and drop the [:-3] from TESTFN, but apart from that it's OK. I also agree that functools.wraps should be added.

To summarize the discussion we had on #python-dev:
1) the context manager should always create a writable cwd and to be able to run with -J it should contain the process id. Using TESTFN as first-level dir solves both the issues;
2) a suffix is added to TESTFN to let the tests use TESTFN as a valid filename;
3) the second-level dir is 'tempcwd' by default or can be passed to the function in case a test needs a specific name for the cwd;

The result will be something like '@test_xxxx_tmp_cwd/dirname'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Tue Jan 19 17:14:58 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 19 Jan 2010 16:14:58 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1263917698.72.0.540273593655.issue4194@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Looks good to me:

tmp% python3.1 popentest.py
time with os.popen :  0.035565
time with subprocess.Popen :  0.031796
tmp% python3.2 popentest.py
time with os.popen :  0.03501
time with subprocess.Popen :  0.031168
tmp% python3.1
Python 3.1.1+ (release31-maint:77485M, Jan 13 2010, 19:53:41)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
tmp% python3.2
Python 3.2a0 (py3k:77484:77485, Jan 13 2010, 19:49:33)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4194>
_______________________________________

From report at bugs.python.org  Tue Jan 19 17:47:30 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 19 Jan 2010 16:47:30 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1263919650.47.0.658750657693.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm currently struggling with determining if the host process has the appropriate privileges. I'm stuck in that I've enumerated the privileges for an admin account, but the SeCreateSymbolicLink privilege is not present. I guess it's inherited. If you have any suggestions for determining access, please consider posting a response at http://stackoverflow.com/questions/2094663/determine-if-windows-process-has-permission-to-create-symbolic-link .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Jan 19 18:03:04 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 19 Jan 2010 17:03:04 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1263920584.55.0.155729733442.issue1578269@psf.upfronthosting.co.za>


Changes by Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:


----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Jan 19 18:33:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 19 Jan 2010 17:33:49 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1263922429.76.0.631649580527.issue1578269@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO we could just catch the WindowsError, and skip the test if its winerror attribute is 1314 (=ERROR_PRIVILEGE_NOT_HELD).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Jan 19 19:02:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 19 Jan 2010 18:02:50 +0000
Subject: [issue5684] test_zipfile writes in its test directory
In-Reply-To: <1238833190.77.0.866792563675.issue5684@psf.upfronthosting.co.za>
Message-ID: <1263924170.58.0.373432349755.issue5684@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch using the proposed context manager (#7712).

----------
keywords: +patch
nosy: +flox
Added file: http://bugs.python.org/file15952/issue5684_test_zipfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5684>
_______________________________________

From report at bugs.python.org  Tue Jan 19 19:06:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Jan 2010 18:06:10 +0000
Subject: [issue5684] test_zipfile writes in its test directory
In-Reply-To: <1238833190.77.0.866792563675.issue5684@psf.upfronthosting.co.za>
Message-ID: <1263924370.29.0.477274942279.issue5684@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
keywords: +needs review
priority: low -> normal
stage: needs patch -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5684>
_______________________________________

From report at bugs.python.org  Tue Jan 19 21:27:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 19 Jan 2010 20:27:46 +0000
Subject: [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: <1263932866.67.0.955366058986.issue7739@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd also be curious why it takes a second to open /etc/localtime. That sounds like a bug in the C library, or a mismanaged system.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Tue Jan 19 22:02:42 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 19 Jan 2010 21:02:42 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263934962.28.0.23269903229.issue7736@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Here's the backtrace:

#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x00007fcd0234a6e8 in PyThread_acquire_lock (lock=0x183f3f0, waitflag=128) at Python/thread_pthread.h:349
#2  0x00007fcd02311fa4 in PyEval_RestoreThread (tstate=0x17a9b00) at Python/ceval.c:356
#3  0x00007fcd02336a28 in PyGILState_Ensure () at Python/pystate.c:592
#4  0x00007fcd013fcec1 in _CallPythonObject (cif=0x183f3f0, resp=0x80, args=0x7fccff153f40, userdata=<value optimized out>)
    at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/callbacks.c:220
#5  closure_fcn (cif=0x183f3f0, resp=0x80, args=0x7fccff153f40, userdata=<value optimized out>)
    at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/callbacks.c:374
#6  0x00007fcd014044f0 in ffi_closure_unix64_inner (closure=<value optimized out>, rvalue=<value optimized out>, reg_args=0x246, argp=0x0)
    at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/libffi/src/x86/ffi64.c:566
#7  0x00007fcd01404b68 in ffi_closure_unix64 () at /home/marcin/Desktop/python/python2.x-hg/Modules/_ctypes/libffi/src/x86/unix64.S:230
#8  0x00007fccff572429 in ?? () from /lib/libfuse.so.2
#9  0x00007fccff5704fa in fuse_session_loop () from /lib/libfuse.so.2
#10 0x00007fccff1576e4 in ?? ()
#11 0x00007fccff154188 in ?? ()
#12 0x00007fccff3580e0 in ?? ()
#13 0x000000000192e2f0 in ?? ()
#14 0x0000000400000000 in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00000000016ff5e0 in ?? ()
#17 0x0000000000000001 in ?? ()
#18 0x0000000000000000 in ?? ()

All calls to native POSIX functions seem to be wrapped with Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS except of opendir() and closedir(). When I fix it (as in attached patch), call_hello.py doesn't block anymore.

----------
keywords: +patch
nosy: +marcin.bachry
Added file: http://bugs.python.org/file15953/posix-opendir-and-gil.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 22:32:03 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 19 Jan 2010 21:32:03 +0000
Subject: [issue7736] ctypes freezes/deadlocks process
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263936723.22.0.772990816998.issue7736@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Wow, great! Thanks for looking into this. How did you manage to get the backtrace? As I said, on my system gdb -p just hangs with when attaching.

I'm changing the component, since it seems that it's the os module that's at fault and not ctypes.

----------
components: +Library (Lib) -ctypes
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 22:33:28 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 19 Jan 2010 21:33:28 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263936808.53.0.661551681846.issue7736@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
title: ctypes freezes/deadlocks process -> os.listdir hangs since opendir() and closedir() do not release GIL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 22:36:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jan 2010 21:36:42 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263937002.35.0.00882525946771.issue7736@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
nosy: +brian.curtin
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Jan 19 22:36:55 2010
From: report at bugs.python.org (Doron Tal)
Date: Tue, 19 Jan 2010 21:36:55 +0000
Subject: [issue7739] time.strftime may hung while trying to open
	/etc/localtime but does not release GIL
In-Reply-To: <1263932866.67.0.955366058986.issue7739@psf.upfronthosting.co.za>
Message-ID: <2a8674c61001191336s64d0c0ccjb31b47f35addd498@mail.gmail.com>


Doron Tal <doron.tal.list at gmail.com> added the comment:

We didn't prove this point yet, currently it's merely circumstantial.
The application calls strftime few dozen times each second from different
threads. We spot the stall using another two threads, the first takes a time
stamp before calling a python function and reset the time stamp when the
python function is done. The other thread watches the timestamp and if it
gets over a certain limit (2 seconds) it aborts the process, leaving a core
dump behind.

We've build this infrastructure to tackle python stalls caused by
misbehaving C calls which takes long but does not release the GIL.

Here is the traceback (one of the threads):

#0  0x0000003424ac5800 in __open_nocancel () from /lib64/libc.so.6

#1  0x0000003424a6c383 in __GI__IO_file_open () from /lib64/libc.so.6

#2  0x0000003424a6c43c in _IO_new_file_fopen () from /lib64/libc.so.6

#3  0x0000003424a61764 in __fopen_internal () from /lib64/libc.so.6

#4  0x0000003424a8d666 in __tzfile_read () from /lib64/libc.so.6

#5  0x0000003424a8c56f in tzset_internal () from /lib64/libc.so.6

#6  0x0000003424a8d010 in tzset () from /lib64/libc.so.6

#7  0x0000003424a91934 in strftime_l () from /lib64/libc.so.6

#8  0x00002aea01bced34 in ?? () from

/usr/lib64/python2.4/lib-dynload/timemodule.so

#9  0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0 #10 0x0000003430436bbc in PyObject_CallMethod
() from /usr/lib64/libpython2.4.so.1.0

#11 0x00002aea01dda64a in ?? () from

/usr/lib64/python2.4/lib-dynload/datetime.so

#12 0x00002aea01dda9c3 in ?? () from

/usr/lib64/python2.4/lib-dynload/datetime.so

#13 0x00000034304950ba in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#14 0x0000003430494b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#15 0x0000003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0

#16 0x000000343044c45a in ?? () from /usr/lib64/libpython2.4.so.1.0

#17 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#18 0x000000343049352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#19 0x0000003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0 #20 0x000000343044c45a in ?? () from
/usr/lib64/libpython2.4.so.1.0

#21 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#22 0x000000343049352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#23 0x0000003430494b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0

#24 0x0000003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0

#25 0x000000343044c367 in ?? () from /usr/lib64/libpython2.4.so.1.0

#26 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#27 0x000000343043c1ef in ?? () from /usr/lib64/libpython2.4.so.1.0

#28 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0

#29 0x000000343048fc3d in PyEval_CallObjectWithKeywords () from
/usr/lib64/libpython2.4.so.1.0 #30 0x00000034304bbbbd in ?? () from
/usr/lib64/libpython2.4.so.1.0

#31 0x00000034256064a7 in start_thread () from /lib64/libpthread.so.0

#32 0x0000003424ad3c2d in clone () from /lib64/libc.so.6

So, we didn't actually proved that opening /etc/localtime takes so long. I
assumed that it is better to release the GIL prior to opening a file.

In any case, it won't solve our problem, since we use old Python 2.4.3
(CentOS5.4)...

--doron

On Tue, Jan 19, 2010 at 10:27 PM, Martin v. L??wis <report at bugs.python.org>wrote:

>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> I'd also be curious why it takes a second to open /etc/localtime. That
> sounds like a bug in the C library, or a mismanaged system.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7739>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file15954/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________
-------------- next part --------------
<div dir="ltr">We didn&#39;t prove this point yet, currently it&#39;s merely circumstantial.<br>The application calls strftime few dozen times each second from different threads. We spot the stall using another two threads, the first takes a time stamp before calling a python function and reset the time stamp when the python function is done. The other thread watches the timestamp and if it gets over a certain limit (2 seconds) it aborts the process, leaving a core dump behind.<br>
<br>We&#39;ve build this infrastructure to tackle python stalls caused by misbehaving C calls which takes long but does not release the GIL.<br><br>Here is the traceback (one of the threads):<br><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 12"><meta name="Originator" content="Microsoft Word 12"><link rel="File-List" href="file:///C:%5CDOCUME%7E1%5Cdoron.tal%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml"><link rel="themeData" href="file:///C:%5CDOCUME%7E1%5Cdoron.tal%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"><link rel="colorSchemeMapping" href="file:///C:%5CDOCUME%7E1%5Cdoron.tal%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml"><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;
	mso-font-alt:"Calisto MT";
	mso-font-charset:0;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:-1610611985 1107304683 0 0 159 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-alt:"Century Gothic";
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1610611985 1073750139 0 0 159 0;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:modern;
	mso-font-pitch:fixed;
	mso-font-signature:-1610611985 1073750091 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:Arial;
	mso-bidi-theme-font:minor-bidi;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.5pt;
	font-family:Consolas;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-bidi-font-family:Arial;
	mso-bidi-theme-font:minor-bidi;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Plain Text";
	mso-ansi-font-size:10.5pt;
	mso-bidi-font-size:10.5pt;
	font-family:Consolas;
	mso-ascii-font-family:Consolas;
	mso-hansi-font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:Arial;
	mso-bidi-theme-font:minor-bidi;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>

<p class="MsoPlainText">#0<span style="">??
</span>0x0000003424ac5800 in __open_nocancel () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#1<span style="">??
</span>0x0000003424a6c383 in __GI__IO_file_open () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#2<span style="">??
</span>0x0000003424a6c43c in _IO_new_file_fopen () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#3<span style="">??
</span>0x0000003424a61764 in __fopen_internal () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#4<span style="">??
</span>0x0000003424a8d666 in __tzfile_read () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#5<span style="">??
</span>0x0000003424a8c56f in tzset_internal () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#6<span style="">??
</span>0x0000003424a8d010 in tzset () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#7<span style="">??
</span>0x0000003424a91934 in strftime_l () from /lib64/libc.so.6</p>

<p class="MsoPlainText">#8<span style="">?? </span>0x00002aea01bced34
in ?? () from</p>

<p class="MsoPlainText">/usr/lib64/python2.4/lib-dynload/timemodule.so</p>

<p class="MsoPlainText">#9<span style="">??
</span>0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0 #10 0x0000003430436bbc in PyObject_CallMethod ()
from /usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#11 0x00002aea01dda64a in ?? () from</p>

<p class="MsoPlainText">/usr/lib64/python2.4/lib-dynload/datetime.so</p>

<p class="MsoPlainText">#12 0x00002aea01dda9c3 in ?? () from</p>

<p class="MsoPlainText">/usr/lib64/python2.4/lib-dynload/datetime.so</p>

<p class="MsoPlainText">#13 0x00000034304950ba in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#14 0x0000003430494b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#15 0x0000003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#16 0x000000343044c45a in ?? () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#17 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#18 0x000000343049352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#19 0x0000003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0 #20 0x000000343044c45a in ?? () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#21 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#22 0x000000343049352c in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#23 0x0000003430494b66 in PyEval_EvalFrame () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#24 0x0000003430495fe5 in PyEval_EvalCodeEx () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#25 0x000000343044c367 in ?? () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#26 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#27 0x000000343043c1ef in ?? () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#28 0x00000034304360f0 in PyObject_Call () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#29 0x000000343048fc3d in PyEval_CallObjectWithKeywords
() from /usr/lib64/libpython2.4.so.1.0 #30 0x00000034304bbbbd in ?? () from
/usr/lib64/libpython2.4.so.1.0</p>

<p class="MsoPlainText">#31 0x00000034256064a7 in start_thread () from
/lib64/libpthread.so.0</p>

<p class="MsoPlainText">#32 0x0000003424ad3c2d in clone () from /lib64/libc.so.6</p>

<p class="MsoPlainText">??</p>

So, we didn&#39;t actually proved that opening /etc/localtime takes so long. I assumed that it is better to release the GIL prior to opening a file.<br><br>In any case, it won&#39;t solve our problem, since we use old Python 2.4.3 (CentOS5.4)...<br>
<br>--doron<br><br><div class="gmail_quote">On Tue, Jan 19, 2010 at 10:27 PM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<br>
I&#39;d also be curious why it takes a second to open /etc/localtime. That sounds like a bug in the C library, or a mismanaged system.<br>
<br>
----------<br>
nosy: +loewis<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7739" target="_blank">http://bugs.python.org/issue7739</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Tue Jan 19 23:15:52 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Tue, 19 Jan 2010 22:15:52 +0000
Subject: [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  Tue Jan 19 23:18:44 2010
From: report at bugs.python.org (Michael Haubenwallner)
Date: Tue, 19 Jan 2010 22:18:44 +0000
Subject: [issue7742] please avoid 'which' in Modules/ld_so_aix
In-Reply-To: <1263939351.94.0.865840686982.issue7742@psf.upfronthosting.co.za>
Message-ID: <1263939524.86.0.445204269319.issue7742@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

Uhm, as I read the patch again, there's room for improvement of pywhich():
it likely fails with CC=/full/path/to/cc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7742>
_______________________________________

From report at bugs.python.org  Tue Jan 19 23:48:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 19 Jan 2010 22:48:32 +0000
Subject: [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: <1263941312.42.0.600548570078.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Different approach, after some other talks with Ezio and David.

Now the directory is changed before running any test.
The developer can assume that the current directory if always writable.
It makes the tests easier to write, and repeatable.

Additionally, TESTFN always contains a single filename (without path).
Before this change, it could be "/tmp/@test" or "@test", which is error-prone.

The decorator becomes useless.

----------
Added file: http://bugs.python.org/file15956/issue7712_context_manager.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Wed Jan 20 00:16:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jan 2010 23:16:45 +0000
Subject: [issue7742] please avoid 'which' in Modules/ld_so_aix
In-Reply-To: <1263939351.94.0.865840686982.issue7742@psf.upfronthosting.co.za>
Message-ID: <1263943005.63.0.681351988368.issue7742@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +None
keywords: +needs review
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7742>
_______________________________________

From report at bugs.python.org  Wed Jan 20 11:57:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jan 2010 10:57:10 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263985030.25.0.484319592331.issue7736@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 12:11:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jan 2010 11:11:42 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263985902.49.0.634528444266.issue7736@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Releasing the GIL when calling C library functions (e.g. opendir()) is not a requirement, it's just an optimization for slightly better multi-threading. Also, as shown in the backtrace, PyGILState_Ensure() is called which should only try to acquire the GIL if it isn't already held by the current thread; that is, it is designed to avoid the deadlock you are witnessing.

So, I would suggest the problem lies somewhere else. Does FUSE implicitly do a fork() of the current process? It's not obvious how the example shown here works.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 12:30:17 2010
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 20 Jan 2010 11:30:17 +0000
Subject: [issue3599] test_pydoc after test_urllib2 causes exception in
	Popen.__del__
In-Reply-To: <1219157315.63.0.32622319144.issue3599@psf.upfronthosting.co.za>
Message-ID: <1263987017.07.0.692052548574.issue3599@psf.upfronthosting.co.za>


Yinon Ehrlich <yinoneh at users.sourceforge.net> added the comment:

I saw this error in my scripts when using Python 2.5 on Ubuntu.
When imported trunk version instead of Python2.5 one, it disappeared.

So it's fixed in subprocess - def __del__

----------
nosy: +Yinon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3599>
_______________________________________

From report at bugs.python.org  Wed Jan 20 12:49:07 2010
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 20 Jan 2010 11:49:07 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1263988147.25.0.493515007128.issue5115@psf.upfronthosting.co.za>


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


----------
nosy: +guettli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Wed Jan 20 13:04:11 2010
From: report at bugs.python.org (Jeong-Min Lee)
Date: Wed, 20 Jan 2010 12:04:11 +0000
Subject: [issue5879] multiprocessing - example "pool of http servers " fails
	on windows "socket has no attribute fromfd"
In-Reply-To: <1241019482.48.0.575158847578.issue5879@psf.upfronthosting.co.za>
Message-ID: <1263989051.45.0.0749691153866.issue5879@psf.upfronthosting.co.za>


Changes by Jeong-Min Lee <falsetru at gmail.com>:


----------
nosy: +falsetru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5879>
_______________________________________

From report at bugs.python.org  Wed Jan 20 13:12:12 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 20 Jan 2010 12:12:12 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263989532.89.0.00442189156209.issue7736@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

In this simple example, FUSE does not fork and does not start any threads.

Note that PyGILState_Ensure() cannot do anything here. What happens is this:

 - call_hello.py calls FUSE in a new thread, releasing the GIL.
 - FUSE mounts the file system and waits for requests
 - Meanwhile, in the main thread, call_hello.py calls opendir(), but does not release the GIL
 - FUSE receives the opendir() system call and calls the appropriate callback function
 - If the callback function is implemented in C, everything works fine.
 - If the callback function is implemented in Python, the FUSE thread tries to acquire the GIL to call the (Python) opendir() handler. But it cannot do so, because the GIL is still held by the main thread (which is waiting for the opendir syscall to return) => deadlock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 13:19:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jan 2010 12:19:19 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263989532.89.0.00442189156209.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263990026.3297.4.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, thanks for the explanation. Yes indeed the patch looks ok for the
job. You should just be aware that similar problems may appear with
other system calls. I don't think we have ever considered that common C
calls such as opendir() could call back into Python code through
libraries such as FUSE.

By the way, it seems there are Python bindings for FUSE, in two
different flavours. You might want to look into them, and perhaps to
check whether they also experience this issue.

Le mercredi 20 janvier 2010 ? 12:12 +0000, Nikolaus Rath a ?crit :
> Nikolaus Rath <Nikolaus at rath.org> added the comment:
> 
> In this simple example, FUSE does not fork and does not start any threads.
> 
> Note that PyGILState_Ensure() cannot do anything here. What happens is this:
> 
>  - call_hello.py calls FUSE in a new thread, releasing the GIL.
>  - FUSE mounts the file system and waits for requests
>  - Meanwhile, in the main thread, call_hello.py calls opendir(), but does not release the GIL
>  - FUSE receives the opendir() system call and calls the appropriate callback function
>  - If the callback function is implemented in C, everything works fine.
>  - If the callback function is implemented in Python, the FUSE thread tries to acquire the GIL to call the (Python) opendir() handler. But it cannot do so, because the GIL is still held by the main thread (which is waiting for the opendir syscall to return) => deadlock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 13:38:06 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 20 Jan 2010 12:38:06 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do not
	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263991086.26.0.639345659942.issue7736@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

I have used both of them in the past, but in the end I wrote my own bindings (currently only available as part of the http://code.google.com/p/s3ql source code, but I intend to factor it out at some point), 
since neither fuse.py (http://code.google.com/p/fusepy) nor python-fuse (fuse.sf.net) support the FUSE low level API.

That said, I am reasonably sure that in both of them are affected by this bug too. However, it may not show up in practive very often, because the high level FUSE API by default forks into a background process before mounting the file system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 13:44:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2010 12:44:32 +0000
Subject: [issue7710] Inconsistent Exception for int() conversion
In-Reply-To: <1263584123.75.0.822719915688.issue7710@psf.upfronthosting.co.za>
Message-ID: <1263991472.07.0.388987764562.issue7710@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7710>
_______________________________________

From report at bugs.python.org  Wed Jan 20 13:45:23 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 20 Jan 2010 12:45:23 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263990026.3297.4.camel@localhost>
Message-ID: <4B56FAD1.30405@rath.org>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

On 01/20/2010 07:19 AM, Antoine Pitrou wrote:
> Ah, thanks for the explanation. Yes indeed the patch looks ok for the
> job. You should just be aware that similar problems may appear with
> other system calls. I don't think we have ever considered that common C
> calls such as opendir() could call back into Python code through
> libraries such as FUSE.

Well, now that I know what to look for, tracking down more of these 
problems should be significantly faster and easier. Are you generally 
going to accept similar patches for other unprotected syscalls?

Still, I'd be extremly grateful if someone could tell me the trick how 
to create a backtrace in such a deadlock situation... Or am I the only 
one for which a simple "gdb -a" does not work?

Best,

    -Nikolaus

----------
title: os.listdir hangs since opendir() and closedir() do not release GIL -> os.listdir hangs since opendir() and closedir() do not	release GIL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 14:03:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jan 2010 13:03:52 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <4B56FAD1.30405@rath.org>
Message-ID: <1263992699.3297.11.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, now that I know what to look for, tracking down more of these 
> problems should be significantly faster and easier. Are you generally 
> going to accept similar patches for other unprotected syscalls?

Until now the rule of thumb was to consider only time-consuming syscalls
(as I said, the primary goal is optimizing multi-threaded I/O). But I
guess we can accept such patches if they have no downsides. Martin, what
do you think?

> Still, I'd be extremly grateful if someone could tell me the trick how 
> to create a backtrace in such a deadlock situation... Or am I the only 
> one for which a simple "gdb -a" does not work?

Perhaps you can try to crash the process (using `kill -ABRT`) and then
load the core dump using gdb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

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: [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 14:14:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 20 Jan 2010 13:14:39 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1263993279.93.0.26718859523.issue7743@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

From report at bugs.python.org  Wed Jan 20 14:29:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 20 Jan 2010 13:29:25 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1263994165.76.0.903893690472.issue7743@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, it's not that difficult to trigger (2).  With the bigcomp functionality disabled as above:

AssertionError: Incorrectly rounded str->float conversion for 11651287494059419563861790709256988151903479322938522856916519154189084656466977171489691608488398792047332126810029685763620092606534076968286334920536334924763766067178320990794927368304039797998410780646182269333271282839761794603623958163297658510063352026077076106072540390412314438457161207373275477458821194440646557259102208197382844892733860255628785183174541939743301249188486945446244053689504749943655197464973191717009938776287102040358299419343976193341216682148401588363162253931420379903449798213003874174172790742957567330246138038659650118748200625752770984217933648838167281879845022933912352785884444833681591202045229462491699354638895656152216187535257259042082360747878839946016222830869374205287663441403533948204085390898399055004119873046875e-1075: expected 0x0.0d67b36890cfcp-1022, got 0x0.0d67b36890cfbp-1022

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

From report at bugs.python.org  Wed Jan 20 15:02:52 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Wed, 20 Jan 2010 14:02:52 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1263996172.35.0.332412908395.issue7736@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

> Still, I'd be extremly grateful if someone could tell me the trick how 
to create a backtrace in such a deadlock situation

Sorry, I should have mentioned that. In order to get backtrace you let the process freeze, attach gdb to it (it will freeze too), then go to /sys/fs/fuse/connections/ and find your fuse connection (it's most likely the one with non-zero value in "waiting" file). Then do "echo 1 > abort" and go back to gdb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Jan 20 17:14:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Jan 2010 16:14:24 +0000
Subject: [issue2015] Possible optimisations in kwargs handling
In-Reply-To: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>
Message-ID: <1264004064.49.0.658002743146.issue2015@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This was handled in r65241 as a result of #1819.

----------
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Speed hack for function calls with named parameters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2015>
_______________________________________

From report at bugs.python.org  Wed Jan 20 18:03:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Jan 2010 17:03:15 +0000
Subject: [issue1479611] speed up function calls
Message-ID: <1264006995.91.0.064840403012.issue1479611@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
stage:  -> patch review
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1479611>
_______________________________________

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: [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  Wed Jan 20 22:21:58 2010
From: report at bugs.python.org (Chris Lasher)
Date: Wed, 20 Jan 2010 21:21:58 +0000
Subject: [issue7744] Allow site.addsitedir insert to beginning of sys.path
In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za>
Message-ID: <1264022518.87.0.10141380153.issue7744@psf.upfronthosting.co.za>


Chris Lasher <chris.lasher at gmail.com> added the comment:

One correction: by "beginning of sys.path", what I really mean is, "the portion of sys.path after the initial ''". I forgot that '', the empty path, should always be at the start of sys.path to ensure that packages and modules in the current working directory are given top priority. Thus, I would like to see insertions between sys.path[0] and sys.path[1].

Sorry for the confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7744>
_______________________________________

From report at bugs.python.org  Thu Jan 21 00:04:11 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 20 Jan 2010 23:04:11 +0000
Subject: [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 01:29:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 00:29:32 +0000
Subject: [issue5115] Extend subprocess.kill to be able to kill process groups
In-Reply-To: <1233370260.58.0.70597374825.issue5115@psf.upfronthosting.co.za>
Message-ID: <1264033772.27.0.206832952432.issue5115@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I suspect that on Windows, TerminateJobObject won't work 
> with a handle returned by CreateProcess.

TerminateJobObject works with CreateJobObject and AssignProcessToJobObject. The following code (from your patch) should call AssignProcessToJobObject (and CreateJobObject if there is no job yet):

+                    if not mswindows:
+                        os.setpgid(0, 0)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5115>
_______________________________________

From report at bugs.python.org  Thu Jan 21 01:55:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jan 2010 00:55:23 +0000
Subject: [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: <1264035323.23.0.00863391264135.issue7745@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7745>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:01:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 01:01:24 +0000
Subject: [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: <1264035684.82.0.743374128308.issue7739@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It appears that the stall happens due to time.strftime call, which internally opens 
> a file ('/etc/localtime')

In the GNU libc, strftime() calls tzset() and tzset() uses a lock to be thread safe. Yes, releasing the GIL before calling strftime() would speed up your use case.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:21:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 01:21:08 +0000
Subject: [issue7720] Errors in tests and C implementation of raw FileIO
In-Reply-To: <1263678361.41.0.947080196973.issue7720@psf.upfronthosting.co.za>
Message-ID: <1264036868.74.0.16632077396.issue7720@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

IOTest.test_destructor() is already fixed in Python trunk (future 2.7) by r73394 (Issue #6215: backport the 3.1 io lib).

I don't think that it would be possible to backport the 3.1 io lib in Python 2.6. Would it possible to backport only the io tests?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7720>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:24:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Jan 2010 01:24:34 +0000
Subject: [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: <1264037074.65.0.0232314995851.issue7745@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As discussed on python-dev, this patch should probably be rejected.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7745>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:34:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 01:34:30 +0000
Subject: [issue7708] test_xmlrpc fails with non-ascii path
In-Reply-To: <1263576038.96.0.565214554799.issue7708@psf.upfronthosting.co.za>
Message-ID: <1264037670.24.0.373332454687.issue7708@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

SimpleXMLRPCRequestHandler.do_POST() writes the traceback in the HTTP header "X-traceback". But an HTTP header value is ASCII only, whereas a traceback can contain any character (eg. an non-ASCII character from a directory name for this issue).

A simple fix would be to use the ASCII charset with the backslashreplace error handler. Attached patch uses:

   trace = str(trace.encode('ASCII', 'backslashreplace'), 'ASCII')

Is there an easier method to escape non-ASCII characters without double conversion (unicode->bytes and bytes->unicode)?

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file15958/xmlrpc_server_ascii_traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7708>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:37:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 01:37:06 +0000
Subject: [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: <1264037826.89.0.385385065394.issue7739@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15954/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:37:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 01:37:43 +0000
Subject: [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: <1264037863.77.0.0346620071323.issue7739@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here you have a patch releasing the GIL for the call to strftime().

----------
keywords: +patch
Added file: http://bugs.python.org/file15959/time_strftime_gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:47:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 01:47:41 +0000
Subject: [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: <1264038461.13.0.415585193159.issue7739@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

time_tzset() might also release the GIL, but:
 - i hope that multithreaded programs don't call regulary tzset() in different threads
 - time_tzset() calls tzset() and inittimezone()
 - inittimezone() modify the time module attributes and may call tzset() (depending on the OS / C library). it's also called from inittime()

So I prefer to leave it unchanged :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7739>
_______________________________________

From report at bugs.python.org  Thu Jan 21 02:51:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jan 2010 01:51:42 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1264038702.48.0.238859695433.issue4722@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15265/issue4722_20091104_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4722>
_______________________________________

From report at bugs.python.org  Thu Jan 21 03:00:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jan 2010 02:00:24 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1264039224.4.0.075282234085.issue4722@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

On Windows 7, I see the issue as both a regular user and one with admin privileges. The patch (updated to fix tab/space difference) seems to do the trick. 
Gabriel, which OS are you on that this works differently based on the user privileges?

I'm still not sure how to test this...not sure how to modify the binary data and leave it blank via code.

----------
Added file: http://bugs.python.org/file15960/issue4722.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4722>
_______________________________________

From report at bugs.python.org  Thu Jan 21 03:09:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 02:09:12 +0000
Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 )
In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>
Message-ID: <1264039752.71.0.672686679677.issue7727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Marshaller.dump_string() encodes a byte string in <string>...</string> using the escape() function. A byte string can be encoded in base64 using <base64>...</base64>. It's described in the XML-RPC specification, but I don't know if all XML-RPC implementations do understand this type.
http://www.xmlrpc.com/spec

Should we change the default type to base64, or only fallback to base64 if the byte string cannot be encoded in XML. Test if a byte string can be encoded in XML can be slow, and set default type to base64 may cause compatibility issues :-/

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7727>
_______________________________________

From report at bugs.python.org  Thu Jan 21 03:15:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 02:15:04 +0000
Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 )
In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>
Message-ID: <1264040104.19.0.336247171262.issue7727@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is an example of patch using the following test:

   all(32 <= ord(byte) <= 127 for byte in value)

I don't know how much slower is the patch, but at least it doesn't raise an "ExpatError: not well-formed (invalid token): ...".

----------
keywords: +patch
Added file: http://bugs.python.org/file15961/xmlrpc_byte_string.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7727>
_______________________________________

From report at bugs.python.org  Thu Jan 21 03:26:23 2010
From: report at bugs.python.org (Steven Hartland)
Date: Thu, 21 Jan 2010 02:26:23 +0000
Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 )
In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za>
Message-ID: <1264040783.74.0.644813597581.issue7727@psf.upfronthosting.co.za>


Steven Hartland <steven.hartland at multiplay.co.uk> added the comment:

One thing that springs to mind is how valid is that when applied to utf8 data?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7727>
_______________________________________

From report at bugs.python.org  Thu Jan 21 03:59:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 02:59:33 +0000
Subject: [issue7668] test_httpservers fails with non-ascii path
In-Reply-To: <1263147324.56.0.696076411083.issue7668@psf.upfronthosting.co.za>
Message-ID: <1264042771.3.0.456592237963.issue7668@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

CGIHTTPServerTestCase creates .py files with sys.executable in a shebang:
-----
cgi_file1 = """\
#!%s
..."""

with open(self.file1_path, 'w') as file1:
    file1.write(cgi_file1 % sys.executable)
-----
The shebang have to be the first line, and the encoding cookie (#coding:...) have to be written before any non-ASCII character. Since the shebang contains non-ASCII character, the cookie have to be written before... which is impossible.

Whereas issue #7708 contains the tested modules, this issue is specific to the tests themself.

Possible workaround: create a symbolic link to an ASCII directory (eg. "/tmp/python") and use the link in the shebang.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7668>
_______________________________________

From report at bugs.python.org  Thu Jan 21 04:34:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 03:34:36 +0000
Subject: [issue7667] test_doctest fails with non-ascii path
In-Reply-To: <1263147113.71.0.132140640007.issue7667@psf.upfronthosting.co.za>
Message-ID: <1264044876.16.0.265310040409.issue7667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There are 2 different issues:
 * doctest.DocTestRunner.report_failure() raise an unicode error if the source line type is unicode: _failure_header() should convert the line to bytes using ASCII with backslashreplace error handler (as sys.stderr)
 * traceback.print_tb() raises an unicode error if the source line type is unicode: same solution (ASCII+bashslashreplace)

See also #Issue7708.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file15962/test_doctest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7667>
_______________________________________

From report at bugs.python.org  Thu Jan 21 07:01:53 2010
From: report at bugs.python.org (Justin Lebar)
Date: Thu, 21 Jan 2010 06:01:53 +0000
Subject: [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: [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 08:48:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jan 2010 07:48:02 +0000
Subject: [issue7747] Function variable wrongly reported unassigned
In-Reply-To: <1264059159.7.0.610108234991.issue7747@psf.upfronthosting.co.za>
Message-ID: <1264060082.21.0.949030246211.issue7747@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is not a bug, see http://docs.python.org/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7747>
_______________________________________

From report at bugs.python.org  Thu Jan 21 12:17:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 11:17:36 +0000
Subject: [issue4221] inconsistent exception from int is confusing
In-Reply-To: <1225213917.89.0.391557406226.issue4221@psf.upfronthosting.co.za>
Message-ID: <1264072656.86.0.331614774145.issue4221@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #7710.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4221>
_______________________________________

From report at bugs.python.org  Thu Jan 21 12:20:15 2010
From: report at bugs.python.org (Adrian May)
Date: Thu, 21 Jan 2010 11:20:15 +0000
Subject: [issue7747] Function variable wrongly reported unassigned
In-Reply-To: <1264059159.7.0.610108234991.issue7747@psf.upfronthosting.co.za>
Message-ID: <1264072815.08.0.657025613406.issue7747@psf.upfronthosting.co.za>


Adrian May <adrian.alexander.may at gmail.com> added the comment:

OK, Thanks. Sorry for the hassle.

Adrian.

----------
type: behavior -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7747>
_______________________________________

From report at bugs.python.org  Thu Jan 21 12:30:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 11:30:30 +0000
Subject: [issue5905] strptime fails in non-UTF locale
In-Reply-To: <1241277441.59.0.031362936917.issue5905@psf.upfronthosting.co.za>
Message-ID: <1264073430.62.0.605155344147.issue5905@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce the error. I tried locales fr_FR.iso88591 and fr_FR.iso885915 at euro (fr_FR at euro), but the example works correctly. Should the terminal use the specified locale? My terminal uses fr_FR.utF8 locale. Should set_locale() be called before loaded time and/or calendar module?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5905>
_______________________________________

From report at bugs.python.org  Thu Jan 21 12:36:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 11:36:16 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1264073776.12.0.0804724692875.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Sum up of my patch:

 * it pass all test_thread*.py tests (tested with in pydebug mode)
 * it preallocates the thread state in the parent thread to be able to raise an error with PyErr_NoMemory() instead of Py_FatalError()
 * PyThreadState_Prealloc() doesn't call _PyGILState_NoteThreadState() because the thread ident is not correct in the parent thread
 * Call _PyGILState_NoteThreadState() in the new thread to finish the thread initialization
 * Py_InitializeEx() calls _PyGILState_Init() before initsite(), because initsite() may create a thread

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Thu Jan 21 12:38:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 11:38:48 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1264073928.66.0.567445257334.issue7267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #7649.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7267>
_______________________________________

From report at bugs.python.org  Thu Jan 21 12:43:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2010 11:43:49 +0000
Subject: [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: <1264074229.94.0.303216008009.issue7649@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Ezio: Your patch leaks a reference: PyUnicode_FromString(...) is not destroyed (Py_DECREF) on success.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Thu Jan 21 16:17:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jan 2010 15:17:03 +0000
Subject: [issue7747] Function variable wrongly reported unassigned
In-Reply-To: <1264059159.7.0.610108234991.issue7747@psf.upfronthosting.co.za>
Message-ID: <1264087023.36.0.0876360458677.issue7747@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7747>
_______________________________________

From report at bugs.python.org  Thu Jan 21 20:03:37 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 21 Jan 2010 19:03:37 +0000
Subject: [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: <1264100617.17.0.169600917887.issue7745@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7745>
_______________________________________

From report at bugs.python.org  Thu Jan 21 20:09:28 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jan 2010 19:09:28 +0000
Subject: [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: <1264100968.03.0.676692918402.issue7745@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7745>
_______________________________________

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: [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:00:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jan 2010 21:00:55 +0000
Subject: [issue7746] Nit: Extra comma in itertools doc
In-Reply-To: <1264053712.92.0.276864246454.issue7746@psf.upfronthosting.co.za>
Message-ID: <1264107655.25.0.268364038339.issue7746@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77675 (trunk), r77676 (release26-maint), r77677 (py3k) and r77678 (release31-maint).

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7746>
_______________________________________

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: [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 22:26:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Jan 2010 21:26:43 +0000
Subject: [issue7749] pydoc error
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264109203.35.0.135477029443.issue7749@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I can?t reproduce your bug.

Please specify exact Python version, how you installed it, whether you did something unusual with the lib directory, and any other useful information.

Kind regards

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Thu Jan 21 22:42:33 2010
From: report at bugs.python.org (Gib Bogle)
Date: Thu, 21 Jan 2010 21:42:33 +0000
Subject: [issue7749] pydoc error
In-Reply-To: <1264109203.35.0.135477029443.issue7749@psf.upfronthosting.co.za>
Message-ID: <4B58CA43.1000506@auckland.ac.nz>


Gib Bogle <g.bogle at auckland.ac.nz> added the comment:

Hi Eric,

I'm using Python 2.5.4 on Windows XP.  I installed pythonxy, which installed 
2.5.4.  I also have PyQt4.4 installed.  I haven't touched anything in the lib 
directory, as far as I know.

A poster on comp.lang.python finds the command works on one machine, but not on 
another.  Look for the post entitled "pyexe and pydocs.Downloads?"

Cheers
Gib

Dr. Gib Bogle
Senior Research Fellow
Auckland Bioengineering Institute
University of Auckland
New Zealand

http://www.bioeng.auckland.ac.nz

g.bogle at auckland.ac.nz
(64-9) 373-7599 Ext. 87030

?ric Araujo wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Hello
> 
> I can?t reproduce your bug.
> 
> Please specify exact Python version, how you installed it, whether you did something unusual with the lib directory, and any other useful information.
> 
> Kind regards
> 
> ----------
> nosy: +Merwok
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7749>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Thu Jan 21 22:45:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jan 2010 21:45:16 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264110316.22.0.745149889529.issue7749@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not seeing this on 2.5, 2.6, or trunk.

----------
components: +Extension Modules
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
title: pydoc error -> pydoc error - "No module named tempfile"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Thu Jan 21 22:53:56 2010
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Thu, 21 Jan 2010 21:53:56 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1264110836.58.0.138617444311.issue2202@psf.upfronthosting.co.za>


Manuel Murad?s <mmuradas at dieresys.com.ar> added the comment:

Here is a patch for supporting MD5-sess, following RFC2617 specification.

Some comments/warnings:
 * I've only tested the patch against IIS 6.0. I don't know about other servers supporting MD5-sess.
 * IIS 6.0 expects the User Agent to send the URI (in the Authorization header) without the query string.
 * This patch doesn't add support for Digest sessions. 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 sessions to be fully supported, we should be adding an [WWW|Proxy]-Authenticate header in each following request we made to the server using the last nonce. This includes both MD5-sess and MD5 digest implementations.
 * A1 is being recalculated for every request. Given the above, this is not a real problem.

I'll open a new ticket regarding Digest sessions.

----------
keywords: +patch
nosy: +dieresys
Added file: http://bugs.python.org/file15964/urllib2-support_md5-sess.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

From report at bugs.python.org  Thu Jan 21 22:55:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jan 2010 21:55:55 +0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1264110955.66.0.904244414098.issue2202@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
_______________________________________

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: [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:18:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jan 2010 22:18:45 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264112325.88.0.539896914396.issue7749@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Under 2.5 this could be due to various weird issues with your python path and the modules on it.  Try running python from a clean directory and specifying the -E flag and see if the behavior changes, and/or try importing tempfile at the python prompt and see if you get a more useful message.

Under 2.7 I think pydoc handles this better.  Note that even if you find a bug in 2.5 it no longer receives bug fixes, so you'd also have to be able to reproduce it in 2.6.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Thu Jan 21 23:38:14 2010
From: report at bugs.python.org (Gib Bogle)
Date: Thu, 21 Jan 2010 22:38:14 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264112325.88.0.539896914396.issue7749@psf.upfronthosting.co.za>
Message-ID: <4B58D742.5040404@auckland.ac.nz>


Gib Bogle <g.bogle at auckland.ac.nz> added the comment:

R. David Murray wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Under 2.5 this could be due to various weird issues with your python path and the modules on it.  Try running python from a clean directory and specifying the -E flag and see if the behavior changes, and/or try importing tempfile at the python prompt and see if you get a more useful message.
> 
> Under 2.7 I think pydoc handles this better.  Note that even if you find a bug in 2.5 it no longer receives bug fixes, so you'd also have to be able to reproduce it in 2.6.
> 
> ----------
> nosy: +r.david.murray
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7749>
> _______________________________________

I previously had 2.6 installed, removed it for compatibility with something. 
Maybe I did something wrong.  It isn't a big issue for me, I just reported it 
because someone suggested I should.  I plan to upgrade to 2.6 soon anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Thu Jan 21 23:55:26 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 21 Jan 2010 22:55:26 +0000
Subject: [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:55 2010
From: report at bugs.python.org (=?utf-8?q?Manuel_Murad=C3=A1s?=)
Date: Thu, 21 Jan 2010 23:47:55 +0000
Subject: [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 01:06:50 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 00:06:50 +0000
Subject: [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: <1264118810.66.0.0520136647787.issue7750@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You can see the same thing by doing execfile(".\test.py"), which is what pdb makes under the hood, then bdb exec's it.

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 01:16:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 00:16:56 +0000
Subject: [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: <1264119416.88.0.0465960732369.issue7751@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Fri Jan 22 01:45:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 00:45:41 +0000
Subject: [issue7752] Add support for Digest authentication session (reuse
	nonces)
In-Reply-To: <1264117674.74.0.518658840947.issue7752@psf.upfronthosting.co.za>
Message-ID: <1264121141.73.0.673167424046.issue7752@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2

_______________________________________
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: [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 02:46:05 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 01:46:05 +0000
Subject: [issue7750] IOError in execfile with backslash in path
In-Reply-To: <1264112305.65.0.888456425139.issue7750@psf.upfronthosting.co.za>
Message-ID: <1264124765.76.0.00226533326016.issue7750@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
title: IOError when launching script under pdb with backslash in script path -> IOError in execfile with backslash in path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:00:32 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 02:00:32 +0000
Subject: [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: <1264125632.27.0.430209412745.issue7750@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm changing the title back to the original title. I don't believe the problem is reproducible using execfile. That is, if a properly-escaped path is passed to execfile, it works fine.

So I believe the problem lies between when pdb takes control and where execfile is called - the command-line is not properly parsed.

----------
title: IOError in execfile with backslash in path -> IOError when launching script under pdb with backslash in script path

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:02:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 02:02:00 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264125720.96.0.253972962521.issue7753@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> high
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:08:33 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 02:08:33 +0000
Subject: [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: <1264126113.03.0.23438241758.issue7750@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I suspect this patch may fix the problem. I haven't yet had time to test it.

Index: Lib/pdb.py
===================================================================
--- Lib/pdb.py  (revision 77683)
+++ Lib/pdb.py  (working copy)
@@ -1200,7 +1200,7 @@
         self._wait_for_mainpyfile = 1
         self.mainpyfile = self.canonic(filename)
         self._user_requested_quit = 0
-        statement = 'execfile( "%s")' % filename
+        statement = 'execfile(%r)' % filename
         self.run(statement)

 # Simplified interface

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:15:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 02:15:23 +0000
Subject: [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: <1264126523.36.0.959656198429.issue7750@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Works for me, repr will escape the slash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

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: [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 03:24:11 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 22 Jan 2010 02:24:11 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1264127051.61.0.899336934748.issue7658@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> RONALD: I've committed a fix for this in r77585, please test.

Verified on Tiger with 10.4u SDK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7658>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:32:22 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 02:32:22 +0000
Subject: [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: <1264127542.54.0.0453651327402.issue7750@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The attached test-case identifies the failure mode (and verifies that the proposed fix corrects the issue).

----------
Added file: http://bugs.python.org/file15968/test_pdb.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:47:54 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 22 Jan 2010 02:47:54 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264128474.7.0.325223088595.issue7753@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:49:42 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 22 Jan 2010 02:49:42 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1264128582.08.0.126276470223.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm working on this now; I'm going to need to port the patch to trunk before moving forward with it. Shouldn't take me long.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:55:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Jan 2010 02:55:24 +0000
Subject: [issue7754] decimal.Decimal 0.0**0.0 error
In-Reply-To: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>
Message-ID: <1264128924.4.0.718628695308.issue7754@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Library (Lib)
nosy: +mark.dickinson
priority:  -> normal
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7754>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:55:56 2010
From: report at bugs.python.org (Mike Crute)
Date: Fri, 22 Jan 2010 02:55:56 +0000
Subject: [issue6457] subprocess.Popen.communicate can lose data from
	output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1264128956.07.0.173898727041.issue6457@psf.upfronthosting.co.za>


Mike Crute <mcrute at gmail.com> added the comment:

Bump. Updated the patch against trunk.

----------
nosy: +mcrute
Added file: http://bugs.python.org/file15969/broken_pipe.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________

From report at bugs.python.org  Fri Jan 22 03:59:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 02:59:53 +0000
Subject: [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: <1264129193.05.0.212546281894.issue7750@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you add your test to Lib/test/test_pdb.py?

If the test fails the "hello world" script won't be removed, it won't make it to os.remove(). You'll need to make sure the file gets deleted in any case. Could use a temporary file.

Can you condense the cmd stuff into less lines? Super minor thing, but it's all short lines anyways.

Rather than testing using failIf, assertFalse is a better alternative. In 2.7 there is assertIn which would be ideal for this test, but this will go into 2.6 as well.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 04:02:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 03:02:19 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264129339.79.0.164734847792.issue7753@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 04:38:59 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 22 Jan 2010 03:38:59 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264131539.91.0.795677005231.issue7749@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

On Windows, trying with different Python versions:

D:\temp>python24 -m pydoc sys
[works as expected]

D:\temp>python25 -m pydoc sys
No module named tempfile

D:\temp>python26 -m pydoc sys
No module named tempfile

D:\temp>python27 -m pydoc sys
[works as expected]


If tempfile.py is in the current directory, it works:

D:\temp>cd \apps\python26\lib

D:\apps\Python26\Lib>dir /b tempfile.py
tempfile.py

D:\apps\Python26\Lib>python26 -m pydoc sys
Help on built-in module sys:
...


Directly executing pydoc.py works fine too:

D:\temp>d:\apps\Python26\lib\pydoc.py sys
Help on built-in module sys:
...


so this may be a runpy issue, not directly related to pydoc.

----------
nosy: +gagenellina

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Fri Jan 22 04:52:50 2010
From: report at bugs.python.org (Gib Bogle)
Date: Fri, 22 Jan 2010 03:52:50 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264112325.88.0.539896914396.issue7749@psf.upfronthosting.co.za>
Message-ID: <4B59210C.2040907@auckland.ac.nz>


Gib Bogle <g.bogle at auckland.ac.nz> added the comment:

Importing tempfile from within python does not produce an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Fri Jan 22 05:04:13 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 22 Jan 2010 04:04:13 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264133053.81.0.176442018908.issue7753@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Looks like the 2.7 patch has a spurious change to /Lib/unittest/runner.py.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 05:37:45 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 22 Jan 2010 04:37:45 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264135065.3.0.820913560594.issue7749@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

This happens to be a duplicate of issue #7328 -- pydoc used to remove the Python standard library from sys.path (!) when run with -m

Fixed in r76312 (2.7). I think the fix should be backported to 2.6

@gib: you may patch your Python 2.5 installation yourself, it's very simple, you'll have to add a single line and reindent a block, that's all. See r76312

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Fri Jan 22 06:38:20 2010
From: report at bugs.python.org (Shawn Ligocki)
Date: Fri, 22 Jan 2010 05:38:20 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1264138700.08.0.387054106892.issue7076@psf.upfronthosting.co.za>


Shawn Ligocki <sligocki at gmail.com> added the comment:

ping

Please look at the last patch. It's very simple and would be helpful. This is not very complicated and shouldn't take months to consider.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7076>
_______________________________________

From report at bugs.python.org  Fri Jan 22 09:38:51 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 22 Jan 2010 08:38:51 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264149531.03.0.363216107479.issue7753@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 09:42:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Jan 2010 08:42:49 +0000
Subject: [issue7138] elementtree segfaults on invalid xml declaration
In-Reply-To: <1255585052.13.0.483709817013.issue7138@psf.upfronthosting.co.za>
Message-ID: <1264149769.9.0.467123508866.issue7138@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was merged into 2.6 with r74432, into 2.5 with r77666, into 3.1 with r74436.

----------
assignee:  -> jyasskin
nosy: +jyasskin
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7138>
_______________________________________

From report at bugs.python.org  Fri Jan 22 09:46:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Jan 2010 08:46:02 +0000
Subject: [issue7754] decimal.Decimal 0.0**0.0 error
In-Reply-To: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>
Message-ID: <1264149962.46.0.770527886096.issue7754@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report.  Unfortunately, this behaviour is by design:  the decimal module follows the specification at

http://speleotrove.com/decimal/decarith.html

See particularly:

http://speleotrove.com/decimal/daops.html#refpower

<rant> Yes, I think this is wrong too, particularly since (a) it's inconsistent with Decimal('Inf')**Decimal('0.0') giving Decimal('1') and (b) it's inconsistent with other established standards like IEEE 754-2008 and C99 Annex F.  And that's before getting into arguments about how a simple power operation is *not* the same thing as an indeterminate form, and how Decimal is also supposed to be usable for pure integer arithmetic, where having 0**0 be anything other than 1 is horrible.  I made these points to the author of the specification some time ago, but he was regrettably unmoved.  :)  </rant>

Ultimately, I don't think it's a big enough issue to justify breaking compliance with the specification.

----------
assignee:  -> mark.dickinson
nosy: +skrah
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7754>
_______________________________________

From report at bugs.python.org  Fri Jan 22 10:32:33 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Jan 2010 09:32:33 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264152753.17.0.656147876949.issue7753@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

A few things:

 * The ceval_gil.h file is missing from the patch.

 * Please check whether you can move these variable declarations inside the main loop function (as statics):

+/* This single variable consolidates all requests to break out of the fast path
+   in the eval loop. */
+static volatile int eval_breaker = 0;
+/* Request for droppping the GIL */
+static volatile int gil_drop_request = 0;
+/* Request for running pending calls */
+static volatile int pendingcalls_to_do = 0; 
+/* Request for looking at the `async_exc` field of the current thread state */
+static volatile int pending_async_exc = 0;

 * Instead of deprecating the set/getcheckinterval APIs, convert the arguments passed to these to the switch interval. The new APIs set/getswitchinteral are then not needed.

 * Please add the fallback solutions from the time module in case gettimeofday() is not available. You cannot assume that "all modern POSIX systems" implement that API - it was introduced in POSIX 2001 and Python 2.x still supports OSes that were released prior to that year.

 * Note that gettimeofday() et al. are rather slow APIs on most systems. It would be better to directly use a simple performance timer since we don't really need any timing accuracy in managing the GIL when run with threads. Have a look at the clock_gettime() API for ways of accessing such timers. There may also be other ways of accessing such times via pthreads.

 * I haven't looked at the timing details of the implementation, but please make sure that it works even if the clock interval is a few ms (while gettimeofday() provides us resolution, the system clock may still only tick in ms intervals - another reason to use CPU performance timers instead).

Thanks.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 10:34:15 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Jan 2010 09:34:15 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264152855.05.0.65796805053.issue7753@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

See Tools/pybench/systimes.py for more comments on clocks, ticks and update frequency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

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: [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 13:14:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Jan 2010 12:14:25 +0000
Subject: [issue7754] decimal.Decimal 0.0**0.0 error
In-Reply-To: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>
Message-ID: <1264162465.35.0.0929949428962.issue7754@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Now that I think about it, this could be 'fixed' without breaking compliance:  all the specification requires is that a power function with the specified behaviour is present *somewhere* in the decimal module;  it needn't be linked to the ** operator.  So there could be two versions of power in decimal.py:  one version (called Decimal.power) that strictly conforms to the specification, and another (Decimal.__pow__) that's identical in every way except that it returns Decimal('1') for Decimal('0.0')**0.

While we're at it, we could also 'fix' Decimal.__pos__ and Decimal.__neg__ similarly:  the standard requires operations 'plus' and 'minus', with the slightly surprising (to me, at least) properties that plus(-0.0) = 0.0 and minus(0.0) = 0.0  (for both these, -0.0 seems more natural);  but there's no requirement that Python's __pos__ and __neg__ be identical to these.

But these changes would come with all the usual costs: extra code, tests and documentation, future maintenance costs, possibility of introducing bugs, user confusion, possible backwards compatibility issues,...  So there would have to be some significant perceived benefits to outweigh the costs.

Perhaps a discussion on the python-dev mailing list would be in order?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7754>
_______________________________________

From report at bugs.python.org  Fri Jan 22 15:23:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jan 2010 14:23:28 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264170208.67.0.155651352106.issue7753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>  * Instead of deprecating the set/getcheckinterval APIs, convert the
> arguments passed to these to the switch interval. The new APIs
> set/getswitchinteral are then not needed.

This is certainly not a good idea. The semantics are different, which is the reason why I created a separate API in the first place instead of recycling the old one.

Actually, there should be hardly any reason to want to change the interval with the new GIL implementation. It was required with the old GIL due to the fact that counting opcodes is a very poor way of estimating wall clock durations.

> Note that gettimeofday() et al. are rather slow APIs on most systems

In my measurements under Linux it seemed to be as fast as clock_gettime() actually. But I don't know about other systems. I didn't want to complicate the patch (with several different paths) more than seemed necessary.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 15:24:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 14:24:21 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1264170261.16.0.807368504409.issue7076@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7076>
_______________________________________

From report at bugs.python.org  Fri Jan 22 15:34:54 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 14:34:54 +0000
Subject: [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: <1264170894.47.0.400481033917.issue7750@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Here's a new patch against the trunk that addresses Brian's concerns.

----------
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file15970/fix with test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 15:46:32 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 14:46:32 +0000
Subject: [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: <1264171592.65.0.129643860483.issue7750@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

For completeness, I've back-ported the patch to the release26-maint branch.

----------
Added file: http://bugs.python.org/file15971/fix with test (releas26-maint).patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

From report at bugs.python.org  Fri Jan 22 15:46:36 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 Jan 2010 14:46:36 +0000
Subject: [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: <1264171596.98.0.00420204958278.issue7750@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15968/test_pdb.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7750>
_______________________________________

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: [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 15:56:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 22 Jan 2010 14:56:25 +0000
Subject: [issue7756] Complete your registration to Python tracker --
	key	rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf
In-Reply-To: <4B59BC6A.4070802@cbnco.com>
Message-ID: <1264172185.23.0.0399458206979.issue7756@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> low
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7756>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:08:34 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Fri, 22 Jan 2010 15:08:34 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1264172914.37.0.141323066478.issue7490@psf.upfronthosting.co.za>


Changes by Lennart Regebro <regebro at gmail.com>:


Removed file: http://bugs.python.org/file15538/python-trunk-exception-detail.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:08:39 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Fri, 22 Jan 2010 15:08:39 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1264172919.83.0.165559603132.issue7490@psf.upfronthosting.co.za>


Changes by Lennart Regebro <regebro at gmail.com>:


Removed file: http://bugs.python.org/file15537/python-py3k-exception-detail.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:09:11 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Fri, 22 Jan 2010 15:09:11 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1264172951.69.0.139394951723.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

New diff for trunk, with the additional test

----------
Added file: http://bugs.python.org/file15972/python-trunk-exception-detail.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:09:31 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Fri, 22 Jan 2010 15:09:31 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1264172971.85.0.166662075035.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

Could you please provide any advise on this bug?
I've submitted my patch, would be curious if there any chance to get it merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:15:44 2010
From: report at bugs.python.org (Lennart Regebro)
Date: Fri, 22 Jan 2010 15:15:44 +0000
Subject: [issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
In-Reply-To: <1260702702.76.0.177643280777.issue7490@psf.upfronthosting.co.za>
Message-ID: <1264173344.59.0.401973007993.issue7490@psf.upfronthosting.co.za>


Lennart Regebro <regebro at gmail.com> added the comment:

New diff for Py3k with the additional test

----------
Added file: http://bugs.python.org/file15973/python-py3k-exception-detail.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7490>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:29:21 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 22 Jan 2010 15:29:21 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264174161.98.0.0524970150465.issue7753@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Here is an updated set of patches that includes the ceval_gil.h file as well as the documentation changes.

----------
Added file: http://bugs.python.org/file15974/gil-2.7.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 16:44:48 2010
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 22 Jan 2010 15:44:48 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264175088.88.0.861467496782.issue7753@psf.upfronthosting.co.za>


Changes by Kevin Watters <kevinwatters at gmail.com>:


----------
nosy: +kevinwatters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 17:10:01 2010
From: report at bugs.python.org (David W. Lambert)
Date: Fri, 22 Jan 2010 16:10:01 +0000
Subject: [issue7076] Documentation add note about SystemRandom
In-Reply-To: <1254894491.86.0.615800723933.issue7076@psf.upfronthosting.co.za>
Message-ID: <1264176601.19.0.579525894824.issue7076@psf.upfronthosting.co.za>


David W. Lambert <b49P23TIvg at stny.rr.com> added the comment:

I recall an experience with a random file in /dev that was considerably slow after consuming its cache.  I used it as a seeder.  I've now got an ubuntu system for which /dev/urandom gives me a hundred million bytes quickly.  Perhaps a nosy one has more information?

----------
nosy: +LambertDW

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7076>
_______________________________________

From report at bugs.python.org  Fri Jan 22 17:11:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Jan 2010 16:11:37 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1264176697.19.0.264314825953.issue7242@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

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: [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 18:06:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Jan 2010 17:06:31 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1264179991.82.0.00319697695067.issue7743@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Second bug listed here fixed in r77698 in the trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

From report at bugs.python.org  Fri Jan 22 18:38:31 2010
From: report at bugs.python.org (spongebob)
Date: Fri, 22 Jan 2010 17:38:31 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1264181911.06.0.661870715414.issue6461@psf.upfronthosting.co.za>


spongebob <nicolas.hesler at gmail.com> added the comment:

I can't seem to freeze an app on Windows using multiprocessing.Manager()


Are apps that use Managers freezable??

Example:

from multiprocessing import freeze_support,Manager

if __name__ == '__main__':
    freeze_support()
    m=Manager()

will throw errors, when run:

Process SyncManager-1:
Traceback (most recent call last):
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.process"
, line 232, in _bootstrap
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.process"
, line 88, in run
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.managers
", line 520, in _run_server
IOError: [Errno 6] The handle is invalid
Traceback (most recent call last):
  File "<string>", line 5, in <module>
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing", line 9
8, in Manager
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.managers
", line 499, in start
EOFError

----------
nosy: +spongebob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________

From report at bugs.python.org  Fri Jan 22 18:45:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Jan 2010 17:45:37 +0000
Subject: [issue7757] sys.path is incorrect when prefix is ""
In-Reply-To: <1264178776.01.0.552667161926.issue7757@psf.upfronthosting.co.za>
Message-ID: <1264182337.78.0.278102561267.issue7757@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I thought I remembered a bug that mentioned prefix="/".  What I found was Issue1676135, which might have something to do with your last question.

----------
nosy: +r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7757>
_______________________________________

From report at bugs.python.org  Fri Jan 22 19:56:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Jan 2010 18:56:26 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264170208.67.0.155651352106.issue7753@psf.upfronthosting.co.za>
Message-ID: <4B59F4D7.3090408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>>  * Instead of deprecating the set/getcheckinterval APIs, convert the
>> arguments passed to these to the switch interval. The new APIs
>> set/getswitchinteral are then not needed.
> 
> This is certainly not a good idea. The semantics are different, which is the reason why I created a separate API in the first place instead of recycling the old one.
> 
> Actually, there should be hardly any reason to want to change the interval with the new GIL implementation. It was required with the old GIL due to the fact that counting opcodes is a very poor way of estimating wall clock durations.

Applications currently use those APIs for two reasons:

 * they use lots of threads and need to make sure that they
   all run more often than they do with the default settings e.g.
   to make them respond faster to external inputs: in such a
   case, they use a low check interval number

 * they don't use any threads and thus don't need to check
   for other threads at all or only rarely: in such a case they
   use a large check interval number

While the semantics are different, the result is similar and
the actual numbers used are usually determined by experiment
or rough estimate - noone expects the APIs to provide any kind
of exact timing and it's not needed either.

Turning the existing APIs into no-ops is certainly not a good
idea, since that will change application performance for both
use cases.

Esp. the second use case (single threaded process) is a rather
common one in Python - using multiple processes is often the more
scalable approach for Python applications, than relying on
multiple threads.

>> Note that gettimeofday() et al. are rather slow APIs on most systems
> 
> In my measurements under Linux it seemed to be as fast as clock_gettime() actually. But I don't know about other systems. I didn't want to complicate the patch (with several different paths) more than seemed necessary.

Right, but clock_gettime() provides a better resolution.

Both APIs are relatively slow, so if you call them often, it's
better to go with a different mechanism such as one built on
CPU performance counters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:24:16 2010
From: report at bugs.python.org (Dan Helfman)
Date: Fri, 22 Jan 2010 19:24:16 +0000
Subject: [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 20:29:23 2010
From: report at bugs.python.org (Dan Helfman)
Date: Fri, 22 Jan 2010 19:29:23 +0000
Subject: [issue7758] cPickle.load() segfault on invalid data
In-Reply-To: <1264188255.93.0.523423533776.issue7758@psf.upfronthosting.co.za>
Message-ID: <1264188563.06.0.902976032701.issue7758@psf.upfronthosting.co.za>


Changes by Dan Helfman <dan.helfman at noaa.gov>:


----------
title: cPickle segfault on invalid data -> cPickle.load() segfault on invalid data

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7758>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:42:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jan 2010 19:42:28 +0000
Subject: [issue7755] copyright clarification for audiotest.au
In-Reply-To: <1264154754.86.0.286834971555.issue7755@psf.upfronthosting.co.za>
Message-ID: <1264189348.11.0.182683072358.issue7755@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7755>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:50:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jan 2010 19:50:27 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B59F4D7.3090408@egenix.com>
Message-ID: <1264189895.3526.29.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> While the semantics are different, the result is similar and
> the actual numbers used are usually determined by experiment
> or rough estimate - noone expects the APIs to provide any kind
> of exact timing and it's not needed either.

There's no reasonable formula for computing an absolute switching
interval from the current "check interval" number. Besides, as I said,
there's no demonstrated reason to change the interval with the new GIL.

> * they don't use any threads and thus don't need to check
> for other threads at all or only rarely: in such a case they
> use a large check interval number

Well, if you don't use any threads you don't have to change the setting
in the first place :-). You might want to do it in order to
"micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
is unnecessary with the new GIL, since the interval is ignored when
there's only one thread running.

> Turning the existing APIs into no-ops is certainly not a good
> idea, since that will change application performance for both
> use cases.

The new GIL will change performance far more anyway. Trying to simulate
the old behaviour is doomed to failure. If we want to keep the current
performance characteristics, we'd better not backport the new GIL (which
I'm fine with by the way).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:52:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Jan 2010 19:52:12 +0000
Subject: [issue7758] cPickle.load() segfault on invalid data
In-Reply-To: <1264188255.93.0.523423533776.issue7758@psf.upfronthosting.co.za>
Message-ID: <1264189932.78.0.82473108026.issue7758@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is already fixed, I believe as part of a general cleanup of one of the CAPI macros.  On current 2.6 branch and on trunk you now get an unpickling stack underflow in this case.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7758>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:54:10 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 22 Jan 2010 19:54:10 +0000
Subject: [issue7758] cPickle.load() segfault on invalid data
In-Reply-To: <1264188255.93.0.523423533776.issue7758@psf.upfronthosting.co.za>
Message-ID: <1264190050.72.0.420610277965.issue7758@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is a duplicate of issue 7455.

----------
components: +Extension Modules -None
nosy: +eric.smith
resolution: out of date -> duplicate
superseder:  -> cPickle: stack underflow in load_pop()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7758>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:57:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Jan 2010 19:57:41 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1264190261.74.0.472373805456.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

All outstanding issues mentioned here have been solved in Rev. 77696:

  (1) New ANSI path for unknown 64bit platforms (ia64 and Alpha build
      without problems now).

  (2) Unified tests for decimal and cdecimal.

  (3) Documentation for cdecimal.


Other improvements:

  (4) Added comprehensive test suite for testing the library directly.

  (5) Fixed warnings in Visual Studio.

  (6) Code formatting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Fri Jan 22 20:58:55 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Jan 2010 19:58:55 +0000
Subject: [issue7754] decimal.Decimal 0.0**0.0 error
In-Reply-To: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>
Message-ID: <1264190335.19.0.012571543899.issue7754@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I would not be happy with unlinking __pow__ from the standard's power operation.  We wouldn't be doing our users a favor by implementing part of the standard, then tucking it away in a unexpected place, and substituting our own notion of what should be done.

>From the outset, one of the reasons for buying into the standard was the notion that the interactions had been well thought-out and heavily discussed in another forum.  By agreeing to implement the standard, we have surrendered ourselves to the tyranny of whatever decisions were made.  Another reason for staying compliant (in the most obvious way possible) is to make formulas more interoperable between languages that have chosen to implement the standard (i.e. 0**0 should do the same thing in Rexx as it does in Python).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7754>
_______________________________________

From report at bugs.python.org  Fri Jan 22 21:00:16 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Jan 2010 20:00:16 +0000
Subject: [issue7754] decimal.Decimal 0.0**0.0 error
In-Reply-To: <1264126821.18.0.0419756470395.issue7754@psf.upfronthosting.co.za>
Message-ID: <1264190416.88.0.526404709913.issue7754@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the feedback, Raymond.  I'll close this, then.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7754>
_______________________________________

From report at bugs.python.org  Fri Jan 22 21:02:33 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Jan 2010 20:02:33 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264189895.3526.29.camel@localhost>
Message-ID: <4B5A0456.6000308@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> While the semantics are different, the result is similar and
>> the actual numbers used are usually determined by experiment
>> or rough estimate - noone expects the APIs to provide any kind
>> of exact timing and it's not needed either.
> 
> There's no reasonable formula for computing an absolute switching
> interval from the current "check interval" number. 

Just use some conversion formula, e.g. switching interval in micro
seconds = constant * byte code check interval. We can then determine
a constant to match todays CPU performance.

Given the inexact nature of the check interval that's a very
reasonable formula.

> Besides, as I said,
> there's no demonstrated reason to change the interval with the new GIL.

Didn't I just point out two use cases ?

Perhaps I'm missing some feature of the new GIL. Is there some
documentation for it somewhere ?

>> * they don't use any threads and thus don't need to check
>> for other threads at all or only rarely: in such a case they
>> use a large check interval number
> 
> Well, if you don't use any threads you don't have to change the setting
> in the first place :-). You might want to do it in order to
> "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
> is unnecessary with the new GIL, since the interval is ignored when
> there's only one thread running.

Hmm, how do you determine that only one thread is running ?

What if an extension uses threads that are not under Python
control, e.g. when embedding the JVM or when using a CORBA
ORB ?

>> Turning the existing APIs into no-ops is certainly not a good
>> idea, since that will change application performance for both
>> use cases.
> 
> The new GIL will change performance far more anyway. Trying to simulate
> the old behaviour is doomed to failure. If we want to keep the current
> performance characteristics, we'd better not backport the new GIL (which
> I'm fine with by the way).

I don't follow you.

If an application currently sets the check
interval to a low value, Python should switch to other threads
more often, ie. the switch interval needs to be low.

If an application currently sets the check interval to a high
value, Python should switch to other threads less often, ie.
the switch interval needs to be higher.

Both cases can be mapped to the switch interval, so why not
do it ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 21:05:41 2010
From: report at bugs.python.org (Ross Cohen)
Date: Fri, 22 Jan 2010 20:05:41 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264152753.17.0.656147876949.issue7753@psf.upfronthosting.co.za>
Message-ID: <20100122120225.3e3b4988@neeble>


Ross Cohen <rcohen at snurgle.org> added the comment:

Thanks Neil for fixing up the patch.

As for Marc-Andre's comments, I'm happy to backport any further
changes which happen on the py3k branch. I'd like to keep this as a
strict backport, only changing things as necessary to get it to work
with the older codebase.

Ross

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 21:26:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jan 2010 20:26:19 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B5A0456.6000308@egenix.com>
Message-ID: <1264192046.3526.53.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just use some conversion formula, e.g. switching interval in micro
> seconds = constant * byte code check interval. We can then determine
> a constant to match todays CPU performance.

Well, there are two problems:
- opcode execution cost varies so wildly that trying to pick up an
average would be meaningless (it can vary by many order of magnitudes
between e.g. a POP_TOP and a CALL_FUNCTION calling a C extension method)
- the interval doesn't have the same effect in the new GIL as it has in
the old GIL; in the old GIL, it merely gives the OS a chance to switch
threads if it wants to (there are many missed opportunities, by a
proportion which will be system-dependent); in the new GIL, thread
switching is enforced which means it is not necessary to stop so often.

So we'd have a formula like:

new GIL interval = old GIL interval * opcode duration / proportion of
missed switching opportunities in the old GIL

where two of the three factors on the right side are totally
unpredictable :)

> Perhaps I'm missing some feature of the new GIL. Is there some
> documentation for it somewhere ?

Almost nothing besides what is found in ceval_gil.h and in the following
thread:
http://mail.python.org/pipermail/python-dev/2009-October/093321.html
Dave Beazley did a high-level presentation about it:
http://www.dabeaz.com/python/NewGIL.pdf

> > Well, if you don't use any threads you don't have to change the setting
> > in the first place :-). You might want to do it in order to
> > "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
> > is unnecessary with the new GIL, since the interval is ignored when
> > there's only one thread running.
> 
> Hmm, how do you determine that only one thread is running ?

Actually, I don't determine it, it's a side effect of how the GIL is
implemented. If no thread is waiting for the GIL, the main thread isn't
"asked" to drop it.

> What if an extension uses threads that are not under Python
> control, e.g. when embedding the JVM or when using a CORBA
> ORB ?

These don't wait for the GIL, hopefully :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 21:26:59 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Jan 2010 20:26:59 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B5A0456.6000308@egenix.com>
Message-ID: <4B5A0A10.2060405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On second thought, you're right: while sys.setcheckinterval() could
be made to work with the switching interval, sys.getcheckinterval()
could not be made to return anything useful.

Still, please have a look at the other issues mentioned. They
apply to new GIL in general, regardless of whether implemented
in 3.x or 2.7.

It would also be interesting to see the affect on other threaded
applications, not just the "benchmark" mentioned on the python-dev
thread.

Since there aren't all that many Python 3.x applications in the wild,
it's probably a good idea to check in the patch and then run a few
Python 2.x apps with and without it.

How does pybench react to the patch ? It's single-threaded at the
moment, so a good test of how a single-threaded application would
behave with the patch.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 21:42:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Jan 2010 20:42:31 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264192046.3526.53.camel@localhost>
Message-ID: <4B5A0DB3.6090301@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
>> Perhaps I'm missing some feature of the new GIL. Is there some
>> documentation for it somewhere ?
> 
> Almost nothing besides what is found in ceval_gil.h and in the following
> thread:
> http://mail.python.org/pipermail/python-dev/2009-October/093321.html
> Dave Beazley did a high-level presentation about it:
> http://www.dabeaz.com/python/NewGIL.pdf

Thanks. Dave's slides help a lot. The logic certainly sounds like
a major improvement !

>>> Well, if you don't use any threads you don't have to change the setting
>>> in the first place :-). You might want to do it in order to
>>> "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
>>> is unnecessary with the new GIL, since the interval is ignored when
>>> there's only one thread running.
>>
>> Hmm, how do you determine that only one thread is running ?
> 
> Actually, I don't determine it, it's a side effect of how the GIL is
> implemented. If no thread is waiting for the GIL, the main thread isn't
> "asked" to drop it.
> 
>> What if an extension uses threads that are not under Python
>> control, e.g. when embedding the JVM or when using a CORBA
>> ORB ?
> 
> These don't wait for the GIL, hopefully :-)

Well, they might call back into Python, but I guess that's not
supported anyway, not even in 2.x, since such a thread wouldn't
have a properly setup Python thread state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 22 22:36:20 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 22 Jan 2010 21:36:20 +0000
Subject: [issue4698] Solaris buildbot failure on trunk in test_hostshot
In-Reply-To: <1229641134.61.0.646218726644.issue4698@psf.upfronthosting.co.za>
Message-ID: <1264196180.04.0.954175206986.issue4698@psf.upfronthosting.co.za>


Changes by Neil Schemenauer <nas-python at arctrix.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4698>
_______________________________________

From report at bugs.python.org  Fri Jan 22 22:37:17 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 22 Jan 2010 21:37:17 +0000
Subject: [issue1220756] Re-importing embedded thread dumps core
Message-ID: <1264196237.68.0.957368494123.issue1220756@psf.upfronthosting.co.za>


Changes by Neil Schemenauer <nas-python at arctrix.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220756>
_______________________________________

From report at bugs.python.org  Fri Jan 22 23:22:15 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 22 Jan 2010 22:22:15 +0000
Subject: [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  Fri Jan 22 23:23:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jan 2010 22:23:58 +0000
Subject: [issue2611] Extend buildbot web interface to allow for forced tests
	to be run on a slave in verbose mode.
In-Reply-To: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>
Message-ID: <1264199038.9.0.530723780457.issue2611@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2611>
_______________________________________

From report at bugs.python.org  Sat Jan 23 01:09:16 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 23 Jan 2010 00:09:16 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1264205356.91.0.361998946512.issue7736@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

The patch works fine for me too. Also, I did not discover any other such problems for other syscalls (but I did not systematically try all os.* functions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

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: [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 01:23:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jan 2010 00:23:04 +0000
Subject: [issue7760] use_errno=True does not work
In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za>
Message-ID: <1264206184.05.0.671038671504.issue7760@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7760>
_______________________________________

From report at bugs.python.org  Sat Jan 23 01:37:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2010 00:37:40 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264207060.64.0.428733786324.issue7564@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_ioctl() gets the process group ID of the foreground process group on /dev/tty. If Python is in foreground, it's equal to the process group ID (os.getpgrp()) or to the session ID (os.getsid(0)). If Python is in background, yes, the test fail.

test_ioctl_mutate() contains test_ioctl() but also ensure that the input buffer is not modified by the ioctl.

If you would like to run test_ioctl.py in background, you will have to disable these 2 tests: ignore the tests if the process is in background. Detect if a process is in foreground or background is exactly the goal of test_ioctl()...

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Sat Jan 23 01:46:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2010 00:46:35 +0000
Subject: [issue7267] format method: c presentation type broken
In-Reply-To: <1257438168.68.0.774312526176.issue7267@psf.upfronthosting.co.za>
Message-ID: <1264207595.48.0.194897709856.issue7267@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

('%c' % 255) == chr(255) == '\xff'

'%c' % 256 raise an "OverflowError: unsigned byte integer is greater than maximum" and chr(256) raise a "ValueError: chr() arg not in range(256)". I prefer the second error ;-)

str.format() should follow the same behaviour.

str is a byte string: it can be used to create a network packet or encode data into a byte stream. '%c' is useful for that, and str.format() should keep this nice feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7267>
_______________________________________

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: [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 04:27:34 2010
From: report at bugs.python.org (Pablo Mouzo)
Date: Sat, 23 Jan 2010 03:27:34 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1264217254.96.0.289334599731.issue7723@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

I'm attaching a correction to sqlite3 documentation, removing all 'buffer' references and setting bytes as BLOB equivalent.

----------
keywords: +patch
nosy: +pablomouzo
Added file: http://bugs.python.org/file15977/issue7723-py3k-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7723>
_______________________________________

From report at bugs.python.org  Sat Jan 23 05:00:24 2010
From: report at bugs.python.org (Pablo Mouzo)
Date: Sat, 23 Jan 2010 04:00:24 +0000
Subject: [issue6045] Fix dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1264219224.21.0.64780651554.issue6045@psf.upfronthosting.co.za>


Changes by Pablo Mouzo <pablomouzo at gmail.com>:


----------
nosy: +pablomouzo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6045>
_______________________________________

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: [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: [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 09:42:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jan 2010 08:42:18 +0000
Subject: [issue7763] (C API) PyUnicode_Tailmatch documentation
In-Reply-To: <1264232171.64.0.310629533976.issue7763@psf.upfronthosting.co.za>
Message-ID: <1264236138.83.0.378973261184.issue7763@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Duplicate of #7762.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> (C API) PyUnicode_Tailmatch documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7763>
_______________________________________

From report at bugs.python.org  Sat Jan 23 09:43:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jan 2010 08:43:37 +0000
Subject: [issue7762] (C API) PyUnicode_Tailmatch documentation
In-Reply-To: <1264232168.43.0.991718973668.issue7762@psf.upfronthosting.co.za>
Message-ID: <1264236217.83.0.579362973114.issue7762@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r77702.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7762>
_______________________________________

From report at bugs.python.org  Sat Jan 23 09:48:04 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jan 2010 08:48:04 +0000
Subject: [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: <1264236484.85.0.274733646926.issue7725@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r77703.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7725>
_______________________________________

From report at bugs.python.org  Sat Jan 23 11:12:47 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Jan 2010 10:12:47 +0000
Subject: [issue7748] unicode supported in distutils register but not distutils
	upload
In-Reply-To: <1264105392.3.0.560672704359.issue7748@psf.upfronthosting.co.za>
Message-ID: <1264241567.72.0.199193504634.issue7748@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> accepted
type:  -> crash
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7748>
_______________________________________

From report at bugs.python.org  Sat Jan 23 13:21:46 2010
From: report at bugs.python.org (Chris Withers)
Date: Sat, 23 Jan 2010 12:21:46 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264249306.95.0.807999327918.issue7759@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Please can you write a test for your patch?

----------
nosy: +cjw296
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sat Jan 23 13:24:11 2010
From: report at bugs.python.org (Chris Withers)
Date: Sat, 23 Jan 2010 12:24:11 +0000
Subject: [issue7741] Allow multiple statements in code.InteractiveConsole.push
In-Reply-To: <1263912723.35.0.93131684665.issue7741@psf.upfronthosting.co.za>
Message-ID: <1264249451.02.0.389258739468.issue7741@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Please can you starts a small test suite for the code module that tests the fix you are proposing and include it as another patch?

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7741>
_______________________________________

From report at bugs.python.org  Sat Jan 23 13:27:18 2010
From: report at bugs.python.org (Chris Withers)
Date: Sat, 23 Jan 2010 12:27:18 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1264249638.59.0.241791617937.issue7743@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Out of curiosity, is it possible to write unit tests for any/all of this?

> I haven't yet found any examples that cause this crash without bigcomp 
> enabled.

I presume you meant *with* bigcomp enabled?

Forgive my lack of knowledge, but why would you disable bigcomp?

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

From report at bugs.python.org  Sat Jan 23 13:30:57 2010
From: report at bugs.python.org (Chris Withers)
Date: Sat, 23 Jan 2010 12:30:57 +0000
Subject: [issue7744] Allow site.addsitedir insert to beginning of sys.path
In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za>
Message-ID: <1264249857.67.0.599814933812.issue7744@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

This sounds like something best taken to the python-ideas mailing list.
Can you do that and update the issue with the outcome of any discussion?

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7744>
_______________________________________

From report at bugs.python.org  Sat Jan 23 13:33:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Jan 2010 12:33:05 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1264249985.82.0.819898924859.issue7743@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Out of curiosity, is it possible to write unit tests for any/all of this?

There are some tests in Lib/test/test_strtod.py, that I added around two weeks ago and have been updating since;  I don't have mechanism for running tests with the altered STRTOD_DIGLIM value, though.

> I presume you meant *with* bigcomp enabled?
I did.  Thanks!

> Forgive my lack of knowledge, but why would you disable bigcomp?

Just as a stress test, really:  a failure that occurs with bigcomp disabled might indicate a problem that could also occur with bigcomp enabled.  Or someone might want to alter the value of the STRTOD_DIGLIM threshold at some later point based on performance tests;  if the code is correct then it ought to be safe to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

From report at bugs.python.org  Sat Jan 23 13:36:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Jan 2010 12:36:22 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1264250182.8.0.116096954472.issue7743@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I forgot to mention:  the other reason one might want to disable the bigcomp stuff is that it seems less reliable than the rest of the code:  of the 11-12 independent bugs that I found in dtoa.c recently, around 9 of them were related to the bigcomp code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

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: [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 14:56:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jan 2010 13:56:20 +0000
Subject: [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: <1264254980.56.0.255168695383.issue7764@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +rhettinger
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sat Jan 23 14:57:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Jan 2010 13:57:59 +0000
Subject: [issue7748] unicode supported in distutils register but not distutils
	upload
In-Reply-To: <1264105392.3.0.560672704359.issue7748@psf.upfronthosting.co.za>
Message-ID: <1264255079.68.0.0290112169268.issue7748@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7748>
_______________________________________

From report at bugs.python.org  Sat Jan 23 15:07:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jan 2010 14:07:23 +0000
Subject: [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: <1264255643.77.0.436808678031.issue7764@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sat Jan 23 15:21:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jan 2010 14:21:29 +0000
Subject: [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: <1264256489.14.0.224841678523.issue7751@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Sat Jan 23 16:26:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jan 2010 15:26:20 +0000
Subject: [issue7761] telnetlib Telnet.interact fails on Windows but not Linux
In-Reply-To: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>
Message-ID: <1264260380.74.0.907104697974.issue7761@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7761>
_______________________________________

From report at bugs.python.org  Sat Jan 23 16:45:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jan 2010 15:45:49 +0000
Subject: [issue7744] Allow site.addsitedir insert to beginning of sys.path
In-Reply-To: <1264018763.75.0.862537731081.issue7744@psf.upfronthosting.co.za>
Message-ID: <1264261549.19.0.118137691357.issue7744@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed
status: open -> pending
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7744>
_______________________________________

From report at bugs.python.org  Sat Jan 23 17:59:01 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Sat, 23 Jan 2010 16:59:01 +0000
Subject: [issue7760] use_errno=True does not work
In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za>
Message-ID: <1264265941.92.0.826742797011.issue7760@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

In the libc case you shouldn't give absolute path in CDLL: CDLL('libc.so.6') is better. You use "/lib/libc.so.6" path, but Python (and ctypes.so) actually uses something like "/lib/tls/i686/cmov/libc.so.6" - these are two separate libraries with separate "errno" variables, mapped to different memory regions. Your call to getxattr modifies errno in the former library, but ctypes get_errno() fetches value from the latter library.

If I fix CDLL() call, the test works ok for me.

----------
nosy: +marcin.bachry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7760>
_______________________________________

From report at bugs.python.org  Sat Jan 23 18:29:12 2010
From: report at bugs.python.org (Peter Otten)
Date: Sat, 23 Jan 2010 17:29:12 +0000
Subject: [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: <1264267752.32.0.458118310293.issue7764@psf.upfronthosting.co.za>


Peter Otten <__peter__ at web.de> added the comment:

As noted on comp.lang.python the implementation can be simplified to

def consume(items, n):
    next(islice(items, n, n), None)

When I suggested the above I wasn't aware that 

consume(items, None)

should exhaust the entire iterator. Unfortunately I've not found an elegant way to add that functionality.

----------
nosy: +potten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sat Jan 23 19:09:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jan 2010 18:09:33 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264270173.35.0.956900918799.issue7759@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The documentation mentions that mhlib is deprecated and mailbox should be used instead. Is there any point in trying to fix it?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sat Jan 23 19:12:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jan 2010 18:12:28 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264270348.95.0.88624189348.issue7759@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: test needed -> patch review
versions: +Python 2.6 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sat Jan 23 19:12:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jan 2010 18:12:51 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264270371.47.0.146215598146.issue7759@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sat Jan 23 19:23:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jan 2010 18:23:08 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264270988.68.0.841510050993.issue7753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As for your other comments, Marc-Andre:

> * Please check whether you can move these variable declarations inside
> the main loop function (as statics):
> [snip]

They are used in other functions than in the main loop, so it's not possible.

> * Please add the fallback solutions from the time module in case 
> gettimeofday() is not available. You cannot assume that "all modern
> POSIX systems" implement that API - it was introduced in POSIX 2001
> and Python 2.x still supports OSes that were released prior to that
> year.

I didn't know about that. In the context of py3k, I'm not sure it is really annoying, but you're right that for 2.x a fallback might be needed.

By the way, the new GIL only works with POSIX and Windows NT threading APIs. Perhaps it can't be backported at all to 2.x, given that 2.x supports more threading APIs than py3k does?

> I haven't looked at the timing details of the implementation, but
> please make sure that it works even if the clock interval is a few ms

Well, since it works under Windows (I don't have any really reliable benchmarks, since I've tested under a VM which is not an ideal condition), I assume it's robust against poor timing precisions.
(under Windows, WaitForMultipleObjects() is used which according to the MSDN docs has worse than microsecond precision)

But, yes, testing would be welcome on such platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Sat Jan 23 19:25:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jan 2010 18:25:12 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264271112.58.0.971127800519.issue7753@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I meant "worse than milliseconds", sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Sat Jan 23 19:39:00 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Jan 2010 18:39:00 +0000
Subject: [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: <1264271940.77.0.375212207489.issue7764@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will switch to the version using next() instead of deque().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sat Jan 23 20:03:38 2010
From: report at bugs.python.org (John Edmonds)
Date: Sat, 23 Jan 2010 19:03:38 +0000
Subject: [issue5423] Exception raised when attempting to call set_charset on
	an email.mime.multipart once sub-parts have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1264273418.92.0.760119439672.issue5423@psf.upfronthosting.co.za>


John Edmonds <pocketcookies2 at gmail.com> added the comment:

It looks like set_charset's documentation says that it assumes you are calling it on a message with a mimetype of text/*.  This case calls it on a message of type multipart/mixed.  Nonetheless, I am attaching a patch that catches this earlier and prints a more relevant and consistent error message.

----------
keywords: +patch
nosy: +pocketcookies
Added file: http://bugs.python.org/file15979/issue5423.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5423>
_______________________________________

From report at bugs.python.org  Sat Jan 23 20:37:53 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 23 Jan 2010 19:37:53 +0000
Subject: [issue7760] use_errno=True does not work
In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za>
Message-ID: <1264275473.0.0.31819947667.issue7760@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

I can confirm that without the path it works for me too.

But I have to admit that I don't really understand your explanation. Should I generally not use full paths with CDLL? Or just in the case of libc?

In either case, I think the ctypes dokumentation could be more explicit about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7760>
_______________________________________

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: [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:43:53 2010
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 23 Jan 2010 19:43:53 +0000
Subject: [issue7765] 'unittest' documentation misprints
In-Reply-To: <1264275798.04.0.174559060611.issue7765@psf.upfronthosting.co.za>
Message-ID: <1264275833.42.0.107094283905.issue7765@psf.upfronthosting.co.za>


Changes by July Tikhonov <july.tikh at gmail.com>:


Added file: http://bugs.python.org/file15981/unittest-doc-trunk.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: [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  Sat Jan 23 21:27:54 2010
From: report at bugs.python.org (John Edmonds)
Date: Sat, 23 Jan 2010 20:27:54 +0000
Subject: [issue5423] Exception raised when attempting to call set_charset on
	an email.mime.multipart once sub-parts have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1264278474.94.0.835745547343.issue5423@psf.upfronthosting.co.za>


Changes by John Edmonds <pocketcookies2 at gmail.com>:


Added file: http://bugs.python.org/file15983/issue5423.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5423>
_______________________________________

From report at bugs.python.org  Sat Jan 23 21:28:07 2010
From: report at bugs.python.org (John Edmonds)
Date: Sat, 23 Jan 2010 20:28:07 +0000
Subject: [issue5423] Exception raised when attempting to call set_charset on
	an email.mime.multipart once sub-parts have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1264278487.09.0.275564570035.issue5423@psf.upfronthosting.co.za>


Changes by John Edmonds <pocketcookies2 at gmail.com>:


Removed file: http://bugs.python.org/file15979/issue5423.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5423>
_______________________________________

From report at bugs.python.org  Sat Jan 23 21:42:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 23 Jan 2010 20:42:31 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264279351.86.0.0555323378595.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I like this. I've visually reviewed the patch, but haven't tested it yet. I'm willing to commit this.

Could you add to the tests to assert that .major is equal to [0], etc.?

Also, the documentation says that element [4] is "text", but you've referred to it as "service_pack". I don't think "service_pack" is documented anywhere, but is clearly a better name than "text". The documentation of OSVERSIONINFO describes this as szCSDVersion, with the description of 'A null-terminated string, ..., that indicates the latest Service Pack installed on the system ...', so "service_pack" is okay with me. Can you change the documentation to refer to this field as "service_pack"?

Another idea would be to expose OSVERSIONINFOEX. I've personally wanted to get access to wProductType in the past. Any thoughts on that? I think OSVERSIONINFOEX would be available on any version of Windows that we care about going forward.

I don't see any point in changing it from a function to a property at this point. There's the hassle of migrating to the new version, and it's wrapping a Win32 API call anyway.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Sat Jan 23 21:49:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Jan 2010 20:49:23 +0000
Subject: [issue7743] Additional potential string -> float conversion issues.
In-Reply-To: <1263993140.57.0.0708544689838.issue7743@psf.upfronthosting.co.za>
Message-ID: <1264279763.17.0.239569787147.issue7743@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

First bug fixed (in the trunk) in r77713.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7743>
_______________________________________

From report at bugs.python.org  Sat Jan 23 22:14:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jan 2010 21:14:41 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264281281.35.0.531448800057.issue7766@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Good point about OSVERSIONINFOEX. I've actually wanted some of that info as well, and according to MSDN the minimum supported client to get that structure is Windows 2000 - same as OSVERSIONINFO.

Attached is a patch updated with your comments plus the use of OSVERSIONINFOEX.

----------
Added file: http://bugs.python.org/file15984/winver_as_structseq_ex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Sat Jan 23 22:28:51 2010
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 23 Jan 2010 21:28:51 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1264282131.95.0.975074668126.issue1068268@psf.upfronthosting.co.za>


Changes by Nir Soffer <nirsof at gmail.com>:


----------
nosy: +nirs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1068268>
_______________________________________

From report at bugs.python.org  Sat Jan 23 23:23:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jan 2010 22:23:27 +0000
Subject: [issue5423] Exception raised when attempting to call set_charset on
	an email.mime.multipart once sub-parts have been attached
In-Reply-To: <1236258073.44.0.224242973923.issue5423@psf.upfronthosting.co.za>
Message-ID: <1264285407.54.0.166602731658.issue5423@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
stage: test needed -> patch review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5423>
_______________________________________

From report at bugs.python.org  Sun Jan 24 00:27:51 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 23 Jan 2010 23:27:51 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264270173.35.0.956900918799.issue7759@psf.upfronthosting.co.za>
Message-ID: <20100123232659.GA18314@arctrix.com>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

On Sat, Jan 23, 2010 at 06:09:33PM +0000, Antoine Pitrou wrote:
> The documentation mentions that mhlib is deprecated and mailbox
> should be used instead. Is there any point in trying to fix it?

It looks like Btrfs will eventually conform to traditional st_nlink
behavior. However, that still leaves HFS+.  Perhaps the easiest fix
would be to have the unit test check for weird st_nlink behavior by
creating a directory with a subdirectory.  If something is weird,
skip testing mhlib.  The downside to that solution is that someone
might use mhlib on a HFS+ filesystem and encounter buggy behavior.

I can imagine that removing the optimization can make mhlib much
slower for large mail boxes.  Maybe that would be better than
risking lost mail though.  On modern machines maybe it doesn't
matter much.

  Neil

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sun Jan 24 02:16:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jan 2010 01:16:19 +0000
Subject: [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: <1264295779.3.7.14513569541e-05.issue7737@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I fixed more in r77111 and then backported everything to trunk in r77715.

----------
keywords:  -needs review
nosy: +ezio.melotti
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7737>
_______________________________________

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: [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 02:25:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Jan 2010 01:25:18 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <20100123232659.GA18314@arctrix.com>
Message-ID: <1264296387.4710.0.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The documentation mentions that mhlib is deprecated and mailbox
> > should be used instead. Is there any point in trying to fix it?
> 
> It looks like Btrfs will eventually conform to traditional st_nlink
> behavior. However, that still leaves HFS+.

That wasn't really my question. What I ask is: since mhlib is
deprecated, why do we need to fix it while people are encouraged to use
mailbox instead?
And, besides, does mailbox show the same problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sun Jan 24 02:30:17 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 24 Jan 2010 01:30:17 +0000
Subject: [issue7748] unicode supported in distutils register but not distutils
	upload
In-Reply-To: <1264105392.3.0.560672704359.issue7748@psf.upfronthosting.co.za>
Message-ID: <1264296617.77.0.0403185554458.issue7748@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

fixed in r77717, r77719 

Under Py3, we will just use utf8 strings.

Thanks!

----------
status: open -> closed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7748>
_______________________________________

From report at bugs.python.org  Sun Jan 24 03:09:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 02:09:41 +0000
Subject: [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264298981.47.0.752052793566.issue7767@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Interpreter Core -Extension Modules
keywords: +needs review
priority:  -> normal
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7767>
_______________________________________

From report at bugs.python.org  Sun Jan 24 04:33:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 03:33:26 +0000
Subject: [issue6651] Py3k's posixpath.relpath not compatible with
	ntpath.relpath
In-Reply-To: <1249500192.85.0.26357988262.issue6651@psf.upfronthosting.co.za>
Message-ID: <1264304006.93.0.365454924912.issue6651@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

After thinking about this, I don't see a need for any change. 

Although it _looks_ like the relpath implementations aren't compatible based on their start default parameters, they do work the same. My code change isn't really necessary. All it does is rearrange things to make the signatures look the same, but it doesn't change the actual functionality.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6651>
_______________________________________

From report at bugs.python.org  Sun Jan 24 04:35:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Jan 2010 03:35:26 +0000
Subject: [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: <1264304126.61.0.678958885049.issue7764@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r77721

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

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: [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 09:45:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Jan 2010 08:45:32 +0000
Subject: [issue2611] Extend buildbot web interface to allow for forced tests
	to be run on a slave in verbose mode.
In-Reply-To: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>
Message-ID: <1264322732.79.0.20897405572.issue2611@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm closing this as "won't fix". If there is a need to run specific tests in specific ways, it is best to check in code that does it as desired. If it is then unacceptable to run that change on all slaves, a branch can be created, and building the branch can be triggered in the UI.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2611>
_______________________________________

From report at bugs.python.org  Sun Jan 24 10:14:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 09:14:56 +0000
Subject: [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264324496.04.0.678191545652.issue7767@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7767>
_______________________________________

From report at bugs.python.org  Sun Jan 24 10:19:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Jan 2010 09:19:14 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1264324754.88.0.583185097177.issue7736@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the bug here is really in the application, which makes a system call to fuse and the fuse callback in the same process. This isn't supported, and IMO doesn't need to be. Python makes no promises that it will accept callbacks while a system call is in progress.

That said, working around this problem in this specific case with the proposed patch is fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Sun Jan 24 11:01:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Jan 2010 10:01:47 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1264327307.65.0.836814669522.issue7242@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

One relevant difference may be the change to the fork semantics in Solaris 10: fork() now means the same as fork1(). Before, fork() meant the same as forkall(), unless the applications was linked with -lpthread, in which case fork() also meant fork1(). See fork(2).

So I'd be curious if a) the test case passes on Solaris 8 if fork1 is being used, and b) whether it passes if you make sure -lpthread is being used. If so, I'd rather fix this issue by changing the linkage for Solaris 8 (or declaring that system as unsupported altogether), instead of fiddling yet again with the fork handling. In Python, posix.fork definitely needs to mean "POSIX fork".

If it's something else (i.e. the thread ID changes in Solaris 8 whether fork1 or forkall is used), then the patch is fine in principle. However, I would always reset the thread ID. In your patch, it is not clear why you apply this resetting to Solaris and AIX, but not other systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Sun Jan 24 11:52:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 10:52:48 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264330368.47.0.657805959395.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the latest patch!  It's looking good, but I have a few comments:

(1) It's not necessary to do an isinstance(a, Decimal) check before calling _convert_other, since _convert_other does that check anyway.  It doesn't really harm either, but for consistency with the way the Decimal methods themselves are written, I think the isinstance check should be left out.

(2) The error message that's produced when the Decimal operation returns NotImplemented is a bit strange:

>>> decimal.getcontext().add(2, 'bob')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/dickinsm/python/svn/trunk/Lib/decimal.py", line 3869, in add
    raise TypeError("Unable to convert %s to Decimal" % r)
TypeError: Unable to convert NotImplemented to Decimal

Presumably that '% r' should be '% b' instead.

(3) It looks like Context.power is missing a NotImplemented check:

>>> decimal.getcontext().power(2, 'bob')
NotImplemented

(4) We should consider updating the documentation for the Context methods, though there's actually nothing there that would suggest that these operations wouldn't work for integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Sun Jan 24 11:56:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 10:56:32 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264330592.41.0.94257425937.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One more:

(5) The patch includes a (presumably accidental) change to the divmod docstring, from "Return (a // b, a % b)" to "Return (self // other, self % other)".  I think the first version is preferable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Sun Jan 24 12:00:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 11:00:19 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264330819.86.0.423977127592.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And another.  :)

(6) I think that with these changes, the single argument methods, like Context.exp, and Context.sqrt, should also accept integers.  Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Sun Jan 24 12:23:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 11:23:27 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1264332207.79.0.987371241452.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So here's the plan for trunk.  The big question is:  what should be done for py3k?

For trunk:

 - all comparisons (==, !=, <=, >=, <, >) between floats and Decimals
   return the correct numerical result, as though the float were
   converted to a Decimal with no loss of precision.  Like-signed float
   and Decimal infinities compare equal.  float and Decimal nans compare
   unequal to everything else, as always.

 - check whether anything special needs to be done to make sure that
   cmp also returns sensible results.

 - fix Decimal.__hash__ so that when x == y for a float x and Decimal
   instance y, hash(x) == hash(y)

 - the hash fix above is going to slow down hash computations, so
   consider caching hash values for Decimal instances (as a _hash
   attribute on the Decimal object itself).  My gut feeling is that
   this probably isn't worth it, given that Decimal objects probably
   don't get hashed very often in normal use, but I'll do some timings
   to find out what the performance impact of the new hash is.

For py3k, the obvious options are:

(A) adopt the above changes, or

(B) keep Decimal and float non-comparable (as currently).  In this case, a Decimal-to-float comparison in trunk should probably raise a DeprecationWarning.  (Note that DeprecationWarnings are now silent by default, so such a warning wouldn't impact end-users much.)

----------
priority:  -> high
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Sun Jan 24 12:37:56 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jan 2010 11:37:56 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264333076.97.0.303579201617.issue7633@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

(6) Yes, I think that is logical. In cdecimal, I accept integers for all unary methods except is_canonical and number_class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Sun Jan 24 13:33:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jan 2010 12:33:29 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1264336409.96.0.544856377977.issue2531@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I'm new to this thread, so I hope I didn't miss anything that has been
said already. I don't fully understand why TypeError cannot be raised
in 2.x. The 2.6 documentation for tp_richcompare says:

"If you want to implement a type for which only a limited set of comparisons makes sense (e.g. == and !=, but not < and friends), directly raise TypeError in the rich comparison function."


I just tried that in the 2.7 version of cdecimal, and it works well:


>>> from cdecimal import *
>>> Decimal(9) < 2.5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: conversion from float to Decimal is not supported

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

From report at bugs.python.org  Sun Jan 24 13:37:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 12:37:22 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1264336642.77.0.931199401896.issue2531@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan:  the problem is backwards compatibility.  In 2.6 it's possible to sort a heterogeneous list that contains both Decimal instances and floats.  The resulting order may not be particularly meaningful, but for some applications that doesn't matter.

If we make a Decimal-to-float comparison raise TypeError for 2.7 then sort will raise a TypeError where it used to work, so it's a potential code-breaking change.  We could deprecate:  raise a warning in 2.7 and make it a TypeError in 2.8, but since 2.8 currently seems unlikely to happen that would be a bit pointless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2531>
_______________________________________

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: [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 13:57:41 2010
From: report at bugs.python.org (Muhammad Alkarouri)
Date: Sun, 24 Jan 2010 12:57:41 +0000
Subject: [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: <1264337861.39.0.103729325824.issue7764@psf.upfronthosting.co.za>


Muhammad Alkarouri <malkarouri at gmail.com> added the comment:

Excellent solution and comments. Many thanks.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

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: [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 14:16:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jan 2010 13:16:25 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264338985.83.0.969224728329.issue7770@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +mark.dickinson
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 14:26:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 13:26:40 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264339600.59.0.326502284069.issue7770@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think that recipe is meant more as a simple example of what's possible than as a bullet-proof library function.  Can you suggest changes that would improve accuracy while also keeping the recipe clear and simple?

The usual method for sin/cos is to do an initial reduction by an integral multiple of pi/2 so that the argument lies in [-pi/4, pi/4].  (Though that's still problematic for very large arguments, where pi needs to be computed to many more places than the desired output accuracy.)

Perhaps it would be best to just add a note to the docstring indicating that this is an implementation that's suitable for small arguments; for large arguments, more sophisticated algorithms are needed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 14:31:10 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 24 Jan 2010 13:31:10 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1264339870.94.0.407087001587.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

system python has to be at least revision 77704 (trunk)

----------
Added file: http://bugs.python.org/file15987/python-trunk-20100124-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun Jan 24 14:32:54 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 24 Jan 2010 13:32:54 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1264339974.79.0.419129487297.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

system python has to be at least revision 77704 (trunk)

----------
Added file: http://bugs.python.org/file15988/python-trunk-20100124-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jan 24 14:46:13 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 13:46:13 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264340773.12.0.694119702517.issue7770@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

This is the version I would suggest and which is quite accurate unless the numbers get extremely large.

def sin(x):
    """Return the sine of x as measured in radians.

    >>> print sin(Decimal('0.5'))
    0.4794255386042030002732879352
    >>> print sin(0.5)
    0.479425538604
    >>> print sin(0.5+0j)
    (0.479425538604+0j)

    """
    x = x - pi()*int(x / pi())
    getcontext().prec += 2
    i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i * (i-1)
        num *= x * x
        sign *= -1
        s += num / fact * sign
    getcontext().prec -= 2
    return +s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 14:48:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 13:48:49 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264340929.58.0.12722205889.issue7770@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Isn't sine periodic with period 2*pi, not pi?

I'd also suggest making use of remainder_near.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 14:56:32 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 13:56:32 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264341392.14.0.839776655565.issue7770@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

stupid, it is much better to just use the modulo operator. The same works with cos...

def sin(x):
    """Return the sine of x as measured in radians.

    >>> print sin(Decimal('0.5'))
    0.4794255386042030002732879352
    >>> print sin(0.5)
    0.479425538604
    >>> print sin(0.5+0j)
    (0.479425538604+0j)

    """
    x %= pi()
    getcontext().prec += 2
    i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i * (i-1)
        num *= x * x
        sign *= -1
        s += num / fact * sign
    getcontext().prec -= 2
    return +s

def cos(x):
    """Return the cosine of x as measured in radians.

    >>> print cos(Decimal('0.5'))
    0.8775825618903727161162815826
    >>> print cos(0.5)
    0.87758256189
    >>> print cos(0.5+0j)
    (0.87758256189+0j)

    """
    x %= pi()
    getcontext().prec += 2
    i, lasts, s, fact, num, sign = 0, 0, 1, 1, 1, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i * (i-1)
        num *= x * x
        sign *= -1
        s += num / fact * sign
    getcontext().prec -= 2
    return +s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 15:46:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Jan 2010 14:46:43 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264344403.51.0.570909965501.issue7770@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Johannes: note that the reduction needs to be by 2*pi, not pi.  The remainder_near method is slightly better than the modulo operator here:
remainder_near reduces to the range [-pi, pi], while the modulo operator reduces to the range (-2*pi, 2*pi), so ends up passing larger arguments to the Taylor series.  (And it's a nice excuse to show what remainder_near is good for!)  Also, the reduction should happen *after* the temporary increase in context precision.

Here's a doc patch, that just adds a single line:

x = x.remainder_near(2*pi())

after getcontext().prec += 2, for both the sin and cos recipes.  It also removes the float and complex examples in the docstrings, since remainder_near doesn't exist for those types.

Raymond, is this change okay with you?

----------
keywords: +patch
stage: test needed -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15989/issue7770.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 16:12:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Jan 2010 15:12:38 +0000
Subject: [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: <1264345958.11.0.288044328024.issue7768@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I agree that would be nice, but it's usefulness would also be limited by the fact that raw_input always returns a normal string.

----------
nosy: +benjamin.peterson
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7768>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:12:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 16:12:56 +0000
Subject: [issue3754] minimal cross-compilation support for configure
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1264349576.96.0.816496395602.issue3754@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:23:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 16:23:35 +0000
Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function
	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264350215.33.0.910105933651.issue7769@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you submit your patch as a unified diff -- it's not easy to tell where you made changes to that file. 
Can you also include tests showing how this is used, especially using register_function in both the old way and the new way you propose? Lib/test/test_xmlrpc.py is a good place to put your tests.

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7769>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:26:40 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 24 Jan 2010 16:26:40 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264296387.4710.0.camel@localhost>
Message-ID: <20100124162618.GA19421@arctrix.com>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

On Sun, Jan 24, 2010 at 01:25:18AM +0000, Antoine Pitrou wrote:
> That wasn't really my question. What I ask is: since mhlib is
> deprecated, why do we need to fix it while people are encouraged to use
> mailbox instead?

Sorry, I don't understand what you are proposing. Do you mean we
should just let the test fail for people who develop on HFS+ and
Btrfs filesystems? That seems not so good.

> And, besides, does mailbox show the same problem?

No, it doesn't have that optimization.

  Neil

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:27:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 16:27:58 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1264350478.64.0.807830931699.issue3871@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:31:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Jan 2010 16:31:01 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264350661.22.0.878656568171.issue7759@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sorry, I don't understand what you are proposing. Do you mean we
> should just let the test fail for people who develop on HFS+ and
> Btrfs filesystems? That seems not so good.

Hmm, you are right. From a quick glance, the patch looks ok. I assume you've checked it doesn't break anything else :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:32:12 2010
From: report at bugs.python.org (Chris Withers)
Date: Sun, 24 Jan 2010 16:32:12 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1264350732.98.0.715679220097.issue7759@psf.upfronthosting.co.za>


Changes by Chris Withers <chris at simplistix.co.uk>:


----------
nosy:  -cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:47:05 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 16:47:05 +0000
Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function
	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264351625.15.0.830119430801.issue7769@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

I'm not very used to working with bug/issue trackers, is there any tutorial here, where this is explained?

I did the stuff you asked me to do:

diff: http://paste.pocoo.org/compare/169357/169359/
test: http://paste.pocoo.org/show/169360/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7769>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:49:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 16:49:42 +0000
Subject: [issue1729305] test_doctest fails when run in verbose mode
Message-ID: <1264351782.1.0.368630434679.issue1729305@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The patch did not work with latest trunk.

Here is an updated version of the patch.

Patch tested with different commands:
~ $ ./python -m test.regrtest test_doctest
~ $ ./python -m test.regrtest -v test_doctest
~ $ ./python -m test.regrtest -v test_doctest |less
~ $ ./python -3 -Wd Lib/test/regrtest.py -v test_doctest |less

----------
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15990/issue1729305_doctest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729305>
_______________________________________

From report at bugs.python.org  Sun Jan 24 17:54:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 16:54:00 +0000
Subject: [issue1729305] test_doctest fails when run in verbose mode
Message-ID: <1264352040.44.0.478999231453.issue1729305@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

And for Python 3. (Slightly different)

----------
stage:  -> patch review
Added file: http://bugs.python.org/file15991/issue1729305_doctest_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729305>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:00:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 17:00:52 +0000
Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function
	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264352452.23.0.98435544655.issue7769@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

http://www.python.org/dev/workflow/ and http://python.org/dev/faq/ should help you get started. The workflow doc will let you know what the process is around here. The FAQ will tell you how to setup Subversion, how to make a diff, etc.

With that said, I think your change could be useful. Being that it's a feature request, it will go into 2.7 if accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7769>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:04:46 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 24 Jan 2010 17:04:46 +0000
Subject: [issue7764] dictview
In-Reply-To: <1264254781.04.0.3391109102.issue7764@psf.upfronthosting.co.za>
Message-ID: <1264352686.09.0.185587907727.issue7764@psf.upfronthosting.co.za>


Changes by Jan Kaliszewski <zuo at chopin.edu.pl>:


----------
title: Doc for itertools recipe consume is complicated and less efficient -> dictview
versions:  -Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:05:16 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 24 Jan 2010 17:05:16 +0000
Subject: [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: <1264352716.82.0.664399869547.issue7764@psf.upfronthosting.co.za>


Changes by Jan Kaliszewski <zuo at chopin.edu.pl>:


----------
title: dictview -> Doc for itertools recipe consume is complicated and less efficient

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:06:22 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 24 Jan 2010 17:06:22 +0000
Subject: [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: <1264352782.51.0.366060037306.issue7764@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

(sorry! typed into a wrong field)

----------
nosy: +zuo
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:09:06 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 17:09:06 +0000
Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function
	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264352946.14.0.2303907734.issue7769@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

OK, thank you for the links!

Do you still want me to do anything (like test cases etc.)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7769>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:19:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 17:19:16 +0000
Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function
	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264353556.64.0.859940167248.issue7769@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Once you get a Subversion checkout of the source, have a look in Lib/test/test_xmlrpc.py for examples of how things are currently tested (using unittest). Once you get a feel for it, add new tests for what your changes do. The file you paste'd looks good as an example, you just have to make actual tests out of it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7769>
_______________________________________

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: [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 18:21:02 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 17:21:02 +0000
Subject: [issue7769] SimpleXMLRPCServer.SimpleXMLRPCServer.register_function
	as decorator
In-Reply-To: <1264337326.51.0.913533963705.issue7769@psf.upfronthosting.co.za>
Message-ID: <1264353662.9.0.867703896917.issue7769@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

OK, will work on it and reply as soon as I have results!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7769>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:29:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 17:29:45 +0000
Subject: [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: <1264354185.99.0.747743407974.issue7764@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Changeset r77721 should be ported to trunk, and py3k probably.

----------
nosy: +flox
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sun Jan 24 18:34:29 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 17:34:29 +0000
Subject: [issue7269] buildbot occasional DBFileExistsError failures in
	test_bsddb3
In-Reply-To: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
Message-ID: <1264354469.34.0.0939295184232.issue7269@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It may occur on any platform.
The patch fixes the issue.

----------
title: Windows buildbot occasional DBFileExistsError failures in test_bsddb3 -> buildbot occasional DBFileExistsError failures in test_bsddb3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7269>
_______________________________________

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: [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 19:51:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 18:51:11 +0000
Subject: [issue7772] test_py3kwarn fails when running the whole test suite
In-Reply-To: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>
Message-ID: <1264359071.72.0.211190573361.issue7772@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Here comes the patch:
 - use test_support.__warningregistry__ to check past warnings
 - filter the warnings with "(module|package)", to be sure that they are silenced by "test_support.import_module"
 - fix test_reduce_move (it failed when run after test_unittest)


Note:
 - it requires that all "deprecated" imports are filtered through the "test_support.import_module" function (issue #7092)

----------
dependencies: +Test suite emits many DeprecationWarnings when -3 is enabled
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file15992/issue7772_py3kwarn.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7772>
_______________________________________

From report at bugs.python.org  Sun Jan 24 20:03:16 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Jan 2010 19:03:16 +0000
Subject: [issue7713] implement ability to disable automatic search path
	additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1264359796.23.0.251317064203.issue7713@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7713>
_______________________________________

From report at bugs.python.org  Sun Jan 24 20:28:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 19:28:48 +0000
Subject: [issue7772] test_py3kwarn fails when running the whole test suite
In-Reply-To: <1264358547.08.0.209937802024.issue7772@psf.upfronthosting.co.za>
Message-ID: <1264361328.21.0.0535071282491.issue7772@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7772>
_______________________________________

From report at bugs.python.org  Sun Jan 24 20:39:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Jan 2010 19:39:01 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264361941.71.0.00307272315632.issue7770@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll look at it when I get a chance.  Want to continue to show how the same recipe can work for different input types.  I may just document the function's range of inputs.

----------
assignee: georg.brandl -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 20:41:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Jan 2010 19:41:33 +0000
Subject: [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: <1264362093.41.0.539539817846.issue7764@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Remain calm.  I left the status as Open for a reason.  When I'm satisfied that people are reacting well to the new update, will port to other versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Sun Jan 24 20:58:08 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 19:58:08 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264363088.5.0.503784444927.issue7770@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

This adds two further lines, so you can pass int's, float's or Decimal types to the function.

def sin(x):
    """Return the sine of x as measured in radians.

    >>> print sin(Decimal('0.5'))
    0.4794255386042030002732879352
    >>> print sin(0.5)
    0.479425538604
    >>> print sin(0.5+0j)
    (0.479425538604+0j)

    """
    getcontext().prec += 2
    if not isinstance(x, Decimal):
        x = Decimal(x)
    x = x.remainder_near(2*pi())
    i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i * (i-1)
        num *= x * x
        sign *= -1
        s += num / fact * sign
    getcontext().prec -= 2
    return +s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Jan 24 20:58:57 2010
From: report at bugs.python.org (=?utf-8?q?Johannes_Sch=C3=B6nberger?=)
Date: Sun, 24 Jan 2010 19:58:57 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264363137.86.0.386697565497.issue7770@psf.upfronthosting.co.za>


Johannes Sch?nberger <jls at icoost.com> added the comment:

sorry, forgot the str:

def rsin(x):
    """Return the sine of x as measured in radians.

    >>> print sin(Decimal('0.5'))
    0.4794255386042030002732879352
    >>> print sin(0.5)
    0.479425538604
    >>> print sin(0.5+0j)
    (0.479425538604+0j)

    """
    getcontext().prec += 2
    if not isinstance(x, Decimal):
        x = Decimal(str(x))
    x = x.remainder_near(2*pi())
    i, lasts, s, fact, num, sign = 1, 0, x, 1, x, 1
    while s != lasts:
        lasts = s
        i += 2
        fact *= i * (i-1)
        num *= x * x
        sign *= -1
        s += num / fact * sign
    getcontext().prec -= 2
    return +s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

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: [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  Sun Jan 24 21:11:30 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Jan 2010 20:11:30 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264363890.7.0.0464459141236.issue7773@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Sun Jan 24 21:15:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jan 2010 20:15:27 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1264364127.95.0.78983313262.issue7771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Sun Jan 24 21:17:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Jan 2010 20:17:14 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1264364234.32.0.284884313184.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

After looking into this again, the testing situations are much different than I had originally written.

Some of the tests aren't really valid exercises. For one, the querying/enabling/disabling of reflection keys aren't good tests as they aren't tested against reflected keys. Windows 7 and Server 2008 R2 act differently in reflection situations when compared to XP/Vista/Server 2003, and I'll need to account for that.

For now, forget about the current patches, I'm working on a more correct testing approach.

----------
assignee:  -> brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7347>
_______________________________________

From report at bugs.python.org  Sun Jan 24 22:51:43 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jan 2010 21:51:43 +0000
Subject: [issue7269] buildbot occasional DBFileExistsError failures in
	test_bsddb3
In-Reply-To: <1257476332.86.0.346139621294.issue7269@psf.upfronthosting.co.za>
Message-ID: <1264369903.16.0.599805932764.issue7269@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77733 (trunk) and r77734 (release26-maint), thanks for the patch!

----------
assignee: jcea -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7269>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:04:38 2010
From: report at bugs.python.org (John Marter)
Date: Sun, 24 Jan 2010 22:04:38 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1264370678.93.0.566002072265.issue4570@psf.upfronthosting.co.za>


John Marter <jmarter at gmail.com> added the comment:

I see that the spelling of banana has been fixed but what is the purpose of assigning fruit and then immediately reassigning it another value without even looking at the first assignment?

>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> fruit = set(basket)               # create a set without duplicates

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4570>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:15:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:15:26 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264371326.82.0.309341312001.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15928/issue7092_filterwarnings_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:15:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:15:30 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264371330.52.0.0830320249336.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15929/issue7092_syntax_imports_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:15:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:15:38 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264371338.42.0.419480690388.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15788/issue7092_check_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:16:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:16:59 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264371419.15.0.0221710991065.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15994/issue7092_syntax_imports_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:17:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:17:57 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264371477.89.0.580695068617.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file15995/issue7092_check_warnings_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:24:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:24:31 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264371871.97.0.280818263834.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Re-uploaded after fixes for #7737.

To remove all "-3" warnings:
 - apply the 4 patches
 - fix SQLite "buffer()" warnings (issue #7223)

----------
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file15996/issue7092_filterwarnings_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:39:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 22:39:05 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1264372745.11.0.285161123997.issue4570@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed in trunk and 3.1

----------
nosy: +flox
resolution: fixed -> 
stage:  -> needs patch
status: closed -> open
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4570>
_______________________________________

From report at bugs.python.org  Sun Jan 24 23:45:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Jan 2010 22:45:58 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264373158.23.0.914376531963.issue7773@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

An accompanying test would be wonderful.

----------
nosy: +benjamin.peterson

_______________________________________
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: [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 00:24:09 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 24 Jan 2010 23:24:09 +0000
Subject: [issue7774] subprocess executable option wrong location
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264375449.91.0.905273926905.issue7774@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Notice that this happen only under Linux and Solaris AFAIK. I couldn't reproduce it under Mac OS X

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 00:28:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jan 2010 23:28:39 +0000
Subject: [issue7774] subprocess executable option wrong location
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264375719.3.0.907373532308.issue7774@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 00:39:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 23:39:28 +0000
Subject: [issue7774] subprocess executable option wrong location
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264376368.6.0.918277313429.issue7774@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed on all Python versions.

Same behaviour without subprocess:
~ $ sh -c "exec -a missingfile python -c 'import sys; print sys.executable'"
/home/name/

----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 00:39:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 23:39:51 +0000
Subject: [issue7774] subprocess executable option wrong location
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264376391.32.0.991574510685.issue7774@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
versions: +Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 00:40:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 24 Jan 2010 23:40:53 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264376453.94.0.830919201396.issue7774@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: subprocess executable option wrong location -> sys.executable: wrong location if zeroth command argument is modified.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 02:19:34 2010
From: report at bugs.python.org (Muhammad Alkarouri)
Date: Mon, 25 Jan 2010 01:19:34 +0000
Subject: [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: <1264382374.35.0.217301429091.issue7764@psf.upfronthosting.co.za>


Muhammad Alkarouri <malkarouri at gmail.com> added the comment:

Mea culpa. Not knowing the conventions here, I closed the ticket, which probably resulted in florent's feedback. I will leave you to it then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Mon Jan 25 02:40:12 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 25 Jan 2010 01:40:12 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264383612.22.0.829304036246.issue7774@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I'm not the subprocess owner Tarek :(

----------
assignee: jnoller -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 03:22:50 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 25 Jan 2010 02:22:50 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264386170.86.0.101063655437.issue7773@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Updated the patch to add a test case in 'test_platform'.  I also added a comment explaining the change and removed a redundant assignment.

----------
nosy: +minge
Added file: http://bugs.python.org/file15997/issue-7773.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Mon Jan 25 03:22:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2010 02:22:56 +0000
Subject: [issue4570] Bad example in set tutorial
In-Reply-To: <1228612211.41.0.0899785129664.issue4570@psf.upfronthosting.co.za>
Message-ID: <1264386176.29.0.297182977362.issue4570@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4570>
_______________________________________

From report at bugs.python.org  Mon Jan 25 03:59:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 25 Jan 2010 02:59:07 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264388347.13.0.823682523789.issue7773@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Mon Jan 25 04:31:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Jan 2010 03:31:36 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264390296.94.0.245734168742.issue7773@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the patch! Applied in r77735.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

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: [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: [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 05:57:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 25 Jan 2010 04:57:07 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264395427.1.0.0731630793384.issue7776@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Mon Jan 25 06:44:12 2010
From: report at bugs.python.org (Richard Hansen)
Date: Mon, 25 Jan 2010 05:44:12 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1264398252.83.0.590485125747.issue7615@psf.upfronthosting.co.za>


Richard Hansen <rhansen at bbn.com> added the comment:

Any comments on the patches?  I'd love to see at least patches 1-3 make it into Python 2.7.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7615>
_______________________________________

From report at bugs.python.org  Mon Jan 25 06:46:39 2010
From: report at bugs.python.org (Cameron Simpson)
Date: Mon, 25 Jan 2010 05:46:39 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264398399.87.0.322905740465.issue7776@psf.upfronthosting.co.za>


Cameron Simpson <cs at zip.com.au> added the comment:

Amendment: regarding the infinite regress, it looks like there will not be a recursion if the caller leaps straight to the .connect() method. However, if they do that then the call to _tunnel() from within connect() will happen _after_ the socket is made directly to the origin host, not via the proxy. So the behaviour seems incorrect then also; it looks very much like _tunnel() must always be called before the real socket connection is established, and .connect() calls _tunnel() afterwards, not before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Mon Jan 25 07:22:17 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Jan 2010 06:22:17 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264400537.12.0.920853327073.issue7776@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Mon Jan 25 07:54:18 2010
From: report at bugs.python.org (Chris Withers)
Date: Mon, 25 Jan 2010 06:54:18 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>


New submission from Chris Withers <chris at simplistix.co.uk>:

Can you please provide information about the actual problem you're reporting?

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 07:57:45 2010
From: report at bugs.python.org (Cameron Simpson)
Date: Mon, 25 Jan 2010 06:57:45 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264402665.92.0.141204621596.issue7776@psf.upfronthosting.co.za>


Cameron Simpson <cs at zip.com.au> added the comment:

It's looking like I have my idea of .host versus ._tunnel_host swapped. I think things are still buggy, but my interpretation of the bug is wrong or misleading.

I gather that after _set_tunnel(), .host is the proxy host and that ._tunnel_host is the original target host.

I'll follow up here in a bit when I've better characterised the problem.
I think I'm letting urllib2's complicated state stuff confuse me too...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Mon Jan 25 08:01:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Jan 2010 07:01:06 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1264402866.56.0.537967682492.issue7621@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7621>
_______________________________________

From report at bugs.python.org  Mon Jan 25 08:01:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Jan 2010 07:01:28 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1262450907.6.0.524108589463.issue7621@psf.upfronthosting.co.za>
Message-ID: <1264402888.38.0.00506738287408.issue7621@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Generate a message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7621>
_______________________________________

From report at bugs.python.org  Mon Jan 25 08:01:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Jan 2010 07:01:59 +0000
Subject: [issue7621] Test issue
In-Reply-To: <1264402888.38.0.00506738287408.issue7621@psf.upfronthosting.co.za>
Message-ID: <4B5D41E3.4040000@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Generate a message.

Reply to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7621>
_______________________________________

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: [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 08:34:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Jan 2010 07:34:00 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1264404840.1.0.425570662934.issue7777@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A patch has good chances of getting accepted (eventually; it may take several months or years). Test cases and documentation changes should be included.

Supporting generic socket addresses can't work (IMO): how could Python possibly know how to map a Python representation of the address (which is likely a tuple of some kind) onto a struct sockaddr?

----------
nosy: +loewis
versions:  -Python 2.5, Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7777>
_______________________________________

From report at bugs.python.org  Mon Jan 25 08:58:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 25 Jan 2010 07:58:32 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264406312.89.0.336972416102.issue7775@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 09:06:13 2010
From: report at bugs.python.org (kai zhu)
Date: Mon, 25 Jan 2010 08:06:13 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264406773.19.0.0928279753557.issue7775@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

documentation bug
should be changed to:

"S.rpartition(sep) -> (head, sep, tail)"



>>> help(str.rpartition)
Help on method_descriptor:

rpartition(...)
    S.rpartition(sep) -> (tail, sep, head)

    Search for the separator sep in S, starting at the end of S, and return
    the part before it, the separator itself, and the part after it.  If the
    separator is not found, return two empty strings and S.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 09:12:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 25 Jan 2010 08:12:24 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264407144.98.0.325847672071.issue7775@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 10:19:28 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 25 Jan 2010 09:19:28 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264411168.73.0.00104011294332.issue7775@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

Not only str, but also bytearray, unicode, and bytes.

----------
keywords: +patch
nosy: +july
Added file: http://bugs.python.org/file15998/rpartition-docstrings-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 10:19:52 2010
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 25 Jan 2010 09:19:52 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264411192.25.0.259197065753.issue7775@psf.upfronthosting.co.za>


Changes by July Tikhonov <july.tikh at gmail.com>:


Added file: http://bugs.python.org/file15999/rpartition-docstrings-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 10:21:39 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Jan 2010 09:21:39 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1264398252.83.0.590485125747.issue7615@psf.upfronthosting.co.za>
Message-ID: <4B5D62A0.8080900@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Richard Hansen wrote:
> 
> Richard Hansen <rhansen at bbn.com> added the comment:
> 
> Any comments on the patches?  I'd love to see at least patches 1-3 make it into Python 2.7.  :)

Sorry, I haven't had a chance to review them yet. Will try today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7615>
_______________________________________

From report at bugs.python.org  Mon Jan 25 10:24:41 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Jan 2010 09:24:41 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264411481.99.0.525693274079.issue7773@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Could you provide a dump of the (whole) release file ?

It's a bit strange to have an empty release file.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Mon Jan 25 10:31:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2010 09:31:56 +0000
Subject: [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: <1264411916.47.0.37198602858.issue7764@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

No problem.
Will forward port when I get a chance.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Mon Jan 25 10:46:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 25 Jan 2010 09:46:43 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1264412803.06.0.213570961951.issue7615@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7615>
_______________________________________

From report at bugs.python.org  Mon Jan 25 11:44:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jan 2010 10:44:41 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264416281.6.0.562514584252.issue7775@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 12:28:53 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 Jan 2010 11:28:53 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264418933.29.0.144877192018.issue7773@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

My release file actually is correct (non-empty).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Mon Jan 25 12:35:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 25 Jan 2010 11:35:07 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264418933.29.0.144877192018.issue7773@psf.upfronthosting.co.za>
Message-ID: <4B5D81E8.2000209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Arfrever Frehtes Taifersar Arahesis wrote:
> 
> Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:
> 
> My release file actually is correct (non-empty).

Could you post it on the ticket, so that I can check what's
causing the problem ?!

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Mon Jan 25 12:41:53 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 Jan 2010 11:41:53 +0000
Subject: [issue7773] platform._parse_release_file() can cause UnboundLocalError
In-Reply-To: <1264363807.73.0.89179918578.issue7773@psf.upfronthosting.co.za>
Message-ID: <1264419713.27.0.625489546485.issue7773@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

A user of Portage had incorrect release file.
https://bugs.gentoo.org/show_bug.cgi?id=301848

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7773>
_______________________________________

From report at bugs.python.org  Mon Jan 25 13:03:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jan 2010 12:03:40 +0000
Subject: [issue7775] str.rpartition(sep) -> (tail, sep, head)
In-Reply-To: <1264402458.9.0.430084513463.issue7775@psf.upfronthosting.co.za>
Message-ID: <1264421020.07.0.967029255596.issue7775@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77743 (trunk), r77744 (release26-maint), r77745 (py3k) and r77746 (release31-maint), thanks for the patches!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7775>
_______________________________________

From report at bugs.python.org  Mon Jan 25 13:09:58 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 25 Jan 2010 12:09:58 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264421398.87.0.796085342234.issue7774@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Ooops sorry Jesse, my brain has a hard link to your name when I see the word "process" ;)

It comes out this bug is more related to 'sys' anyways.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 13:57:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Jan 2010 12:57:06 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264424226.31.0.335022877969.issue7774@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

How would you suggest to implement sys.executable if not by looking at sys.argv[0] (or the C equivalent, rather)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 14:06:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 25 Jan 2010 13:06:04 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264424764.68.0.913730662553.issue7774@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It may help to find other methods:
http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe


By the way, it should not "absolutize" the path when sys.executable is irrelevant. IMHO, it should render an empty thing in such case (code below).


--- Modules/getpath.c   (revision 77750)
+++ Modules/getpath.c   (working copy)
@@ -441,7 +441,7 @@
        }
        else
                progpath[0] = '\0';
-       if (progpath[0] != SEP)
+       if (progpath[0] != SEP && progpath[0] != '\0')
                absolutize(progpath);
        strncpy(argv0_path, progpath, MAXPATHLEN);
        argv0_path[MAXPATHLEN] = '\0';

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

From report at bugs.python.org  Mon Jan 25 14:06:40 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 25 Jan 2010 13:06:40 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1264424800.93.0.913899463011.issue7774@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

readlink("/proc/self/exe") would work on linux. (there's a similar link on freebsd).

----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7774>
_______________________________________

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: [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 14:32:42 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 25 Jan 2010 13:32:42 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1264426362.88.0.491051790866.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

I compile it with -lpthread.
os.fork1() was not available by default, I enabled it by removing two lines from posixmodule.c (it seems it's only enabled when #if defined(__USLC__) && defined(__SCO_VERSION__) is true).

With os.fork1() I have the same results, RuntimeError.

I was not able to compile it without pthread because I haven't found any configure options for that. If it's possible I'm happy to try it.

In my patch I wanted to reduce the effect on systems where forking in thread is working (eg. linux), that's the reason why I added "(defined (__SVR4) && defined (__sun)". But it just checks for solaris, not the OS version (on solaris 10/intel my demo is working).

(btw forking in thread  actually happens in a unittest related to BaseHTTPServer, which obviously fails on my platform)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Mon Jan 25 14:54:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 25 Jan 2010 13:54:03 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1262316507.32.0.63969926675.issue7615@psf.upfronthosting.co.za>
Message-ID: <1264427643.29.0.225238610182.issue7615@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I feel uneasy to change the default unicode-escape encoding.
I think that we mix two features here; to transfer a unicode string between two points, programs must agree on where the data ends, and how characters are represented as bytes.
All codecs including unicode-escape only dealt with byte conversion; (unicode-escape converts everything to printable 7bit ascii);
these patches want to add a feature related to the "where does the string end" issue, and is only aimed at "python code" containers. Other transports and protocols may choose different delimiters.

My point is that unicode-escape used to not change printable 7-bit ascii characters, and the patches will change this.

And actually this will break existing code. It did not take me long to find two examples of programs which embed unicode_escape-encoded text between quotes, and take care themselves of escaping quotes. First example generates javascript code, the second generates SQL statements:
http://github.com/chriseppstein/pywebmvc/blob/master/src/code/pywebmvc/tools/searchtool.py#L450
http://gitweb.sabayon.org/?p=entropy.git;a=blob;f=libraries/entropy/db/__init__.py;h=2d818455efa347f35b2e96d787fefd338055d066;hb=HEAD#l6463

This does not prevent the creation of a new codec, let's call it 'python-unicode-escape' [ or 'repr' :-) ]

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7615>
_______________________________________

From report at bugs.python.org  Mon Jan 25 15:25:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 25 Jan 2010 14:25:07 +0000
Subject: [issue7777] Support needed for AF_RDS family
In-Reply-To: <1264404460.15.0.913920533968.issue7777@psf.upfronthosting.co.za>
Message-ID: <1264429507.53.0.0155732828522.issue7777@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7777>
_______________________________________

From report at bugs.python.org  Mon Jan 25 16:08:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jan 2010 15:08:17 +0000
Subject: [issue7778] Typo(s) in ``itertools`` documentation reST marker
In-Reply-To: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>
Message-ID: <1264432097.83.0.908255362518.issue7778@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7778>
_______________________________________

From report at bugs.python.org  Mon Jan 25 16:11:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jan 2010 15:11:17 +0000
Subject: [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: <1264432277.93.0.442781870842.issue7764@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Raymond, before porting you should check the typos reported in issue #7778.

----------
dependencies: +Typo(s) in ``itertools`` documentation reST marker
nosy: +ezio.melotti
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7764>
_______________________________________

From report at bugs.python.org  Mon Jan 25 16:47:52 2010
From: report at bugs.python.org (Michael Smith)
Date: Mon, 25 Jan 2010 15:47:52 +0000
Subject: [issue7757] sys.path is incorrect when prefix is ""
In-Reply-To: <1264178776.01.0.552667161926.issue7757@psf.upfronthosting.co.za>
Message-ID: <1264434472.06.0.321131950629.issue7757@psf.upfronthosting.co.za>


Michael Smith <msmith at cbnco.com> added the comment:

Yes, that does look related. The fix from Issue1676135 seems to handle --prefix="/" properly, and from what I can tell PREFIX does get set to "/".

There is also code in getpath.c to set sys.prefix to "/" if it's "".

The correct prefix for configure is actually "", not "/", to avoid double-slashes - but neither one seems to work at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7757>
_______________________________________

From report at bugs.python.org  Mon Jan 25 17:10:45 2010
From: report at bugs.python.org (=?utf-8?q?Vincent_F=C3=A9rotin?=)
Date: Mon, 25 Jan 2010 16:10:45 +0000
Subject: [issue7778] Typo(s) in ``itertools`` documentation reST marker
In-Reply-To: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>
Message-ID: <1264435845.1.0.42451597465.issue7778@psf.upfronthosting.co.za>


Vincent F?rotin <vincent.ferotin at gmail.com> added the comment:

Add patch fixing typo for sample code.

----------
keywords: +patch
Added file: http://bugs.python.org/file16000/fix_7778-typo_in_itertools_documentation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7778>
_______________________________________

From report at bugs.python.org  Mon Jan 25 17:14:29 2010
From: report at bugs.python.org (=?utf-8?q?Vincent_F=C3=A9rotin?=)
Date: Mon, 25 Jan 2010 16:14:29 +0000
Subject: [issue7778] Typo(s) in ``itertools`` documentation reST marker
In-Reply-To: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>
Message-ID: <1264436069.06.0.785264920155.issue7778@psf.upfronthosting.co.za>


Vincent F?rotin <vincent.ferotin at gmail.com> added the comment:

Add patch fixing typo for sample code, and changing ``dotproduct`` emphasis (``*dotproduct*``) to literal (``\``dotproduct\````).

----------
Added file: http://bugs.python.org/file16001/fix_7778-typo_in_itertools_documentation-literal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7778>
_______________________________________

From report at bugs.python.org  Mon Jan 25 20:22:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jan 2010 19:22:23 +0000
Subject: [issue7778] Typo(s) in ``itertools`` documentation reST marker
In-Reply-To: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>
Message-ID: <1264447343.88.0.644506752136.issue7778@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed double colon issue.
Leaving the *dotproduct* markup as-is.
Thanks for the report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7778>
_______________________________________

From report at bugs.python.org  Mon Jan 25 20:47:52 2010
From: report at bugs.python.org (=?utf-8?q?Vincent_F=C3=A9rotin?=)
Date: Mon, 25 Jan 2010 19:47:52 +0000
Subject: [issue7778] Typo(s) in ``itertools`` documentation reST marker
In-Reply-To: <1264426142.42.0.81396869188.issue7778@psf.upfronthosting.co.za>
Message-ID: <1264448872.83.0.926843449451.issue7778@psf.upfronthosting.co.za>


Vincent F?rotin <vincent.ferotin at gmail.com> added the comment:

Ok, thanks for reviewing and fixing!

----------

_______________________________________
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: [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 21:55:09 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 25 Jan 2010 20:55:09 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264452909.55.0.458998133044.issue7779@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

There's no bug here.  You've misunderstood how the literal \0 syntax works.  Perhaps this will clarify things:

  >>> list('\0123')
  ['\n', '3']
  >>> list('\x00123')
  ['\x00', '1', '2', '3']
  >>>

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 21:56:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Jan 2010 20:56:28 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264452988.4.0.151081119977.issue7779@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 21:57:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jan 2010 20:57:29 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264453049.44.0.42476736807.issue7779@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 22:05:06 2010
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Surkamp?=)
Date: Mon, 25 Jan 2010 21:05:06 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264453506.56.0.425446163145.issue7779@psf.upfronthosting.co.za>


S?rgio Surkamp <sergio at gruposinternet.com.br> added the comment:

The SASL protocol says that the encoded base64 should be formed from:

null + login + null + password

The smtplib is not doing it, instead its "converting" the \012 (\0 + 2 first chars from password) in the char "\n", and it's right in the python way to see the things, it's not the bug reported here. The bug is a patch to change the null character representation from \0 to \x00 (using the hexadecimal representation) in the encode_base64 call to prevent the "conversion" and generate the right base64 encoded string.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 22:06:20 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 25 Jan 2010 21:06:20 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264453580.98.0.216442015494.issue7779@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

It doesn't matter whether \0 or \x00 is used.  They mean the same thing.  Maybe this is the example I should have given:

  >>> list('\0%s' % ('12',))
  ['\x00', '1', '2']
  >>> list('\x00%s' % ('12',))
  ['\x00', '1', '2']
  >>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 22:15:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Jan 2010 21:15:30 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1264426362.88.0.491051790866.issue7242@psf.upfronthosting.co.za>
Message-ID: <4B5E09EF.3060708@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> In my patch I wanted to reduce the effect on systems where forking in
> thread is working (eg. linux), that's the reason why I added
> "(defined (__SVR4) && defined (__sun)". 

I think that's inappropriate, please change that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Mon Jan 25 22:16:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jan 2010 21:16:19 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264454179.17.0.364331085762.issue7779@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 22:22:22 2010
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Surkamp?=)
Date: Mon, 25 Jan 2010 21:22:22 +0000
Subject: [issue7779] smtplib SASL PLAIN authentication error
In-Reply-To: <1264452779.18.0.958137638395.issue7779@psf.upfronthosting.co.za>
Message-ID: <1264454542.82.0.342588132145.issue7779@psf.upfronthosting.co.za>


S?rgio Surkamp <sergio at gruposinternet.com.br> added the comment:

Got your point. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7779>
_______________________________________

From report at bugs.python.org  Mon Jan 25 22:38:49 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 25 Jan 2010 21:38:49 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264455529.26.0.82142153993.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hello

Just to notify that I've just tested this patch on a fresh python2.6 SVN checkout, on Ubuntu this time (previously, it was only win32), and it passes all IO-related tests I know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

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: [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 00:59:30 2010
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 25 Jan 2010 23:59:30 +0000
Subject: [issue4440] "sort" command doesn't work in pstats if run interactively
In-Reply-To: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>
Message-ID: <1264463970.22.0.847663050107.issue4440@psf.upfronthosting.co.za>


Mitchell Model <mlm at acm.org> added the comment:

Still true in 3.1

----------
nosy: +MLModel
versions: +Python 3.1 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4440>
_______________________________________

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: [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 01:25:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 00:25:38 +0000
Subject: [issue6710] hotshot stats load causes TypeError when multiple files
	are loaded
In-Reply-To: <1250374338.11.0.481034078931.issue6710@psf.upfronthosting.co.za>
Message-ID: <1264465538.19.0.433778136019.issue6710@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is a duplicate of #7372.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> Regression in pstats

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6710>
_______________________________________

From report at bugs.python.org  Tue Jan 26 01:35:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 00:35:54 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1264466154.89.0.121708601728.issue7372@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #7372.

AFAIU add_callers can receive either a tuple or an int (and this is what is not working now). When I looked at #7372 I wasn't able to find out why it might receive two different objects and not always the same (i.e. always a tuple, possibly with only one int). From the first message it seems that cProfile returns the tuple of 4 ints and profile returns a single int.
Can profile be fixed to return a tuple (of 4 or 1 ints) too?

----------
nosy: +alexandre.vassalotti, ezio.melotti, fdrake, j1m
priority:  -> normal
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Tue Jan 26 01:39:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 00:39:44 +0000
Subject: [issue7781] interactive pstats broken
In-Reply-To: <1264464159.48.0.243673781455.issue7781@psf.upfronthosting.co.za>
Message-ID: <1264466384.67.0.25186596258.issue7781@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7781>
_______________________________________

From report at bugs.python.org  Tue Jan 26 01:43:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 00:43:57 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1258765391.77.0.857956675588.issue7372@psf.upfronthosting.co.za>
Message-ID: <1264466637.7.0.837956732339.issue7372@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I meant "See also #6710".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Tue Jan 26 02:06:42 2010
From: report at bugs.python.org (Craig McQueen)
Date: Tue, 26 Jan 2010 01:06:42 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1264468002.06.0.0627214993591.issue1205239@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Just for the record... here is a relevant use case...

I'm working on some code for calculating CRCs, and hope to support any CRC width, including CRC-5. This involves, among the calculations:

    crc >> (crc_width - 8)

The complete expression is:

    crc = table[((crc >> (crc_width - 8)) ^ data_byte) & 0xFF] ^ (crc << 8)

where crc_width is typically 32 or 16, but in the case of CRC-5 would be 5.

I think the calculation would work fine for all cases, if only Python allowed me to right-shift with a negative number. But now I'll have to handle the two cases separately.

----------
nosy: +cmcqueen1975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205239>
_______________________________________

From report at bugs.python.org  Tue Jan 26 02:07:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 01:07:03 +0000
Subject: [issue7765] 'unittest' documentation misprints
In-Reply-To: <1264275798.04.0.174559060611.issue7765@psf.upfronthosting.co.za>
Message-ID: <1264468023.88.0.547658428884.issue7765@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7765>
_______________________________________

From report at bugs.python.org  Tue Jan 26 02:08:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 01:08:10 +0000
Subject: [issue7728] test_timeout should use "find_unused_port" helper
In-Reply-To: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>
Message-ID: <1264468090.7.0.397579011987.issue7728@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7728>
_______________________________________

From report at bugs.python.org  Tue Jan 26 02:37:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Jan 2010 01:37:06 +0000
Subject: [issue7765] 'unittest' documentation misprints
In-Reply-To: <1264275798.04.0.174559060611.issue7765@psf.upfronthosting.co.za>
Message-ID: <1264469826.92.0.831727711758.issue7765@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Another one-liner, stopTestRun

----------
nosy: +brian.curtin
Added file: http://bugs.python.org/file16002/stopTestRun.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7765>
_______________________________________

From report at bugs.python.org  Tue Jan 26 02:39:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Jan 2010 01:39:20 +0000
Subject: [issue4440] "sort" command doesn't work in pstats if run interactively
In-Reply-To: <1227711651.41.0.519645038553.issue4440@psf.upfronthosting.co.za>
Message-ID: <1264469960.65.0.126496064894.issue4440@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4440>
_______________________________________

From report at bugs.python.org  Tue Jan 26 02:53:47 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Jan 2010 01:53:47 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1264470827.17.0.107077838739.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Amaury, that was a good suggestion, but I did with Eric's help track down a mechanism to test for the presence of the symlink creation privilege. I prefer to have a proper check rather than to attempt to create one and test for the failure message because it doesn't have the potential to be confounded with other causes. I want to avoid issues such as where is the test symlink created and how is it cleaned up. If there's still desire to go that route after looking at this implementation, I'm not opposed to switching gears and using that technique.

This patch (20) uses ctypes (in the test suite; is that okay?) to determine if the symlink creation privilege is present, falling back to the assumption that it is, and integrates that with the test.support.has_symlink function (which is new in this issue thread).

Eric, can you test this new patch in your limited user environment and report what you find?

----------
Added file: http://bugs.python.org/file16003/windows symlink draft 20.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Tue Jan 26 03:24:07 2010
From: report at bugs.python.org (Cameron Simpson)
Date: Tue, 26 Jan 2010 02:24:07 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264472647.78.0.760930244515.issue7776@psf.upfronthosting.co.za>


Cameron Simpson <cs at zip.com.au> added the comment:

Well, I've established a few things:
  - I'm mischaracterised this issue
  - httplib's _set_tunnel() is really meant to be called from
    urllib2, because using it directly with httplib is totally
    counter intuitive
  - a bare urllib2 setup fails with its own bug

To the first item: _tunnel() feels really fragile with that recursion issue, though it doesn't recurse called from urllib2.

For the second, here's my test script using httplib:

  H = httplib.HTTPSConnection("localhost", 3128)
  print H
  H._set_tunnel("localhost", 443)
  H.request("GET", "/boguspath")
  os.system("lsof -p %d | grep IPv4" % (os.getpid(),))
  R = H.getresponse()
  print R.status, R.reason

As you can see, one builds the HTTPSConnection object with the proxy's details instead of those of the target URL, and then put the target URL details in with _set_tunnel(). Am I alone in find this strange?

For the third, my test code is this:

  U = urllib2.Request('https://localhost/boguspath')
  U.set_proxy('localhost:3128', 'https')
  f = urllib2.urlopen(R)
  print f.read()

which fails like this:

  Traceback (most recent call last):
    File "thttp.py", line 15, in <module>
      f = urllib2.urlopen(R)
    File "/opt/python-2.6.4/lib/python2.6/urllib2.py", line 131, in urlopen
      return _opener.open(url, data, timeout)
    File "/opt/python-2.6.4/lib/python2.6/urllib2.py", line 395, in open
      protocol = req.get_type()
  AttributeError: HTTPResponse instance has no attribute 'get_type'

The line numbers are slightly off because I've got some debugging statements in there.

Finally, I flat out do not understand urllib2's set_proxy() method:
  
    def set_proxy(self, host, type):
        if self.type == 'https' and not self._tunnel_host:
            self._tunnel_host = self.host
        else:
            self.type = type
            self.__r_host = self.__original
        self.host = host

When my code calls set_proxy, self.type is None. Now, I had naively expected the first branch to be the only branch. Could someone explain what's happening here, and what is meant to happen?

I'm thinking that this bug may turn into a doc fix instead of a behaviour fix, but I'm finding it surprisingly hard to know how urllib2 is supposed to be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Tue Jan 26 04:08:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jan 2010 03:08:39 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264475319.23.0.146535977649.issue7776@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

As you noticed, the _set_tunnel method is a private method not intended to be used directly. Its being used by urllib2 when https through proxy is required.
urllib2 works like this, it reads HTTPS_PROXY environment variable (in turn includes HTTPSProxyHandler and HTTPSProxyAuthenticationHandler) and then try to do a urlopen on an https:// url or a request object through the tunnel doing a  CONNECT instead of a GET.

How do think the docs can be improved? If you have any suggestions please upload a patch. 
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Tue Jan 26 04:45:50 2010
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 26 Jan 2010 03:45:50 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1264477550.96.0.198323795375.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Attached is the ported patch for Python 2.7/trunk. Please review it to make sure I didn't completely flub anything. I noticed you had forgotten the maxtasksperchild argument in the unit test, so I added that. I also expanded the docs a little but, paraphrasing your original post w.r.t to the justification.

Let me know what you think, or if you have issues. Once you give the go ahead, I will commit to trunk and then merge to Py3k. 

Once again, thanks for the patch

----------
Added file: http://bugs.python.org/file16004/mp_patch_6963_trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Jan 26 05:17:32 2010
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio?=)
Date: Tue, 26 Jan 2010 04:17:32 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1264479452.04.0.341287821485.issue2987@psf.upfronthosting.co.za>


S?rgio <sergio at sergiomb.no-ip.org> added the comment:

Hi, with python-2.6.2-2.fc12.i686

In: x ="http://www.somesite.com/images/rubricas/"
In: urlparse.urljoin(x, '07.11.2009-9:54:12-1.jpg')
Out: '07.11.2009-9:54:12-1.jpg' !?

In: urlparse.urljoin(x, './07.11.2009-9:54:12-1.jpg')
Out: 'http://www.somesite.com/images/rubricas/07.11.2009-9:54:12-1.jpg'

urlparse.urlparse('07.11.2009-9:54:12-1.jpg')
is wrong
but 
urlparse.urlparse('./07.11.2009-9:54:12-1.jpg')
isn't. 

think about that please

----------
nosy: +sergiomb2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Tue Jan 26 05:22:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jan 2010 04:22:40 +0000
Subject: [issue2987] RFC2732 support for urlparse (e.g. http://[::1]:80/)
In-Reply-To: <1211920837.73.0.839643919886.issue2987@psf.upfronthosting.co.za>
Message-ID: <1264479760.0.0.0803341441454.issue2987@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

okay, this should be easy to address. But the more important part is RFC compliance so that this simple change does not break many other things in the wild.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2987>
_______________________________________

From report at bugs.python.org  Tue Jan 26 07:57:58 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 26 Jan 2010 06:57:58 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1264489078.47.0.358153287824.issue7325@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

I have created a patch for this for Python 3.1 and included an update to the unit tests.  The tests were never checking for a relative path and if they did would pas it even when it would have failed due to liberal use of os.path.abspath()

The test fix is probably not as clean as it could be by I did not want to severely alter its state.  The change to tempfile.mkdtemp() was clear and followed the current method tempfile.mkstemp() uses.

----------
keywords: +patch
nosy: +Thomas.Holmes
Added file: http://bugs.python.org/file16005/Py7325.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Tue Jan 26 08:08:00 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 26 Jan 2010 07:08:00 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1264489680.67.0.0101188583792.issue7325@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

As a side note, this was done mostly as an exercise for myself and as a learning experience.  Any feedback would be appreciated regardless of any decision on the status of this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Tue Jan 26 08:36:22 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 07:36:22 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264491382.26.0.955960915298.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's an updated patch. I fixed some docstrings, modified it to work with the most recent assertIsInstance changes, and added #ifdef for Windows.

There are a number of test failures still, I think all of them relating to errors in platform.py where it calls sys.getwindowsversion() and unpacks the result. I'll look at those soon.

----------
Added file: http://bugs.python.org/file16006/winver_as_structseq_ex1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Tue Jan 26 08:58:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 07:58:55 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264492735.16.0.146692033017.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The more I think about this, the more concerned I am about changing the number of elements in the tuple. That's the change that broke platform.py. Maybe we should add a parameter named something like "level", defaulting to 0.

0 = existing behavior, but with named tuple
1 = return named 9-tuple OSVERSIONINFOEX values
other values: reserved for future use

Or maybe we should make it a bool instead, and not worry about future expansion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

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: [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:18:43 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 26 Jan 2010 08:18:43 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1264493923.72.0.473626106197.issue5689@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

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: [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 09:30:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 08:30:51 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1264494651.71.0.0437534943792.issue7783@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Here is a patch.

The function "test_support.open_urlresource" is enhanced with an optional argument "check" which receives a function. This "check" function accepts an open file as input and return False if the file is outdated.

----------
keywords: +patch
versions: +Python 3.2
Added file: http://bugs.python.org/file16007/issue7783_normalization.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Tue Jan 26 11:07:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Jan 2010 10:07:57 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264492735.16.0.146692033017.issue7766@psf.upfronthosting.co.za>
Message-ID: <4B5EBEFA.5050607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Eric Smith wrote:
> 
> Eric Smith <eric at trueblade.com> added the comment:
> 
> The more I think about this, the more concerned I am about changing the number of elements in the tuple. That's the change that broke platform.py. Maybe we should add a parameter named something like "level", defaulting to 0.
> 
> 0 = existing behavior, but with named tuple
> 1 = return named 9-tuple OSVERSIONINFOEX values
> other values: reserved for future use
> 
> Or maybe we should make it a bool instead, and not worry about future expansion.

The usual approach to such problems is keeping the number of tuple
items and their order the same and only add new items as additional
attributes to the struct.

See the CodecInfo tuple in codecs.py for an example on how this is
done. The tuple is still a 4-tuple, but it provides access to more
items via named attributes.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

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: [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 11:57:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 10:57:00 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1264503420.83.0.320339269682.issue1205239@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Interesting.  I agree that that looks like a case where it would be desirable for a >> -n to do a << n.

By the way, I don't think your formula is quite correct:  your crc is going to grow unboundedly as extra data bytes come in.  I suspect that you want to mask the result with (1 << crc_width) - 1 after each update.
(And what's the '& 0xFF' for?  Isn't it redundant?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205239>
_______________________________________

From report at bugs.python.org  Tue Jan 26 12:05:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 11:05:17 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1264503917.64.0.517034329401.issue1205239@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One other thought: you could always compute the expression

  crc >> (crc_width - 8)

as

  crc << 8 >> crc_width

Since you're computing crc << 8 anyway, this doesn't increase the operations count, so probably wouldn't significant impact performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205239>
_______________________________________

From report at bugs.python.org  Tue Jan 26 12:48:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Jan 2010 11:48:56 +0000
Subject: [issue7615] unicode_escape codec does not escape quotes
In-Reply-To: <1264427643.29.0.225238610182.issue7615@psf.upfronthosting.co.za>
Message-ID: <4B5ED6A3.3020607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> I feel uneasy to change the default unicode-escape encoding.
> I think that we mix two features here; to transfer a unicode string between two points, programs must agree on where the data ends, and how characters are represented as bytes.
> All codecs including unicode-escape only dealt with byte conversion; (unicode-escape converts everything to printable 7bit ascii);
> these patches want to add a feature related to the "where does the string end" issue, and is only aimed at "python code" containers. Other transports and protocols may choose different delimiters.
> 
> My point is that unicode-escape used to not change printable 7-bit ascii characters, and the patches will change this.
> 
> And actually this will break existing code. It did not take me long to find two examples of programs which embed unicode_escape-encoded text between quotes, and take care themselves of escaping quotes. First example generates javascript code, the second generates SQL statements:
> http://github.com/chriseppstein/pywebmvc/blob/master/src/code/pywebmvc/tools/searchtool.py#L450
> http://gitweb.sabayon.org/?p=entropy.git;a=blob;f=libraries/entropy/db/__init__.py;h=2d818455efa347f35b2e96d787fefd338055d066;hb=HEAD#l6463

Ouch... these codecs should not have been used outside
Python. I wonder why these applications don't use repr(text)
to format the JavaScript/SQL strings.

I guess this is the result of documenting them in
http://docs.python.org/library/codecs.html#standard-encodings

Too bad that the docs actually say "Produce a string that is
suitable as Unicode literal in Python source code." The codecs
main intent was to *decode* Unicode literals in Python source
code to Unicode objects...

The naming in the examples you mention also suggest that the
programmers used the table from the docs - they use
"unicode_escape" as codec name, not the standard
"unicode-escape" name which we use throughout the Python
code.

The fact that the demonstrated actual use already does apply the
extra quote escaping suggests that we cannot easily add this
to the existing codecs. It would break those applications, since
they'd be applying double-escaping.

> This does not prevent the creation of a new codec, let's call it 'python-unicode-escape' [ or 'repr' :-) ]

I think that's a good idea to move forward.

Python 3.x comes with a new Unicode repr() format which we could
turn into a new codec: it automatically adds the quotes, processes
the in-string quotes and backslashes and also escapes \t, \n and \r
as well as all non-printable code points.

As for naming the new codec, I'd suggest "unicode-repr" since
that's what it implements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7615>
_______________________________________

From report at bugs.python.org  Tue Jan 26 12:53:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 11:53:02 +0000
Subject: [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: <1264506782.6.0.531456479806.issue7784@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Steve, thank you for your patch.

IMHO, it's better to provide a patch against trunk (Py2) when the optimization is not specific to 3.x.

I merged it manually on my working copy, and all tests pass without leaking. Patch for Py2 attached.

However, I am not an expert. I just cleaned the tab/space mix to conform with what is used in the listobject.c file.

----------
keywords: +patch
nosy: +flox
stage:  -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file16009/issue7784_listobject_perf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Tue Jan 26 12:58:26 2010
From: report at bugs.python.org (showell)
Date: Tue, 26 Jan 2010 11:58:26 +0000
Subject: [issue7784] patch for making list/insert at the top of the list avoid
	memmoves
In-Reply-To: <1264506782.6.0.531456479806.issue7784@psf.upfronthosting.co.za>
Message-ID: <214087.27799.qm@web33506.mail.mud.yahoo.com>


showell <showell30 at yahoo.com> added the comment:

--- On Tue, 1/26/10, Florent Xicluna <report at bugs.python.org> wrote:

> From: Florent Xicluna <report at bugs.python.org>
> Subject: [issue7784] patch for making list/insert at the top of the list avoid memmoves
> To: showell30 at yahoo.com
> Date: Tuesday, January 26, 2010, 3:53 AM
> 
> Florent Xicluna <laxyf at yahoo.fr>
> added the comment:
> 
> Steve, thank you for your patch.
> 
> IMHO, it's better to provide a patch against trunk (Py2)
> when the optimization is not specific to 3.x.
> 
> I merged it manually on my working copy, and all tests pass
> without leaking. Patch for Py2 attached.
> 
> However, I am not an expert. I just cleaned the tab/space
> mix to conform with what is used in the listobject.c file.
> 

Thank you!  My only rationale for applying the patch to 3.x was that it would minimize backward compatibility concerns, but I do not have a strong opinion either way.

You probably noticed a few stylistic mistakes, such as these lines:

            a->orphans += (-1 * d);
            a->ob_item += (-1 * d);

All feedback on ways to improve this code would be greatly welcome.

Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Tue Jan 26 13:04:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 12:04:13 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264507453.58.0.10716074632.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Great idea, Marc-Andre. I agree that's the better approach.

It looks like PyStructSequence supports this, by setting n_in_sequence to a value smaller then the number of PyStructSequence_Fields. A quick look doesn't show any uses of this in the C code (except maybe os.stat), but I'll investigate and make sure that's a supported use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Tue Jan 26 13:04:29 2010
From: report at bugs.python.org (Jim Fulton)
Date: Tue, 26 Jan 2010 12:04:29 +0000
Subject: [issue7372] Regression in pstats
In-Reply-To: <1264466154.89.0.121708601728.issue7372@psf.upfronthosting.co.za>
Message-ID: <1099b90b1001260404u704edcfew61439d6db7c74cec@mail.gmail.com>


Jim Fulton <jim at zope.com> added the comment:

On Mon, Jan 25, 2010 at 7:35 PM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> See also #7372.
>
> AFAIU add_callers can receive either a tuple or an int (and this is what is not working now). When I looked at #7372 I wasn't able to find out why it might receive two different objects and not always the same (i.e. always a tuple, possibly with only one int). From the first message it seems that cProfile returns the tuple of 4 ints and profile returns a single int.
> Can profile be fixed to return a tuple (of 4 or 1 ints) too?

Ah interesting.  I ran into this recently when I noticed that some
analysis tools I'd written a while back no longer worked and had to be
updated because data that were ints were now tuples.

Aside from these particular issues, it would be really great if the
profiler stats data structure was specified. :)

Jim

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7372>
_______________________________________

From report at bugs.python.org  Tue Jan 26 13:40:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Jan 2010 12:40:19 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264507453.58.0.10716074632.issue7766@psf.upfronthosting.co.za>
Message-ID: <4B5EE2A9.1030100@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Eric Smith wrote:
> 
> Eric Smith <eric at trueblade.com> added the comment:
> 
> Great idea, Marc-Andre. I agree that's the better approach.
> 
> It looks like PyStructSequence supports this, by setting n_in_sequence to a value smaller then the number of PyStructSequence_Fields. A quick look doesn't show any uses of this in the C code (except maybe os.stat), but I'll investigate and make sure that's a supported use case.

If not, I'd suggest to move the code to Python, e.g. add a
class to the new sysinfo.py module, and then instantiate it via a C
call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Tue Jan 26 14:10:13 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 26 Jan 2010 13:10:13 +0000
Subject: [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 14:19:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 13:19:25 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264511965.4.0.544190264189.issue7564@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch to skip the test with the appropriate warning in verbose mode.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file16010/issue7564_test_ioctl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Tue Jan 26 14:27:20 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Tue, 26 Jan 2010 13:27:20 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1264512440.48.0.276735632725.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

Ok, here's the new patch. I've removed the #ifdef-#endif lines. It passed the test thread_test.py on linux (and as well on solaris).

----------
Added file: http://bugs.python.org/file16011/patch_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Tue Jan 26 14:53:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jan 2010 13:53:16 +0000
Subject: [issue7785] FileIO.write() accepts Unicode strings
In-Reply-To: <1264511412.59.0.542411267876.issue7785@psf.upfronthosting.co.za>
Message-ID: <1264513996.71.0.256914616322.issue7785@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7785>
_______________________________________

From report at bugs.python.org  Tue Jan 26 14:54:14 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 13:54:14 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264514054.67.0.768647750463.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's a patch that implement's Marc-Andre's suggestion. The docstring and documentation need work. I still need to verify that this isn't a misuse of PyStructSequence, but the tests pass on Windows. I need to verify a few other platforms to make sure the #ifdef logic is correct.

----------
Added file: http://bugs.python.org/file16012/winver_as_structseq_ex2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Tue Jan 26 15:06:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 14:06:13 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264514773.7.0.29653021526.issue7564@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16010/issue7564_test_ioctl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Tue Jan 26 15:09:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 14:09:10 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264514950.56.0.977360886101.issue7564@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch to make the "skip" message visible in normal mode:

test_ioctl
test_ioctl skipped -- Process group 1844 is associated with /dev/tty


And in the summary you have the information:

1 test skipped:
    test_ioctl
1 skip unexpected on linux2:
    test_ioctl

----------
Added file: http://bugs.python.org/file16013/issue7564_test_ioctl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Tue Jan 26 15:43:15 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 14:43:15 +0000
Subject: [issue7785] FileIO.write() accepts Unicode strings
In-Reply-To: <1264511412.59.0.542411267876.issue7785@psf.upfronthosting.co.za>
Message-ID: <1264516995.88.0.858864177546.issue7785@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7785>
_______________________________________

From report at bugs.python.org  Tue Jan 26 15:53:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Jan 2010 14:53:37 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264517617.3.0.492782591979.issue7766@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks a lot for taking a look at this, Eric and Marc-Andre. Apologies for the few mistakes in there, I jumped the gun and submitted that last patch before having run the full test suite again.

Good catch on the missing #ifdef. I will also run this on Mac and Linux today and make sure nothing slips by, but it looks to be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Tue Jan 26 16:01:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 15:01:19 +0000
Subject: [issue7782] new test for test_iter.py
In-Reply-To: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>
Message-ID: <1264518079.85.0.121204254342.issue7782@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>From the comment ("This test would break on an incomplete patch to listobject.c") is not clear what exactly the test is supposed to check.
Probably the test should include some assert* or more comments if it is supposed to work but it might raise an error if there's something wrong.
Finally it would be better if you can provide a patch against trunk and attach it to the issue.

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7782>
_______________________________________

From report at bugs.python.org  Tue Jan 26 16:36:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jan 2010 15:36:45 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264520205.51.0.598584917048.issue7564@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Could the skip message be made a little more explanatory?  I have no idea why "Process group 1844 is associated with /dev/tty" would mean that test_ioctl would need to be skipped.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Tue Jan 26 16:59:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 15:59:35 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264521575.64.0.0839686620286.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

json is now fixed in r77755.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Tue Jan 26 17:17:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jan 2010 16:17:22 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1264522642.46.0.460523190788.issue7325@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

First of all, thanks for working on this.  Now for some feedback :)

It is most helpful if you provide patches against trunk (which is 2.7 alpha right now).  We then forward port them to py3k.  (This will change after the release of 2.7, when py3k will become trunk.)

Isn't the assert you added to nameCheck redundant?  It seems to me it would be better just to remove the abspath call on ndir from the existing assert.

I haven't applied and tested the patch, but the other changes to the tests look odd to me.  Why are you obtaining the abspath of the current directory?  And why do those tests need to be changed at all?

Your additional test case looks like it might be some exploration code you forgot to delete before generating the patch, maybe those other changes are as well?

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Tue Jan 26 18:34:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 17:34:28 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1264527268.97.0.164798673353.issue1559298@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

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: [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:26:07 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 18:26:07 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264530367.06.0.582747430502.issue7564@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16013/issue7564_test_ioctl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

From report at bugs.python.org  Tue Jan 26 19:27:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 18:27:26 +0000
Subject: [issue7564] test_ioctl may fail when run in background
In-Reply-To: <1261525155.67.0.425847513735.issue7564@psf.upfronthosting.co.za>
Message-ID: <1264530446.3.0.329159517002.issue7564@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

A little more explanatory.

----------
Added file: http://bugs.python.org/file16014/issue7564_test_ioctl_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7564>
_______________________________________

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: [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:41:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jan 2010 18:41:30 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264531290.11.0.954773555913.issue7633@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

If none of you is working on it right now, I'll produce a new patch.
Mark, how about this:

     def __add__(self, other, context=None, raiseit=False):
        """Returns self + other.

        -INF + INF (or the reverse) cause InvalidOperation errors.
        """
        other = _convert_other(other, raiseit)
        if other is NotImplemented:
            return other


Then the context functions could look cleaner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Tue Jan 26 19:44:58 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Tue, 26 Jan 2010 18:44:58 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264531498.86.0.335338979724.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gmail.com> added the comment:

I've been working in the modified version of my last patch to solve the 6 mentioned points. I'm posting it in less than 24 hs.

If you're not hurry, please wait for me. This is just my second patch and is very useful to learn how to contribute to Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Tue Jan 26 19:46:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 18:46:18 +0000
Subject: [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: <1264531578.94.0.0959386813699.issue7787@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
priority:  -> normal

_______________________________________
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: [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 19:52:53 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jan 2010 18:52:53 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264531973.75.0.343068294964.issue7633@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Juan: Sure, take your time. :) I just wanted to know if you were still busy with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Tue Jan 26 19:53:26 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 26 Jan 2010 18:53:26 +0000
Subject: [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: <1264532006.89.0.648431848094.issue7788@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

** Erratum **
-- was:
del list_instance([start : stop : very_big_step]) causes segfaults...
-- should be:
del list_instance[start : stop : very_big_step]
causes segfaults...

** Post scriptum **
In each example only the last statement causes segmentation fault (previous are OK, and I attached them on purpose -- to show exemplary boundary values when things start going wrong).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 19:58:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 18:58:19 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264532299.33.0.0208957910369.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Juan, don't worry about the documentation if you don't want to.  I can fix that up easily.  (Of course, if you do want to, go ahead!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:01:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 19:01:17 +0000
Subject: [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: <1264532477.26.0.951579314954.issue7788@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is what I get on trunk:
Python 2.7a2+ (trunk:77754:77755, Jan 26 2010, 20:16:49)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import maxint
>>> del range(10)[::maxint]
>>> del range(10)[:-9:maxint]
>>> del range(10)[-8:8:maxint-2]
>>> del range(10)[9::maxint]
Segmentation fault

Confirmed on py3k too.

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -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:02:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 19:02:32 +0000
Subject: [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: <1264532552.68.0.790065951902.issue7788@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:04:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 19:04:20 +0000
Subject: [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: <1264532660.22.0.516504272494.issue7788@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:05:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 19:05:12 +0000
Subject: [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: <1264532712.06.0.673911691004.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raising priority:  it shouldn't be possible to crash Python this easily.

Ezio, are you on a 64-bit or 32-bit system?

----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:08:41 2010
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 26 Jan 2010 19:08:41 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264532921.93.0.229985082113.issue7633@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Juanjo, ping me in private if you want help with the doc toolchain, I can show you how to touch the .rst and see the changes after processing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:12:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jan 2010 19:12:28 +0000
Subject: [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: <1264533148.7.0.401292497861.issue7788@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

32bit, with sys.maxint/maxsize == 2147483647.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:16:09 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 26 Jan 2010 19:16:09 +0000
Subject: [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: <1264533369.68.0.205193315735.issue7788@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

Interesting that in Py2.5...

>>> del range(10)[::maxint]

...this causes segfault but in Py2.6 is ok, as well as in Py3.0 (with maxsize insetad of maxint). (That's why I didn't noticed that it concerns newer version than 2.5, and marked only 2.5).

But, as Ezio noted, e.g.:

>>> del range(10)[5::maxint]

...crashes all of them, e.g:

Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
[GCC 4.3.3] on linux2
>>> from sys import maxsize
>>> del list(range(10))[::maxsize]  # <- OK
>>> del list(range(10))[5::maxsize]
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:17:08 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 19:17:08 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264533428.04.0.400503079559.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I can confirm the most recent patch (ex2) doesn't break anything on MacOS or Linux.

It's clear that structseq.c is designed to be used this way, with more named members than unnamed members (and vice-versa, actually). See n_members vs. n_in_sequence in Objects/structseq.c.

I'll work on the docstring and documentation then I'll commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:17:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jan 2010 19:17:17 +0000
Subject: [issue7786] Is the BlockingIOError exception an aborted idea?
In-Reply-To: <1264527754.53.0.887033359111.issue7786@psf.upfronthosting.co.za>
Message-ID: <1264533437.62.0.464639343981.issue7786@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7786>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:21:58 2010
From: report at bugs.python.org (JordanS)
Date: Tue, 26 Jan 2010 19:21:58 +0000
Subject: [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 20:22:08 2010
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 26 Jan 2010 19:22:08 +0000
Subject: [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: <1264533728.23.0.0997334712247.issue7788@psf.upfronthosting.co.za>


Jan Kaliszewski <zuo at chopin.edu.pl> added the comment:

PS. Is such a data-dependant segfault considered as security problem? (if it is, maybe Python2.5 shuld be kept in "Versions" list)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:24:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Jan 2010 19:24:04 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264533844.14.0.321100053832.issue7789@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib) -2to3 (2.x to 3.0 conversion tool)
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:29:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 19:29:18 +0000
Subject: [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: <1264534158.64.0.691437572095.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I don't immediately see why it would be considered a security issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:37:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 19:37:12 +0000
Subject: [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: <1264534632.07.0.814506372823.issue7788@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

For the record:

>>> del bytearray('%%%')[1::1<<333]
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:42:05 2010
From: report at bugs.python.org (JordanS)
Date: Tue, 26 Jan 2010 19:42:05 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264534925.31.0.234489142985.issue7789@psf.upfronthosting.co.za>


JordanS <jps126 at mun.ca> added the comment:

sorry, first time posting anything like this: 
versions:

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:44:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 19:44:02 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264535042.42.0.510477729074.issue7789@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

datetime.datetime passes its format string to strftime:

>>> import datetime
>>> x = datetime.datetime(2001, 1, 2, 3, 4)
>>> x.strftime('%Y-%m-%d')
'2001-01-02'
>>> '{0:%Y-%m-%d}'.format(x)
'2001-01-02'

I'll check to make sure this is documented.

----------
assignee:  -> eric.smith
components: +Documentation -Library (Lib)
nosy: +eric.smith
stage: test needed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:51:29 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 19:51:29 +0000
Subject: [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: <1264535489.06.0.538890408253.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a suspicious looking test in list_ass_subscript in Objects/listobject.c:

if (cur + step >= Py_SIZE(self)) {
	lim = Py_SIZE(self) - cur - 1;
}

I think what's happening here is that cur + step is overflowing, so that the test fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:52:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jan 2010 19:52:25 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264535545.04.0.622281770679.issue7789@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If it is, it isn't any place obvious.  I thought I remembered something about using strftime strings in format, but when I looked in the docs for datetime and the section on the format mini language I couldn't find it, so I ended up doing '{} ...'.format(x.strftime("...") in my code...

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:55:29 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 26 Jan 2010 19:55:29 +0000
Subject: [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: <1264535729.62.0.140493535448.issue7788@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

I think the expression "cur + step" in line 2660 of listobject.c (py2.7 trunk) overflows to negative value and the "if" branch isn't entered.

  if (cur + step >= Py_SIZE(self)) {
    lim = Py_SIZE(self) - cur - 1;
   }

If I change the type of "cur" variable to unsigned int, the bug disappears. I don't know if it's ok to have unsigned "cur" here though - but I feel it is.

----------
keywords: +patch
nosy: +marcin.bachry
Added file: http://bugs.python.org/file16015/maybe-a-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 20:57:10 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 19:57:10 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264535830.27.0.61987362571.issue7789@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't think this is documented (that I can find, at least), so I'll assign it to Georg.

I think the correct thing to do is something like this, in the datetime, date, and time object descriptions:

date.__format__(fmt)
    For a date d, format(d, fmt) is equivalent to d.strftime(fmt).

Ditto for date.__format__. But maybe there's a better, more obvious place to document this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:04:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 20:04:19 +0000
Subject: [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: <1264536259.9.0.516381961776.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  Yes, that fix seems to work.  I also tried rewriting the suspect test as

if (step >= Py_SIZE(self) - cur)

but this produced a different failure:  it looks like there's more than one point with potential overflow for cur.  Not to mention that the 'cur += step' in the for loop can produce undefined behaviour.

So making cur unsigned looks like the right solution here.

It would be good to review the rest of this function for similar problems while we're fixing this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:05:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 20:05:19 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264536318.96.0.851978837291.issue7789@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The documentation for this belongs in the mini-language specification, since that just address built-in types. Each type can define its own format specification language.

So I think adding documentation of __format__ to each non-builtin type that implements __format__ is probably the best way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:06:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 20:06:28 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264536318.96.0.851978837291.issue7789@psf.upfronthosting.co.za>
Message-ID: <4B5F4B3B.4010003@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

Eric Smith wrote:
> The documentation for this belongs in the mini-language specification, ...

Oops. "does NOT belong in the mini-language specification".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:07:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 20:07:45 +0000
Subject: [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: <1264536465.88.0.562223912341.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And judging by flox's result for bytearray, we should check all the other sequence types, too.

----------
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:10:23 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 26 Jan 2010 20:10:23 +0000
Subject: [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: <1264536623.72.0.378042269316.issue7788@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Using "grep" I found the same code in Modules/arraymodule.c:

  from array import array
  del array('i', range(10))[9::1<<333]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:15:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 20:15:23 +0000
Subject: [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: <1264536923.57.0.976328103654.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice!  Marcin, are you interested in contributing a patch that fixes the three known cases (bytearray, list, array), and also adds suitable tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:22:45 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 26 Jan 2010 20:22:45 +0000
Subject: [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: <1264537365.61.0.941210970104.issue7788@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

Yes, I can give a shot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:25:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 20:25:17 +0000
Subject: [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: <1264537517.93.0.363162004783.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Great---thank you!  I'll review the patch when it's ready.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:32:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 26 Jan 2010 20:32:10 +0000
Subject: [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: <1264537930.95.0.163112159307.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Raising priority again.  I'm not sure when 3.1.2 is going out, but I'd like to make sure that this issue at least gets considered before it does.

----------
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:34:25 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 20:34:25 +0000
Subject: [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: <1264538065.77.0.507144237744.issue7787@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The check argument is any function which receives an open file and return a boolean.

For example:
 - verify the version number on the first line (test_normalization)
 - calculate the MD5

----------
keywords: +patch
nosy: +r.david.murray
stage:  -> patch review
Added file: http://bugs.python.org/file16016/issue7787_urlresource.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7787>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:36:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 20:36:53 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1264538213.4.0.343536690985.issue7783@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16007/issue7783_normalization.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:37:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 20:37:42 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1264538262.3.0.212426283506.issue7783@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Now the fix depends on #7787

----------
dependencies: +Add an argument to test_support.open_urlresource to invalidate the cache
stage:  -> patch review
Added file: http://bugs.python.org/file16017/issue7787_urlresource.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:38:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 20:38:08 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1264538288.75.0.302028016491.issue7783@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16017/issue7787_urlresource.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

From report at bugs.python.org  Tue Jan 26 21:38:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 26 Jan 2010 20:38:27 +0000
Subject: [issue7783] test_normalization fails when NormalizationTest.txt is
	outdated
In-Reply-To: <1264494095.66.0.402939893086.issue7783@psf.upfronthosting.co.za>
Message-ID: <1264538307.91.0.849574383325.issue7783@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16018/issue7783_normalization_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7783>
_______________________________________

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: [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 21:50:46 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Tue, 26 Jan 2010 20:50:46 +0000
Subject: [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: <1264539046.27.0.796426728686.issue7788@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

I attach the patch. I changed signedness in all three sequence types and made sure tests crash when run on unpatched Python.

----------
Added file: http://bugs.python.org/file16019/fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Tue Jan 26 22:11:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Jan 2010 21:11:22 +0000
Subject: [issue4770] binascii module,
	inconsistent behavior: some functions accept unicode string input
In-Reply-To: <1230573653.7.0.91596129114.issue4770@psf.upfronthosting.co.za>
Message-ID: <1264540282.42.0.281701894711.issue4770@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Please also add a NEWS entry which mentions the changes to those APIs and the change in the email package.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4770>
_______________________________________

From report at bugs.python.org  Tue Jan 26 22:11:57 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 26 Jan 2010 21:11:57 +0000
Subject: [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: <1264540317.89.0.7812739037.issue7784@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Tue Jan 26 22:27:21 2010
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 26 Jan 2010 21:27:21 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1264541241.81.0.608440642488.issue6963@psf.upfronthosting.co.za>


Charles Cazabon <charlesc-python at pyropus.ca> added the comment:

Thanks, Jesse -- it looks good.  If there are bugs remaining in the patch, they're mine and not yours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Tue Jan 26 22:52:47 2010
From: report at bugs.python.org (showell)
Date: Tue, 26 Jan 2010 21:52:47 +0000
Subject: [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: <1264542767.56.0.751596363639.issue7784@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

The next stage for the patch is that I need to switch from using orphans count to using ob_allocated pointer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

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: [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:07:31 2010
From: report at bugs.python.org (dholth)
Date: Tue, 26 Jan 2010 22:07:31 +0000
Subject: [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: <1264543651.54.0.362322661425.issue7791@psf.upfronthosting.co.za>


dholth <dholth at fastmail.fm> added the comment:

Also ipaddr.BaseIP.packed is a property, not a method, so no ()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7791>
_______________________________________

From report at bugs.python.org  Tue Jan 26 23:09:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Jan 2010 22:09:38 +0000
Subject: [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: <1264543778.81.0.395376163312.issue7791@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

unittest also does this, but it does so at the top and references projects as a whole, rather than individual functions/classes in the project.

Seems like this should be taken out. It doesn't exist in any version after 2.6.

----------
nosy: +brian.curtin
priority:  -> low
stage:  -> needs patch
type:  -> behavior

_______________________________________
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: [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 00:15:06 2010
From: report at bugs.python.org (Ross Cohen)
Date: Tue, 26 Jan 2010 23:15:06 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264152753.17.0.656147876949.issue7753@psf.upfronthosting.co.za>
Message-ID: <20100126151155.5cda9e74@neeble>


Ross Cohen <rcohen at snurgle.org> added the comment:

On Fri, 22 Jan 2010 09:32:36 +0000
Marc-Andre Lemburg <report at bugs.python.org> wrote:

>  * Please add the fallback solutions from the time module in case gettimeofday() is not available. You cannot assume that "all modern POSIX systems" implement that API - it was introduced in POSIX 2001 and Python 2.x still supports OSes that were released prior to that year.

POSIX as a standard tends to follow, not lead. The gettimeofday() call
dates back over 20 years in BSD. time.time() falls back on ftime() and
then time(). ftime() was added to the POSIX spec at the same time as
gettimeofday() and is now deprecated. time() probably doesn't have
enough resolution.

I'd have to be pointed to a specific platform which doesn't support
gettimeofday() but which is supported by python. Otherwise, I'd be
coding blind.

Ross

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 00:27:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 26 Jan 2010 23:27:09 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264548429.29.0.093726702825.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's the final version of the patch. After some testing on various platforms I'll commit it.

----------
Added file: http://bugs.python.org/file16020/winver_as_structseq_ex4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Wed Jan 27 00:34:09 2010
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 26 Jan 2010 23:34:09 +0000
Subject: [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: <1264548849.31.0.191250184886.issue7784@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

$ ./python -m timeit -s 'from collections import deque; c = deque(range(1000000))' 'c.append(c.popleft())'
1000000 loops, best of 3: 0.29 usec per loop

$ ./python -m timeit -s 'c = range(1000000)' 'c.append(c.pop(0))'
1000000 loops, best of 3: 0.424 usec per loop

Using flox's issue7784_listobject_perf.diff.  Significantly slower, but it does scale linearly.


$ ./python -m timeit -s 'c = range(1000000)' 'c.insert(0, c.pop())'
100 loops, best of 3: 3.39 msec per loop

Unfortunately inserting does not.  Will future patches attempt to address this?

Note that, if it ends up slower than list and slower than deque there isn't really a use case for it.

----------
nosy: +Rhamphoryncus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Wed Jan 27 01:01:46 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jan 2010 00:01:46 +0000
Subject: [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: <1264550506.6.0.635883258471.issue7784@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Please take care in presenting timings.  It is easy to get misleading results:

* Factor-out the attribute lookup time (since that isn't the part being changed:

  -s 'c = range(1000000); c_ins=c.insert; c_pop=c.pop' 
  'c_insert(0, c_pop())'

* The case of alternately prepending and the popping the 0th element is atypical.  Trying prepending many, then popping many.   Trying popping first, then prepending.

* The patch needs to be throughly exercised so that we cover all of the expected behaviors (do many prepends trigger memmoves, do many prepops leave tons of unused space, what happens with the normal case of a moving queue where the average size varies but hovers around a typical mean).

A decision cannot be based on exercising a small fragment of a data structure on just the things it is good at.  What happens to other typical list behavior and lookup times, etc?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Wed Jan 27 01:15:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 27 Jan 2010 00:15:38 +0000
Subject: [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 01:16:47 2010
From: report at bugs.python.org (Ross Cohen)
Date: Wed, 27 Jan 2010 00:16:47 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264270988.68.0.841510050993.issue7753@psf.upfronthosting.co.za>
Message-ID: <20100126161336.0b5af0a6@neeble>


Ross Cohen <rcohen at snurgle.org> added the comment:

On Sat, 23 Jan 2010 18:23:10 +0000
Antoine Pitrou <report at bugs.python.org> wrote:

> By the way, the new GIL only works with POSIX and Windows NT threading APIs. Perhaps it can't be backported at all to 2.x, given that 2.x supports more threading APIs than py3k does?

Looking at the Python/thread_*.h files, it looks like py3k still
supports 9 different threading models. If that's accurate, it means
py3k trunk is broken on platforms which use cthread, lwp, os2, pth,
sgi, solaris and wince threading models. The 2.x series adds atheos and
beos to that list.

I think the right way to fix this is to extend the thread_*.h files to
have a proper abstraction for conditions which can be used by the
newgil work. Then the maintainers for more obscure platforms can fix
those instead of it all turning into a big mess in ceval_gil.h.

Ross

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 01:38:47 2010
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 27 Jan 2010 00:38:47 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1264552727.16.0.225292370736.issue1205239@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Thanks, good points. I'm thinking with a C background and the fixed-width data types. The 0xFF could be needed if the data_byte is actually a larger number and you need to ensure only the lowest 8 bits are set. Or, if there is some sign-extending going on with the right-shift. That could happen in Python if the user passed a negative 'crc' in to the function (for whatever reason).

Yes, I'm missing a final mask. Thanks for pointing that out. I was thinking like a C programmer!

As for crc << 8 >> crc_width... the 'crc << 8' could bump an integer into long territory, making calculations slower. E.g.:

    >>> 2**23 << 8 >> 16
    32768L

    >>> 2**23 >> (16 - 8)
    32768

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205239>
_______________________________________

From report at bugs.python.org  Wed Jan 27 01:46:33 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 27 Jan 2010 00:46:33 +0000
Subject: [issue7766] sys.getwindowsversion as PyStructSequence
In-Reply-To: <1264276632.05.0.210165677499.issue7766@psf.upfronthosting.co.za>
Message-ID: <1264553193.62.0.700695133726.issue7766@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Committed in trunk r77763, in py3k r77765.

----------
assignee:  -> eric.smith
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7766>
_______________________________________

From report at bugs.python.org  Wed Jan 27 01:50:09 2010
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 27 Jan 2010 00:50:09 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1264553409.74.0.263939612934.issue1205239@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

To complete that thought...

Since crc << 8 could bump the calculation into long territory, for that final mask I guess I'd want to mask and then shift. I.e. rather than

    crc_mask = ((1 << crc_width) - 1)
    crc = (...) ^ ((crc << 8) & crc_mask)

do:

    crc_lower_mask = ((1 << (crc_width - 8)) - 1)
    crc = (...) ^ ((crc & crc_lower_mask) << 8)

But that expression should evaluate to 0 if crc_width <= 8, so I guess I'll need to special-case it. And if I special-case it, I don't need to shift by a negative value after all!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205239>
_______________________________________

From report at bugs.python.org  Wed Jan 27 02:05:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 27 Jan 2010 01:05:27 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1264554327.53.0.388682796899.issue7789@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee: eric.smith -> georg.brandl
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7789>
_______________________________________

From report at bugs.python.org  Wed Jan 27 02:10:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jan 2010 01:10:48 +0000
Subject: [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: <1264554648.08.0.97703342126.issue7793@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7793>
_______________________________________

From report at bugs.python.org  Wed Jan 27 02:32:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 27 Jan 2010 01:32:43 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1264555963.42.0.621758989221.issue7030@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

skip* functions are missing 'new in' documentation. These need to be correct for 2.7 and 3.1 / 3.2 as well.

Plus the example of assertRaises as a context manager sucks.

http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertRaises

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7030>
_______________________________________

From report at bugs.python.org  Wed Jan 27 02:47:29 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 Jan 2010 01:47:29 +0000
Subject: [issue7785] FileIO.write() accepts Unicode strings
In-Reply-To: <1264511412.59.0.542411267876.issue7785@psf.upfronthosting.co.za>
Message-ID: <1264556849.46.0.948333758106.issue7785@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Oops. Fixed in r77781.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7785>
_______________________________________

From report at bugs.python.org  Wed Jan 27 02:49:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 Jan 2010 01:49:37 +0000
Subject: [issue7786] Is the BlockingIOError exception an aborted idea?
In-Reply-To: <1264527754.53.0.887033359111.issue7786@psf.upfronthosting.co.za>
Message-ID: <1264556977.01.0.116845470484.issue7786@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The BufferedReader/Writer classes are supposed to handle this exception correctly, so presumably you could have RawIO class that raises this exceptions and use it with the io stack.

Since this bug report has no clear resolution, I'm closing it. Further discussion should happen on Python-dev I believe.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7786>
_______________________________________

From report at bugs.python.org  Wed Jan 27 03:18:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 27 Jan 2010 02:18:20 +0000
Subject: [issue7792] Errors registering non-classes with ABCs
In-Reply-To: <1264546410.38.0.169010295944.issue7792@psf.upfronthosting.co.za>
Message-ID: <1264558700.33.0.797882226873.issue7792@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed first bug in r77789. The second issue is a separate feature request.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7792>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:06:59 2010
From: report at bugs.python.org (Cameron Simpson)
Date: Wed, 27 Jan 2010 03:06:59 +0000
Subject: [issue7776] httplib.py: ._tunnel() broken
In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za>
Message-ID: <1264561619.83.0.843273376884.issue7776@psf.upfronthosting.co.za>


Cameron Simpson <cs at zip.com.au> added the comment:

Well, following your description I've backed out my urllib2 test case to this:

  f = urllib2.urlopen('https://localhost/boguspath')
  os.system("lsof -p %d | grep IPv4" % (os.getpid(),))
  f = urllib2.urlopen(R)
  print f.read()

and it happily runs HTTPS through the proxy if I set the https_proxy envvar. So it's all well and good for the "just do what the environment suggests" use case.

However, my older test:

  U = urllib2.Request('https://localhost/boguspath')
  U.set_proxy('localhost:3128', 'https')
  f = urllib2.urlopen(R)
  print f.read()

still blows up with:

  File "/opt/python-2.6.4/lib/python2.6/urllib2.py", line 381, in open
    protocol = req.get_type()
  AttributeError: HTTPResponse instance has no attribute 'get_type'

Now, this is the use case for "I have a custom proxy setup for this activity".

It seems a little dd that "req" above is an HTTPResponse instead of a Request, and that my be why there's no .ettype() method available.

I also see nothing obviously wrong with my set_proxy() call above based on the docs for the .set_proxy() method, though obviously it fails.

I think what may be needed is a small expansion of the section in the Examples are on proxies. There's an description of the use of the *_proxy envvars there (and not elsewhere, which seems wrong) and an example of providing a proxy Handler. An addition example with a functioning use of a bare .set_proxy() might help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7776>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:36:57 2010
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 27 Jan 2010 03:36:57 +0000
Subject: [issue6963] Add worker process lifetime to multiprocessing.Pool -
	patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1264563417.93.0.658885568694.issue6963@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Committed to trunk in r77794
Merged to Py3k in r77795

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:37:12 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 27 Jan 2010 03:37:12 +0000
Subject: [issue1752919] Exception in HTMLParser for special JavaScript code
Message-ID: <1264563432.14.0.634568342802.issue1752919@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

I agree, I do not feel like the precise changes to the tests feel completely ideal.  I feel that this problem stems from the fact that the nameCheck function as originally written doesn't seem to completely serve its originally intended purpose.

The original issue that caused the modifications of the tests were as follows:

* After adding "test_abs_path()" namecheck would pass the test when it should actually fail due to the original assert performing os.path.abspath() on both paths.  The obviously solution to this seemed to be to take the abspath of the user supplied path (the variable dir in this function) relative or otherwise and compare to ndir which is derived from the passed in "name" variable, populated by the mkdtemp call.

* The second issue is a somewhat complex case of those asserts passing the atypical odd calls of nameCheck from the "test__RandomNameSequence" suite.  Without absolute pathing of both parameters in the new first assert this test began to fail.  This is because the original call was self.namecheck(<file name>, '', '', '').  These empty parameters when called with os.path.abspath() would return valid paths and these asserts would succeed.  As a result, the abspath(join()) call built a proper path into the "name" parameter allowing the tests to pass in this case.

* For the sake of cleanliness I decided it made more sense to split the two apart.  Make one assert that specifically verifies the path the file/folder is being placed in is both absolute and matching and one that will pass the file name.  Perhaps the old first assert (or second assert in the patch) can actually be removed but I think it may be getting properly tested against in one of the other test classes.

I am quite confident there is a much better way to accomplish this but I did not wish to change _too_ much of the test on my first stab at this.

I appreciate your feedback very much.  I will work on setting up the 2.7 environment for working on issues that span the 2x/3x gap.

----------
nosy: +Thomas.Holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1752919>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:38:42 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 27 Jan 2010 03:38:42 +0000
Subject: [issue1752919] Exception in HTMLParser for special JavaScript code
Message-ID: <1264563522.34.0.107435368007.issue1752919@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

Please disregard, I commented on the wrong issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1752919>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:38:50 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 27 Jan 2010 03:38:50 +0000
Subject: [issue1752919] Exception in HTMLParser for special JavaScript code
Message-ID: <1264563530.18.0.483796876612.issue1752919@psf.upfronthosting.co.za>


Changes by Thomas Holmes <shadox at gmail.com>:


----------
nosy:  -Thomas.Holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1752919>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:39:18 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 27 Jan 2010 03:39:18 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1264563558.94.0.462329670656.issue7325@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

I agree, I do not feel like the precise changes to the tests feel completely ideal.  I feel that this problem stems from the fact that the nameCheck function as originally written doesn't seem to completely serve its originally intended purpose.

The original issue that caused the modifications of the tests were as follows:

* After adding "test_abs_path()" namecheck would pass the test when it should actually fail due to the original assert performing os.path.abspath() on both paths.  The obviously solution to this seemed to be to take the abspath of the user supplied path (the variable dir in this function) relative or otherwise and compare to ndir which is derived from the passed in "name" variable, populated by the mkdtemp call.

* The second issue is a somewhat complex case of those asserts passing the atypical odd calls of nameCheck from the "test__RandomNameSequence" suite.  Without absolute pathing of both parameters in the new first assert this test began to fail.  This is because the original call was self.namecheck(<file name>, '', '', '').  These empty parameters when called with os.path.abspath() would return valid paths and these asserts would succeed.  As a result, the abspath(join()) call built a proper path into the "name" parameter allowing the tests to pass in this case.

* For the sake of cleanliness I decided it made more sense to split the two apart.  Make one assert that specifically verifies the path the file/folder is being placed in is both absolute and matching and one that will pass the file name.  Perhaps the old first assert (or second assert in the patch) can actually be removed but I think it may be getting properly tested against in one of the other test classes.

I am quite confident there is a much better way to accomplish this but I did not wish to change _too_ much of the test on my first stab at this.

I appreciate your feedback very much.  I will work on setting up the 2.7 environment for working on issues that span the 2x/3x gap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Wed Jan 27 04:46:37 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 27 Jan 2010 03:46:37 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1264563997.86.0.747725004428.issue7325@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

One other thing that crossed my mind while I was thinking over this today.  Instead of just relative pathing to '.' I should probably change my path to gettempdir() and then relative path to it since the location of the python executable may not be writable.

Any thoughts on how to go about testing this in a way that is most likely to succeed in all cases and respect OS permissions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Wed Jan 27 05:31:13 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 27 Jan 2010 04:31:13 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1264566673.25.0.797987507369.issue3367@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I think this was fixed with checkins r76689 and r76230, made by Benjamin. Since we are using "exec ''" as the reproduction case, the token state is setup in 'PyTokenizer_FromString', which causes 'tok->inp == ""'.  The code before these checkins (see attached revert patch) caused the following else branch in 'tok_nextc' to be taken:
   char *end = strchr(tok->inp, '\n');
   if (end != NULL)
      end++;
   else {
      end = strchr(tok->inp, '\0');
      if (end == tok->inp) {
         tok->done = E_EOF;
	 return EOF;
      }
   }
   if (tok->start == NULL)
      tok->buf = tok->cur;
   tok->line_start = tok->cur;
   tok->lineno++;
   tok->inp = end;
   return Py_CHARMASK(*tok->cur++);
because under these circumstances 'tok->inp == ""'.  Thus 'tok->line_start' is not assigned. This trickled back out to 'parsetok:159' followed by 'parsetok:187' where 'tok->line_start' gets read unitialized.

After r76689 and r76230 the call to 'translate_newlines' was added in 
'decode_str' which is called from 'PyTokenizer_FromString' when the token state is created.  The 'translate_newlines' call adds a newline to the end of the input buffer which ends up causing 'tok->input == "\n"'.  Thus when 'tok_nextc' is called the initial if branch is taken instead of the else and 'tok->line_start' is initialized properly.

I also verified the current trunk with valgrind, which now shows no issue with this particular scenario:

euclid:trunk minge$ valgrind ./python.exe -c "exec ''"
==77940== Memcheck, a memory error detector
==77940== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==77940== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==77940== Command: ./python.exe -c exec\ ''
==77940== 
--77940-- ./python.exe:
--77940-- dSYM directory has wrong UUID; consider using --dsymutil=yes
==77940== Conditional jump or move depends on uninitialised value(s)
==77940==    at 0x29D99D: __setenv (in /usr/lib/libSystem.B.dylib)
==77940==    by 0x2E9354: putenv$UNIX2003 (in /usr/lib/libSystem.B.dylib)
==77940==    by 0x165217: posix_putenv (in ./python.exe)
==77940==    by 0x6E422: PyCFunction_Call (in ./python.exe)
==77940==    by 0x10E971: call_function (in ./python.exe)
==77940==    by 0x1095FE: PyEval_EvalFrameEx (in ./python.exe)
==77940==    by 0x10EE3B: fast_function (in ./python.exe)
==77940==    by 0x10EB47: call_function (in ./python.exe)
==77940==    by 0x1095FE: PyEval_EvalFrameEx (in ./python.exe)
==77940==    by 0x10C073: PyEval_EvalCodeEx (in ./python.exe)
==77940==    by 0x10EF3C: fast_function (in ./python.exe)
==77940==    by 0x10EB47: call_function (in ./python.exe)
==77940== 
[15652 refs]
==77940== 
==77940== HEAP SUMMARY:
==77940==     in use at exit: 590,354 bytes in 4,795 blocks
==77940==   total heap usage: 34,635 allocs, 29,840 frees, 6,689,168 bytes allocated
==77940== 
==77940== LEAK SUMMARY:
==77940==    definitely lost: 0 bytes in 0 blocks
==77940==    indirectly lost: 0 bytes in 0 blocks
==77940==      possibly lost: 451,997 bytes in 4,461 blocks
==77940==    still reachable: 137,793 bytes in 321 blocks
==77940==         suppressed: 564 bytes in 13 blocks
==77940== Rerun with --leak-check=full to see details of leaked memory
==77940== 
==77940== For counts of detected and suppressed errors, rerun with: -v
==77940== Use --track-origins=yes to see where uninitialised values come from
==77940== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

----------
nosy: +benjamin.peterson, minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Wed Jan 27 05:34:31 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 27 Jan 2010 04:34:31 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1264566871.04.0.462937430295.issue3367@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


Added file: http://bugs.python.org/file16021/revert-76139-76689.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Wed Jan 27 10:35:37 2010
From: report at bugs.python.org (Chris Withers)
Date: Wed, 27 Jan 2010 09:35:37 +0000
Subject: [issue7792] Errors registering non-classes with ABCs
In-Reply-To: <1264546410.38.0.169010295944.issue7792@psf.upfronthosting.co.za>
Message-ID: <1264584937.71.0.0438258761417.issue7792@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

...and for the second feature, Andrew may wish to look at zope.component, which provides for this already.

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7792>
_______________________________________

From report at bugs.python.org  Wed Jan 27 10:38:03 2010
From: report at bugs.python.org (Chris Withers)
Date: Wed, 27 Jan 2010 09:38:03 +0000
Subject: [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: <1264585083.94.0.944025862323.issue7793@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

Can you try and list what the cases are which cause this failure to occur?

----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7793>
_______________________________________

From report at bugs.python.org  Wed Jan 27 10:40:05 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 27 Jan 2010 09:40:05 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1264585205.1.0.517903705362.issue5673@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Wed Jan 27 10:46:31 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Jan 2010 09:46:31 +0000
Subject: [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: <1264585591.89.0.0747915415427.issue7793@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The module is probably reloaded, which causes code like:
    _ord = ord
    def ord(c):
        ... _ord(c) ...
to form a recursion loop.
Attached patch removes the need for a special ord().

All this should be simply removed in py3k branch: ord() and chr() do the right thing even on narrow unicode builds.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file16022/test_multibytecodec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7793>
_______________________________________

From report at bugs.python.org  Wed Jan 27 11:33:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 10:33:47 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <20100126151155.5cda9e74@neeble>
Message-ID: <4B60167F.5070009@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ross Cohen wrote:
> 
> Ross Cohen <rcohen at snurgle.org> added the comment:
> 
> On Fri, 22 Jan 2010 09:32:36 +0000
> Marc-Andre Lemburg <report at bugs.python.org> wrote:
> 
>>  * Please add the fallback solutions from the time module in case gettimeofday() is not available. You cannot assume that "all modern POSIX systems" implement that API - it was introduced in POSIX 2001 and Python 2.x still supports OSes that were released prior to that year.
> 
> POSIX as a standard tends to follow, not lead. The gettimeofday() call
> dates back over 20 years in BSD. time.time() falls back on ftime() and
> then time(). ftime() was added to the POSIX spec at the same time as
> gettimeofday() and is now deprecated. time() probably doesn't have
> enough resolution.
> 
> I'd have to be pointed to a specific platform which doesn't support
> gettimeofday() but which is supported by python. Otherwise, I'd be
> coding blind.

The point here is that we have traditionally been careful not
to break Python for platforms that don't support a certain API,
hence the different fallback solutions for getting the current
time.

gettimeofday() is indeed available on most OSes, but not all. VxWorks
is an example where it is not available and Python happily uses
alternatives.

http://www.gsalcazar.altervista.org/tools/how-to-port-python-to-vxworks/?PHPSESSID=u5do9v0lh2gqdqilmikv7nmsk1

There are also cases where gettimeofday() is buggy
(e.g. on Solaris: http://www.unix.com/sun-solaris/59187-bugs-clock.html or
Cygwin: http://old.nabble.com/About-The---GetMicroSecondTime-on-Windows---Post-td13721510.html)
or returns errors every now and then (I have observed that in mxDateTime
occasionally - it may be related to NTP doing its works).

For those situations is necessary to be able to enable a
fallback solution using other APIs.

I've also done some extra research yesterday and found that e.g.
Ruby is using gettimeofday() for thread scheduling as well. They
have observed issues with gettimeofday() causing problems due
to wallclock time not being a monotonic (e.g. due to NTP running
on the machine and the clock sometimes going backwards due to
corrections or DST changes).

http://groups.google.com/group/ruby-talk-google/browse_thread/thread/f8a616113e2eea8f

OTOH, using process timers is also not regarded as being ideal,
since on SMP systems, each CPU will have its own timer and they
are not necessarily in sync.

Other implementations tend to use the new clock_gettime() APIs
where available and then use the CLOCK_MONOTONIC timer, e.g.

http://stackoverflow.com/questions/88/is-gettimeofday-guaranteed-to-be-of-microsecond-resolution
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=272

Here's some example code which tries to cover even more platforms
than Python 2.x:

http://www.koders.com/c/fid5A75B2B62D4024A2431D060ADD5D378DB7A1D2BD.aspx

Another aspect to consider is update frequency of these APIs.
gettimeofday()'s resolution depends on various factors and
appears to vary between 1us and 100ms (on systems running using
a 100Hz clock).

http://answers.google.com/answers/threadview/id/203397.html
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=272
https://computing.llnl.gov/tutorials/performance_tools/#gettimeofday

clock_gettime() has similar resolution, but tends to be updated
more often:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1264587819627+28353475&threadId=1230881

And finally, using wallclock time for these things is expensive
as I've already mentioned:

http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/dc29071f2417f75f/c46264dba0863463?lnk=st&rnum=1#c46264dba0863463
http://www.developerweb.net/forum/archive/index.php/t-4368.html
http://h21007.www2.hp.com/portal/download/files/unprot/hpux/HowToTellTheTime.pdf
(as HTML:
http://209.85.129.132/search?q=cache%3AI1ihHYBMJvgJ%3Ah21007.www2.hp.com%2Fportal%2Fdownload%2Ffiles%2Funprot%2Fhpux%2FHowToTellTheTime.pdf+gettimeofday()+support+across+platforms&hl=en&gl=de)

It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
where available and only use gettimeofday() as fallback solution
together with times(), ftime() and time().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 11:37:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 10:37:45 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <20100126161336.0b5af0a6@neeble>
Message-ID: <4B601774.4090602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ross Cohen wrote:
>> By the way, the new GIL only works with POSIX and Windows NT threading APIs. Perhaps it can't be backported at all to 2.x, given that 2.x supports more threading APIs than py3k does?
> 
> Looking at the Python/thread_*.h files, it looks like py3k still
> supports 9 different threading models. If that's accurate, it means
> py3k trunk is broken on platforms which use cthread, lwp, os2, pth,
> sgi, solaris and wince threading models. The 2.x series adds atheos and
> beos to that list.
> 
> I think the right way to fix this is to extend the thread_*.h files to
> have a proper abstraction for conditions which can be used by the
> newgil work. Then the maintainers for more obscure platforms can fix
> those instead of it all turning into a big mess in ceval_gil.h.

I find it rather strange that Python 3.x now only supports
NT and POSIX threads in ceval while it still supports the
whole set of other thread implementations for the _thread
module.

Has this been discussed on python-dev ?

Why can't the code necessary to get the new GIL working be
added to Sjoerd's portable thread library ?

As it stands, I think this is a bummer for both Python 2.7 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 12:10:40 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Jan 2010 11:10:40 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1264590640.09.0.051521637439.issue1628484@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Marc-Andre,

on 64-bit Ubuntu, this method ...

BASECFLAGS=-m32 LDFLAGS=-m32 ./configure

... results in a gcc segfault:


gcc -pthread -m32 -Xlinker -export-dynamic -o python \
                        Modules/python.o \
                        libpython3.2.a -lpthread -ldl  -lutil   -lm  
Segmentation fault
make: *** [sharedmods] Error 139



Antoine's patch and command line work.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 12:30:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 11:30:04 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1264590640.09.0.051521637439.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4B6023B4.2000004@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> Marc-Andre,
> 
> on 64-bit Ubuntu, this method ...
> 
> BASECFLAGS=-m32 LDFLAGS=-m32 ./configure
> 
> ... results in a gcc segfault:
> 
> 
> gcc -pthread -m32 -Xlinker -export-dynamic -o python \
>                         Modules/python.o \
>                         libpython3.2.a -lpthread -ldl  -lutil   -lm  
> Segmentation fault
> make: *** [sharedmods] Error 139
> 
> 
> 
> Antoine's patch and command line work.

Just to get an idea of why the above fails, could you provide the
line from the build with Antoine's patch applied ?!

I starting to think that we should apply Antoine's patch for 2.7/3.2
and leave the CFLAGS cleanup to some other release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 12:46:13 2010
From: report at bugs.python.org (Mario Fasold)
Date: Wed, 27 Jan 2010 11:46:13 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1264592773.94.0.832687905786.issue1225769@psf.upfronthosting.co.za>


Mario Fasold <fasold at googlemail.com> added the comment:

Comment lines are a *very* common case in scientific and statistical data. +1 for the change.

----------
nosy: +Mario.Fasold

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

From report at bugs.python.org  Wed Jan 27 13:19:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Jan 2010 12:19:21 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1264594761.45.0.743158697812.issue1628484@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The builds are almost identical, so I attach a diff of the build output.
For both builds, I used a fresh Python-3.1.1 directory. This looks
suspicious:

-checking whether va_list is an array... yes
+checking whether va_list is an array... no


For completeness' sake: "-fno-strict-aliasing -m32" were reversed in the
BASECFLAGS case, so I edited the BASECFLAGS output for the purposes of
creating a diff.

----------
Added file: http://bugs.python.org/file16023/basecflags-vs-patch-3.1.1.builddiff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 13:23:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Jan 2010 12:23:16 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1264594996.6.0.169889574148.issue1628484@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file16023/basecflags-vs-patch-3.1.1-builddiff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 13:23:35 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Jan 2010 12:23:35 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1264595015.12.0.329508589835.issue1628484@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file16024/basecflags-vs-patch-3.1.1-builddiff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 13:36:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 12:36:05 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B601774.4090602@egenix.com>
Message-ID: <1264595835.3631.12.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 27 janvier 2010 ? 10:37 +0000, Marc-Andre Lemburg a ?crit :
> 
> I find it rather strange that Python 3.x now only supports
> NT and POSIX threads in ceval while it still supports the
> whole set of other thread implementations for the _thread
> module.
> 
> Has this been discussed on python-dev ?

Yes, it was. See
http://mail.python.org/pipermail/python-dev/2009-October/093276.html
All these thread_*.h files are still there, but most of them are
deprecated (see the #error's in thread.c). It's the consensus that came
out on the mailing-list.

The one exception is OS/2, which is "supported" as long as Andrew
McIntyre (or someone else, of course) takes care about it. It was
decided that OS/2 compatibility wasn't important enough to bar adding
new features or making improvements.

> Why can't the code necessary to get the new GIL working be
> added to Sjoerd's portable thread library ?

The condition variable "emulation" used by the new GIL under Windows is
not valid as a general condition variable mechanism; this is mentioned
in ceval_gil.h, and a link is given to a much more complicated (but
valid) condition variable emulation. Therefore, I think it could be
detrimental to expose it publicly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 13:46:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 12:46:42 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B60167F.5070009@egenix.com>
Message-ID: <1264596474.3631.13.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mercredi 27 janvier 2010 ? 10:33 +0000, Marc-Andre Lemburg a ?crit :
> 
> It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
> where available and only use gettimeofday() as fallback solution
> together with times(), ftime() and time().

Thanks for the research! I will take a look at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 13:54:44 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 12:54:44 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1264594761.45.0.743158697812.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4B60378F.3040602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> The builds are almost identical, so I attach a diff of the build output.
> For both builds, I used a fresh Python-3.1.1 directory. This looks
> suspicious:
> 
> -checking whether va_list is an array... yes
> +checking whether va_list is an array... no
> 
> 
> For completeness' sake: "-fno-strict-aliasing -m32" were reversed in the
> BASECFLAGS case, so I edited the BASECFLAGS output for the purposes of
> creating a diff.

Thanks.

Looking at the diff I cannot see any difference between the
two builds in terms of gcc options applied during the compile
and link step.

As you noticed, this leaves the va_list difference which also
causes the warnings in the 32-bit build.

I guess this points to the real cause of the problem: configure
doesn't know anything about BASECFLAGS, but does use CFLAGS for
checking various compiler features, so Antoines command line
options using CFLAGS work, while the ones I posted don't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 14:12:56 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Jan 2010 13:12:56 +0000
Subject: [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:17:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Jan 2010 13:17:05 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1264598225.6.0.646823439721.issue1225769@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Comment lines in csv data may be common in some areas, but they are not part of any standard, and they are not the only possible extension to csv files (for example: ignore empty lines, or a terminal \ for line continuation...)

Currently all members of Dialect deal with the format of the records, not with the extraction of records from the file. (lineterminator is used only when writing).

The "CommentedFile" filter above is a good recipe for all cases, and is easy to use. I recommend closing this issue.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

From report at bugs.python.org  Wed Jan 27 14:25:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jan 2010 13:25:55 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1264598755.32.0.991739281034.issue1225769@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Shouldn't the comment char definition belong in a dialect class? The reader would still have to be modified to skip these lines, but having this char in the dialect would not require a change to csv.reader signature.

Kind regards

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

From report at bugs.python.org  Wed Jan 27 14:28:18 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 13:28:18 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264595835.3631.12.camel@localhost>
Message-ID: <4B603F6A.4020408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Le mercredi 27 janvier 2010 ? 10:37 +0000, Marc-Andre Lemburg a ?crit :
>>
>> I find it rather strange that Python 3.x now only supports
>> NT and POSIX threads in ceval while it still supports the
>> whole set of other thread implementations for the _thread
>> module.
>>
>> Has this been discussed on python-dev ?
> 
> Yes, it was. See
> http://mail.python.org/pipermail/python-dev/2009-October/093276.html
> All these thread_*.h files are still there, but most of them are
> deprecated (see the #error's in thread.c). It's the consensus that came
> out on the mailing-list.
> 
> The one exception is OS/2, which is "supported" as long as Andrew
> McIntyre (or someone else, of course) takes care about it. It was
> decided that OS/2 compatibility wasn't important enough to bar adding
> new features or making improvements.

The arguments given in that thread sound a bit strange to me:
just because there were no changes to a few files, doesn't really
say anything about whether they contain working code or not.

In any case, the new GIL implementation as it stands makes
supporting any of those additional threading implementations
a moot case.

You could just as well remove them right now: if the GIL doesn't
work on OS/2, then having support for it in the _thread module
isn't really worth much, is it ?

Regardless, instead of now having two places where threading is
implemented, we should just have one: the portable thread library and
extend this as necessary.

>> Why can't the code necessary to get the new GIL working be
>> added to Sjoerd's portable thread library ?
> 
> The condition variable "emulation" used by the new GIL under Windows is
> not valid as a general condition variable mechanism; this is mentioned
> in ceval_gil.h, and a link is given to a much more complicated (but
> valid) condition variable emulation. Therefore, I think it could be
> detrimental to expose it publicly.

By moving all the thread support code to the thread library,
you don't really expose anything (the lib is only used internally
by Python), you just reorganize the code in a more natural and
easier to maintain way.

If you think that the win32 emulation shouldn't be
used for non-GIL purposes, then just add a comment to
those APIs.

With just NT and POSIX thread support, I think backporting the
new GIL implementation to 2.7 is not possible - we'd have to go
through a standard PEP 11 deprecation process and there are not
enough 2.x releases left for that. It could only be backported
as optional feature, to be enabled by a configure option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 14:40:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jan 2010 13:40:38 +0000
Subject: [issue5498] Can SGMLParser properly handle <empty/> tags?
In-Reply-To: <1237288775.97.0.464945533476.issue5498@psf.upfronthosting.co.za>
Message-ID: <1264599638.21.0.765850292385.issue5498@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

XML of the form <tag/> are an SGML hack, or more precisely the combination of two features of SGML. The forward slash closes the tag, and the following angle bracket is character data, not part of the tag.

The W3C validator  uses a real SGML parser for HTML doctypes, and fails on XML-like /> constructs: http://validator.w3.org/check?uri=data%3Atext%2Fhtml%2C%3C!DOCTYPE+html+PUBLIC+%22-%2F%2FW3C%2F%2FDTD+HTML+4.01%2F%2FEN%22+%22http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml4%2Fstrict.dtd%22%3E+%3Chtml%3E+%3Chead%3E+++%3Ctitle%3ETest%3C%2Ftitle%3E+++%3Cmeta+name%3Dtest+content%3Done%2F%3E+++%3Cmeta+name%3Dbug+content%3Dtwo%3E+%3C%2Fhead%3E+%3Cbody%3E+++%3Cp%3ETest%3C%2Fp%3E+%3C%2Fbody%3E+%3C%2Fhtml%3E&charset=%28detect+automatically%29&doctype=Inline&group=1&verbose=1

The complete explanation can be read at http://www.cs.tut.fi/~jkorpela/html/empty.html

In conclusion, sgmllib is right. Use an XML parser for XML or an HTML5 parser for HTML.

Kind regards

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5498>
_______________________________________

From report at bugs.python.org  Wed Jan 27 14:45:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jan 2010 13:45:05 +0000
Subject: [issue5498] Can SGMLParser properly handle <empty/> tags?
In-Reply-To: <1237288775.97.0.464945533476.issue5498@psf.upfronthosting.co.za>
Message-ID: <1264599905.07.0.689690102239.issue5498@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Damn, the URI got fubared :/ Anyway, I just wanted to give an example of the verbose error message, but the second link will contain enough explanation.

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5498>
_______________________________________

From report at bugs.python.org  Wed Jan 27 14:49:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Jan 2010 13:49:34 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1264600174.51.0.0884507733821.issue1225769@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Shouldn't the comment char definition belong in a dialect class?
The proposed patch does this correctly; then csv.reader automatically accepts the dialect parameters to override the selected dialect.

I'm still -1 on the feature - not standard enough, and easy to implement outside the csv module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

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: [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 15:00:50 2010
From: report at bugs.python.org (=?utf-8?q?Jonas_Weism=C3=BCller?=)
Date: Wed, 27 Jan 2010 14:00:50 +0000
Subject: [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: <1264600850.82.0.46831343858.issue7795@psf.upfronthosting.co.za>


Jonas Weism?ller <jonas.weismueller at gmail.com> added the comment:

uploading missing client file, changing the socket.setdefaulttimeout shows the issue.

----------
Added file: http://bugs.python.org/file16026/client.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7795>
_______________________________________

From report at bugs.python.org  Wed Jan 27 15:01:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 14:01:35 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B603F6A.4020408@egenix.com>
Message-ID: <1264600952.3631.25.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The arguments given in that thread sound a bit strange to me:
> just because there were no changes to a few files, doesn't really
> say anything about whether they contain working code or not.

That was a heuristic. Files which do not get any maintenance for years
while other similar files do are quite suspicious.
Given that nobody stepped up to contradict this hypothesis of mine, I
assume it was right after all ;)

More seriously, all the APIs in question (and most of their supporting
systems: IRIX etc.) seem practically dead. I don't want to rehash that
discussion here, but you can post on python-dev if you want.

> You could just as well remove them right now: if the GIL doesn't
> work on OS/2, then having support for it in the _thread module
> isn't really worth much, is it ?

Andrew told me he believed it possible to port the new GIL to OS/2. So
perhaps he'll do that before 3.2 is out.

> With just NT and POSIX thread support, I think backporting the
> new GIL implementation to 2.7 is not possible - we'd have to go
> through a standard PEP 11 deprecation process and there are not
> enough 2.x releases left for that. It could only be backported
> as optional feature, to be enabled by a configure option.

Right. That's what I think too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 15:14:12 2010
From: report at bugs.python.org (showell)
Date: Wed, 27 Jan 2010 14:14:12 +0000
Subject: [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: <1264601652.75.0.813290510094.issue7784@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

I will attempt to fix insert(0, pop) in the next patch I submit (using pointer vs. orphans count).

Just so we are clear on the performance that I'm promising, I expect benchmarks to prove out these facts:

  1) New-list will always perform comparably to old-list, particularly for access.
  2) New-list will outperform old-list for pre-pop.
  3) New-list will perform comparably to deque for pre-pop.
  4) Although not a super common use case, prepends that follow prepops should reclaim space and perform better than old list and comparably to deque.
  5) For prepends that exceed prepops, I expect deque to greatly outperform new lists, just as it did old lists.

As I explained on python-dev, the new patch should give lists the same performance profile as a pencil/paper todo list.  Prepop works in O(1) with occasional compacting.  Prepend generally works in O(N) unless you can reclaim space from prior prepops.

To measure memory wastage, the two worst case scenarios are a bunch of tiny lists or a list from you which you prepop just under 50% of the elements (although that 50% can be tuned later if that's the only showstopper).  You can certainly construct a benchmark that brings those negative aspects to light, but I think it would be more convincing to find an actual real-world program that performs worse or exhausts memory under the limitation.

In general, it would be nice to find a Python program that makes extensive use of lists to prove out that the new list implementation at least does not degrade performance.  To the extent that test suite all passes, we at least have some empirical evidence that "correctness" has not been jeopardized, but the more we can hammer on this, the better, of course.  Does anybody have a suggestion for a real-world list benchmark program?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Wed Jan 27 15:19:21 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 27 Jan 2010 14:19:21 +0000
Subject: [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: <1264601961.14.0.128542535524.issue7784@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

For macro benchmarking, I suggest using the Unladen Swallow benchmark suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Wed Jan 27 15:30:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 14:30:20 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264600952.3631.25.camel@localhost>
Message-ID: <4B604DF5.3000505@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> The arguments given in that thread sound a bit strange to me:
>> just because there were no changes to a few files, doesn't really
>> say anything about whether they contain working code or not.
> 
> That was a heuristic. Files which do not get any maintenance for years
> while other similar files do are quite suspicious.
> Given that nobody stepped up to contradict this hypothesis of mine, I
> assume it was right after all ;)

We'll only be able to tell for sure when it's too late: at release
time. We simply don't have any active developers working on more
exotic platforms, but that doesn't mean that Python isn't used
on those platforms.

> More seriously, all the APIs in question (and most of their supporting
> systems: IRIX etc.) seem practically dead. I don't want to rehash that
> discussion here, but you can post on python-dev if you want.

No need... I'm tired of trying to get Python devs on track with
respect to the PEP 11 process, deprecations, etc.

>> You could just as well remove them right now: if the GIL doesn't
>> work on OS/2, then having support for it in the _thread module
>> isn't really worth much, is it ?
> 
> Andrew told me he believed it possible to port the new GIL to OS/2. So
> perhaps he'll do that before 3.2 is out.
>
>> With just NT and POSIX thread support, I think backporting the
>> new GIL implementation to 2.7 is not possible - we'd have to go
>> through a standard PEP 11 deprecation process and there are not
>> enough 2.x releases left for that. It could only be backported
>> as optional feature, to be enabled by a configure option.
> 
> Right. That's what I think too.

I'll close the issue then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 15:32:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 14:32:29 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1264602749.71.0.949783545954.issue7753@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Closing the issue since we can't backport to Python 2.7 due to the missing thread library support.

The patch may still be useful for experiments by users, though, so thanks to Ross and Neil for creating it.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Wed Jan 27 15:55:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 27 Jan 2010 14:55:06 +0000
Subject: [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: <1264604106.22.0.825265912888.issue7795@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Duplicate of #6056.

----------
nosy: +brian.curtin
priority:  -> normal
resolution:  -> duplicate
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7795>
_______________________________________

From report at bugs.python.org  Wed Jan 27 16:18:54 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 27 Jan 2010 15:18:54 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1264605534.14.0.603028144055.issue1628484@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

(1) I can get around the configure problem by patching configure.in,
    meaning that va_list is detected correctly now. Perhaps BASECFLAGS
    should be used by default for the compile tests?

(2) Now I run into the problem that distutils somehow ignores the
    LDFLAGS:

 
gcc -pthread -shared build/temp.linux-x86_64-3.2/home/stefan/tmp/svn/py3k/Modules/_struct.o -L/usr/local/lib -o build/lib.linux-x86_64-3.2/_struct.so
collect2: ld terminated with signal 11 [Segmentation fault]



So it might be possible to fix the situation by changing configure.in
and distutils. On the other hand, the patches from Bob and Antoine are
simpler.

----------
Added file: http://bugs.python.org/file16027/basecflags-configure.in.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 16:58:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 15:58:41 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1264607921.68.0.840616159581.issue6715@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies:  -please support lzma compression as an extension and in	the tarfile module
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Wed Jan 27 16:58:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 15:58:57 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1264607937.88.0.73738881252.issue5689@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
dependencies: +xz compressor support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5689>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:07:24 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 27 Jan 2010 16:07:24 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
In-Reply-To: <1264598225.6.0.646823439721.issue1225769@psf.upfronthosting.co.za>
Message-ID: <19296.25781.757391.310024@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Amaury> Comment lines in csv data may be common in some areas, but they
    Amaury> are not part of any standard, and they are not the only possible
    Amaury> extension to csv files (for example: ignore empty lines, or a
    Amaury> terminal \ for line continuation...)

Or different peoples' notion of how to comment strings.  Precidely because
there is no standard way to comment out content in CSV files people are free
to dream up anything they want, including,
but not limited to:

    * C- or C++-style comments
    * MoinMoin-style comments, where "##" introduces a comment but a lone
      "#" introduces a meta command to the parser

Trying to accommodate the myriad varieties of way s people might decide to
comment out content would put an undue burden on the csv module's parser.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

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: [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  Wed Jan 27 17:11:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 16:11:59 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1264608719.68.0.318121968698.issue1225769@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Skip, Raymond and Amaury.
Since the csv module returns you an iterator, it's easy enough to wrap it in another iterator.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:14:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 16:14:11 +0000
Subject: [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: <1264608851.29.0.180631196936.issue7796@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In this case, what is wrong with:

if isinstance(obj, my_tuple): ...

or do you want to catch all namedtuples? And if so, why?

(I suppose it would be easy to make all namedtuples inherit from a common base class, though)

----------
assignee:  -> rhettinger
nosy: +pitrou, rhettinger
priority:  -> normal
stage:  -> needs patch
type:  -> feature request
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:16:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jan 2010 16:16:31 +0000
Subject: [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: <1264608991.5.0.683191710781.issue7796@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

namedtuple is a factory function, not a class (as hinted by the naming in lower case, see PEP?8), so there are no instances of namedtuple.

You can workaround that with issubclass, or checking for special namedtuples attributes (_asdict, _replace, but this is fragile), or just not use class cheking, often unneeded in Python code.

Kind regards

----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:18:43 2010
From: report at bugs.python.org (Peter Waller)
Date: Wed, 27 Jan 2010 16:18:43 +0000
Subject: [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: <1264609123.82.0.37028609863.issue7796@psf.upfronthosting.co.za>


Peter Waller <peter.waller at gmail.com> added the comment:

Hi Antoine and Eric, 

Thanks for your responses.

I need to be able to catch all named tuples, I don't know in advance what instance of a namedtuple it might be, but I want my function to only accept named tuples. Is this unreasonable?

(I am actually writing a C interface which does conversion from namedtuples to a form of "RecordSpecification" to do with databases. The namedtuple is arbitrarily created by the user.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:21:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 16:21:44 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264609123.82.0.37028609863.issue7796@psf.upfronthosting.co.za>
Message-ID: <1264609376.3631.27.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I need to be able to catch all named tuples, I don't know in advance
> what instance of a namedtuple it might be, but I want my function to
> only accept named tuples. Is this unreasonable?

I don't know. Why exactly don't you want to accept something else?
Perhaps the user has their own namedtuple-like class. Or perhaps they're
fine with plain tuples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:23:50 2010
From: report at bugs.python.org (Peter Waller)
Date: Wed, 27 Jan 2010 16:23:50 +0000
Subject: [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: <1264609430.91.0.436911987042.issue7796@psf.upfronthosting.co.za>


Peter Waller <peter.waller at gmail.com> added the comment:

In this case, I need to have names for each object. It is also desirable to use the namedtuple because of their lightweight nature.

If they were to subclass the namedtuple I would be happy to accept that, but I really do want them to pass some form of namedtuple to me, to have some sort of consistency. The named tuple gives an obvious simple interface for determining which fields are available and the order they are in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:24:45 2010
From: report at bugs.python.org (betatim)
Date: Wed, 27 Jan 2010 16:24:45 +0000
Subject: [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: <1264609485.71.0.687149935615.issue7796@psf.upfronthosting.co.za>


Changes by betatim <betatim at gmail.com>:


----------
nosy: +thead

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 17:36:49 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Jan 2010 16:36:49 +0000
Subject: [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: <1264610209.74.0.350448312368.issue7796@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems a perfect case for "duck typing" style of programming:
All namedtuple classes:
- inherit from tuple
- have a "_fields" class attribute
These two properties could be the "duck test" for namedtuples, regardless of the actual implementation.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Wed Jan 27 19:17:16 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 18:17:16 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1264605534.14.0.603028144055.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4B608328.8090003@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> (1) I can get around the configure problem by patching configure.in,
>     meaning that va_list is detected correctly now. Perhaps BASECFLAGS
>     should be used by default for the compile tests?
> 
> (2) Now I run into the problem that distutils somehow ignores the
>     LDFLAGS:
> 
>  
> gcc -pthread -shared build/temp.linux-x86_64-3.2/home/stefan/tmp/svn/py3k/Modules/_struct.o -L/usr/local/lib -o build/lib.linux-x86_64-3.2/_struct.so
> collect2: ld terminated with signal 11 [Segmentation fault]
> 
> 
> 
> So it might be possible to fix the situation by changing configure.in
> and distutils. On the other hand, the patches from Bob and Antoine are
> simpler.

Right, let's go with Antoine's patch and fix the real Makefile
variable problem in some other release - this will require some
major changes to the Makefile and also some changes to distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 19:18:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Jan 2010 18:18:31 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1264616311.63.0.62922533266.issue1628484@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_______________________________________

From report at bugs.python.org  Wed Jan 27 19:28:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 27 Jan 2010 18:28:26 +0000
Subject: [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: <1264616906.46.0.142058538023.issue7793@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thank you for the patch and the analysis.
It fixes the recursion.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7793>
_______________________________________

From report at bugs.python.org  Wed Jan 27 19:43:27 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 27 Jan 2010 18:43:27 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
In-Reply-To: <1264608719.68.0.318121968698.issue1225769@psf.upfronthosting.co.za>
Message-ID: <19296.35144.35252.933365@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Antoine> Since the csv module returns you an iterator, it's easy enough
    Antoine> to wrap it in another iterator.

I prefer to do this sort of stuff as a pre-processing step, so I generally
wrap the file object input and use that iterator as the input "file" for the
csv reader.  I'm sure it's largely a matter of taste and what you need to
do.  Certainly wrapping the csv reader's output would be useful to provide
sensible missing values.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_______________________________________

From report at bugs.python.org  Wed Jan 27 21:50:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 20:50:00 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264625400.32.0.677765014319.issue7610@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
resolution:  -> accepted
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Wed Jan 27 22:01:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jan 2010 21:01:00 +0000
Subject: [issue7765] 'unittest' documentation misprints
In-Reply-To: <1264275798.04.0.174559060611.issue7765@psf.upfronthosting.co.za>
Message-ID: <1264626060.76.0.214439994457.issue7765@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r77796 (trunk) and r77797 (py3k), thanks for the patches!

----------
assignee: georg.brandl -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7765>
_______________________________________

From report at bugs.python.org  Wed Jan 27 22:20:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 21:20:17 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264627217.68.0.438920429599.issue7610@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch has been committed in r77798 (trunk) and r77800 (py3k). Thank you!
I won't commit it to 2.6 and 3.1 because it's too involved to qualify as a bug fix, though.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Wed Jan 27 22:50:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 21:50:23 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264629023.85.0.0810659902766.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you. The patch was committed mostly unchanged in r77802 (a few cosmetic fixes). Now trunk and py3k must absolutely be patched in order to conform to the new behaviour. Can you produce a patch for trunk?

----------
priority:  -> release blocker
stage:  -> needs patch
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Wed Jan 27 22:50:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jan 2010 21:50:27 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264629027.73.0.486704022218.issue6939@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file15931/patch26_largefile_tested.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Wed Jan 27 22:56:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jan 2010 21:56:40 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1264629400.26.0.526198437848.issue7030@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7030>
_______________________________________

From report at bugs.python.org  Wed Jan 27 23:06:49 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 27 Jan 2010 22:06:49 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264630009.83.0.638972329089.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Thanks a lot B-)
I'll make a patch for trunk from now to this W.E.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Wed Jan 27 23:15:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jan 2010 22:15:01 +0000
Subject: [issue5362] Add configure option to disable Py3k warnings
In-Reply-To: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
Message-ID: <1264630501.65.0.843055556048.issue5362@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5362>
_______________________________________

From report at bugs.python.org  Thu Jan 28 00:23:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 27 Jan 2010 23:23:26 +0000
Subject: [issue7666] test_lib2to3 fails if path contains space
In-Reply-To: <1263144970.71.0.0711574272064.issue7666@psf.upfronthosting.co.za>
Message-ID: <1264634606.09.0.696166922488.issue7666@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The fix on r77419 do not work.

The patch in attachment behaves better.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7666>
_______________________________________

From report at bugs.python.org  Thu Jan 28 00:47:10 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Wed, 27 Jan 2010 23:47:10 +0000
Subject: [issue1599329] urllib(2) should allow automatic decoding by charset
Message-ID: <1264636030.7.0.249207650033.issue1599329@psf.upfronthosting.co.za>


Changes by Lino Mastrodomenico <l.mastrodomenico at gmail.com>:


----------
nosy: +mastrodomenico

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599329>
_______________________________________

From report at bugs.python.org  Thu Jan 28 00:51:03 2010
From: report at bugs.python.org (Lino Mastrodomenico)
Date: Wed, 27 Jan 2010 23:51:03 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1264636263.73.0.339018955406.issue4733@psf.upfronthosting.co.za>


Changes by Lino Mastrodomenico <l.mastrodomenico at gmail.com>:


----------
nosy: +mastrodomenico

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Jan 28 01:01:55 2010
From: report at bugs.python.org (Peter Waller)
Date: Thu, 28 Jan 2010 00:01:55 +0000
Subject: [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: <1264636915.16.0.936588292957.issue7796@psf.upfronthosting.co.za>


Peter Waller <peter.waller at gmail.com> added the comment:

Hi Amaury,

Thanks. I had heard of but never bothered to read about duck-typing before now; though I have used it passively before. I think it does make sense in this case. I can't imagine any case where checking for the _fields attribute would fail and isinstance(x, namedtuple) would not.

Besides which, for my current project I am forced to implement such a "workaround" anyway, so it doesn't affect me as such.

The only reason that remains why I would want it is that I often use isinstance(x, Y) to deal with different Ys, and that was the thing I intuitively wanted to use in this case as a python programmer for quite a few years now. This is probably a pretty weak reason, so I am happy to close this issue if the consensus points to duck typing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Thu Jan 28 02:39:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 Jan 2010 01:39:42 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1264642782.39.0.49298193306.issue3367@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Excellent!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Thu Jan 28 02:51:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2010 01:51:46 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264643506.87.0.650809514735.issue7610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Nir, could you also provide a test for the part that "handles unconsumed data" (line 601 in zipfile.py)?

In r77809 (and r77810) I made a change to avoid using zlib when it's not necessary (zlib is not always available), and I was going to commit a typo that luckily I noticed in the diff. The tests however didn't notice anything because that part is untested.

----------
nosy: +ezio.melotti
stage: committed/rejected -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 05:29:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2010 04:29:22 +0000
Subject: [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: <1264652962.09.0.774282549513.issue7791@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I removed it in r77814.

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7791>
_______________________________________

From report at bugs.python.org  Thu Jan 28 05:58:18 2010
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 28 Jan 2010 04:58:18 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1264654698.79.0.252590760148.issue7325@psf.upfronthosting.co.za>


Thomas Holmes <shadox at gmail.com> added the comment:

I made a new patch off of the 2.7 trunk version.  I think I have handled some of the issues more cleanly.

Please see Py(27)7325.diff

I addressed the issue of using a relative path in the tempdir to achieve the 'guaranteed' ability to write rather than assuming the location of the python executable was writable.

----------
Added file: http://bugs.python.org/file16028/Py(27)7325.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Thu Jan 28 06:40:37 2010
From: report at bugs.python.org (Justin Lebar)
Date: Thu, 28 Jan 2010 05:40:37 +0000
Subject: [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 07:55:30 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 28 Jan 2010 06:55:30 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264661730.57.0.828038620368.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

The related scenario is a system without zlib. How do you suggest simulating this in test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 08:07:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2010 07:07:25 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264662445.92.0.426303560558.issue7610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The test should just check that the part that handles unconsumed data works when zlib is available. AFAIU if zlib is not available this part (i.e. the content of the if) can be skipped so it doesn't need to be tested.

(When zlib is not available 'zlib' is set to None, see the try/except at the beginning of zipfile.py)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 08:35:59 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 28 Jan 2010 07:35:59 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264664159.56.0.377782268291.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Unconsumed data is compressed data. If the part which handles unconsumed data does not work when zlib is available, then the existing tests would fail. In any case the unconsumed buffer is an implementation detail of zipfile.

I see a point in adding a test to make sure zipfile behaves as expected when zlib is not available, but how?

Also, on which systems is zlib missing? I don't see this mentioned in the zlib docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 08:56:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2010 07:56:21 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264665381.62.0.600792511683.issue7610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> If the part which handles unconsumed data does not work when zlib is available, then the existing tests would fail.

If the existing tests end up testing that part of code too then it's probably fine. I tried to add a print inside the 'if' (at line 605) but it didn't print anything. However here some tests are skipped, so maybe that part of code is tested in some of these skipped tests.

> I see a point in adding a test to make sure zipfile behaves as expected when zlib is not available, but how?

Several tests are already skipped in test_zipfile.py when zlib is not available (all the ones with the skipUnless decorator)

> Also, on which systems is zlib missing? I don't see this mentioned in the zlib docs.

Even if it's available and usually already installed in most of the systems, in some -- like mine (Linux) -- is not installed.

If you can confirm that that part of code is already tested in some of the tests that here are skipped, I will close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 16:10:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Jan 2010 15:10:53 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1264691453.37.0.567767438831.issue5673@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +astrand
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

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: [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 16:33:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Jan 2010 15:33:19 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1264692799.94.0.771039485543.issue5673@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some comments:

- why do you say Thread.join() uses a busy loop? is it because it uses Condition.wait()? If so, this will be solved in py3k by issue7316 (which you are welcome to review). Otherwise, I think there should be an upper bound on the sleeping granularity (say 2 seconds).

- the "if 'timeout' in kwargs" dance is a bit complicated. Why not simply "kwargs.pop('timeout', None)"?

- if it times out, communicate() should raise a specific exception. Bonus points if the exception holds the partial output as attributes (that's what we do for non-blocking IO in py3k), but if it's too difficult we can leave that out. I don't think returning None would be very good.

- for consistency, other methods should probably raise the same exception. I think we can leave out the more complex scenarios such as "timing out but still processing the beginning of the output".

- I agree that further input from python-dev or python-ideas would be nice

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5673>
_______________________________________

From report at bugs.python.org  Thu Jan 28 16:39:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Jan 2010 15:39:05 +0000
Subject: [issue5362] Add configure option to disable Py3k warnings
In-Reply-To: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
Message-ID: <1264693145.72.0.0115929933865.issue5362@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Given the very small benefits, I don't think there's any point in making this a configuration variable. A hardcoded flag would be sufficient, and expert users would be able to recompile their Python (as with the FAST_LOOPS flag).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5362>
_______________________________________

From report at bugs.python.org  Thu Jan 28 18:13:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 28 Jan 2010 17:13:02 +0000
Subject: [issue5362] Add configure option to disable Py3k warnings
In-Reply-To: <1235516116.64.0.427185955219.issue5362@psf.upfronthosting.co.za>
Message-ID: <1264698782.95.0.921413205092.issue5362@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I'm with Antoine on this one.

Also, instead of removing the flag completely which will cause problems with extensions relying on it, I'd suggest to just disable the PyErr_WarnPy3k(msg, stacklevel) macro and turn it into a no-op if a compile time variable DISABLE_PY3K_WARNINGS (or similar) is defined (which should be undefined per default).

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5362>
_______________________________________

From report at bugs.python.org  Thu Jan 28 18:24:14 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 17:24:14 +0000
Subject: [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: <1264699454.11.0.963605791128.issue7797@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7797>
_______________________________________

From report at bugs.python.org  Thu Jan 28 18:48:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 17:48:54 +0000
Subject: [issue7591] test_distutils: test_get_platform fails on 3.1
In-Reply-To: <1262037646.69.0.736815129849.issue7591@psf.upfronthosting.co.za>
Message-ID: <1264700934.92.0.662228979853.issue7591@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Fixed with r77586

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7591>
_______________________________________

From report at bugs.python.org  Thu Jan 28 18:53:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 17:53:31 +0000
Subject: [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: <1264701211.59.0.542664372466.issue7732@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 18:58:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 17:58:27 +0000
Subject: [issue767645] incorrect os.path.supports_unicode_filenames
Message-ID: <1264701507.85.0.0917524226735.issue767645@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Tests
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue767645>
_______________________________________

From report at bugs.python.org  Thu Jan 28 19:07:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Jan 2010 18:07:06 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264596474.3631.13.camel@localhost>
Message-ID: <1264702100.3358.16.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
> where available and only use gettimeofday() as fallback solution
> together with times(), ftime() and time().

Ok, I've tried and it's less good than expected. Using CLOCK_MONOTONIC
absolutely kills efficiency. CLOCK_REALTIME is ok but it has no obvious
benefits (microsecond resolution as given by gettimeofday() is probably
sufficient).

The explanation AFAICT is that pthread_cond_timedwait() waits for
absolute clock values as given by CLOCK_REALTIME.
CLOCK_MONOTONIC gives other values (the man page says: "represents
monotonic time since some unspecified starting point"). These values are
probably "in the past" as seen from pthread_cond_timedwait(), which
implies a busy loop of waiting for the GIL to be released, inside of
being suspended gracefully until the timeout.

I can still produce a patch with only CLOCK_REALTIME but I'm not sure
it's worth the code complication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Thu Jan 28 19:17:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jan 2010 18:17:27 +0000
Subject: [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  Thu Jan 28 19:21:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 28 Jan 2010 18:21:04 +0000
Subject: [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: <1264702864.02.0.196643800361.issue7799@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yes. The standard tests should be wrapped in a suite before being passed into load_tests. That's a bug - thanks for catching it.

----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7799>
_______________________________________

From report at bugs.python.org  Thu Jan 28 19:22:27 2010
From: report at bugs.python.org (Nir Aides)
Date: Thu, 28 Jan 2010 18:22:27 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264702947.83.0.350824264348.issue7610@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I actually meant how would you simulate zlib's absence on a system in which it is present?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 19:28:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Jan 2010 18:28:29 +0000
Subject: [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: <1264703309.15.0.392495786558.issue7732@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is slightly incorrect: if PyFile_FromFile fails for another reason (PyString_FromString(name) runs out of memory), the fp is not closed and the caller is right to call fclose().

IMO PyFile_FromFile() should be changed to consistently leave the fp opened when NULL is returned. But then, many usages of this function are incorrect, e.g in posixmodule.c :-(

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 19:31:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2010 18:31:03 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264703463.73.0.813989319154.issue7610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The easiest way is to setting zlib to None or not import it at all.
Are you suggesting that test_zipfile should be always run with and without zlib to check that everything (except the things that require zlib of course) works in both the cases?
My concern was about that part that handles unconsumed data only, because I didn't see any test in the patch that specifically check it. If there are already tests that checks it, then it's fine, even if it's not possible to test that part without zlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 21:05:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 20:05:48 +0000
Subject: [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: <1264709148.56.0.0439056152922.issue7732@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15937/issue7732_find_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 21:11:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 20:11:28 +0000
Subject: [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: <1264709488.41.0.791846924469.issue7732@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

> if PyFile_FromFile fails for another reason (PyString_FromString(name)
> runs out of memory), the fp is not closed and the caller is right to
> call fclose().

As far as I understand, the fp is never left open, when PyFile_FromFile returns NULL. So there's no reason to call fclose on it.

However I found a reference leak in the case you describe (PyString_FromString(name) == NULL).

It is fixed with this last update.

----------
Added file: http://bugs.python.org/file16029/issue7732_find_module_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 21:23:59 2010
From: report at bugs.python.org (Trundle)
Date: Thu, 28 Jan 2010 20:23:59 +0000
Subject: [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: <1264710239.92.0.635828060298.issue7732@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

Note that the fp gets set with `fill_file_fields()` and that is called after the error return of `PyString_FromString()`. Hence, the fp is left open if `PyString_FromString()` returns NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 21:30:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 28 Jan 2010 20:30:54 +0000
Subject: [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: <1264710654.47.0.772174516547.issue7732@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

AFAICT, in this case, if PyString_FromString gives NULL, then (o_name == NULL) and the function returns without calling "fill_file_fields".
Hence, the fp is not opened.

Do you suggest something else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 21:40:51 2010
From: report at bugs.python.org (Trundle)
Date: Thu, 28 Jan 2010 20:40:51 +0000
Subject: [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: <1264711251.94.0.280786343621.issue7732@psf.upfronthosting.co.za>


Trundle <andy-python at hammerhartes.de> added the comment:

`fill_file_fields()` does not open the fp, the caller of `PyFile_FromFile()` opens the fp.

I don't have a better idea, that's why I don't have provided a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7732>
_______________________________________

From report at bugs.python.org  Thu Jan 28 21:43:34 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2010 20:43:34 +0000
Subject: [issue7610] Cannot use both read and readline method in same
	ZipExtFile object
In-Reply-To: <1262247083.64.0.723829588215.issue7610@psf.upfronthosting.co.za>
Message-ID: <1264711414.61.0.655644459414.issue7610@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Apparently that part of code is already tested in other tests that use deflated mode, so I'll close this again. Thanks for the info.

----------
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7610>
_______________________________________

From report at bugs.python.org  Thu Jan 28 23:26:22 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 28 Jan 2010 22:26:22 +0000
Subject: [issue7798] document pydoc methods
In-Reply-To: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za>
Message-ID: <1264717582.98.0.964599140373.issue7798@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7798>
_______________________________________

From report at bugs.python.org  Thu Jan 28 23:26:42 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 28 Jan 2010 22:26:42 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264717602.75.0.296712218802.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Hello

Here is the patch for the python trunk, regarding truncate() behaviour.
I've tested it on windows and linux, against IO test suites (with -uall), in debug and normal mode.

I've also updated some docstrings, and added tests for untested potential errors around buffered read+write streams, when truncating.

----------
Added file: http://bugs.python.org/file16030/PY27_truncate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Fri Jan 29 00:10:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 28 Jan 2010 23:10:00 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264702100.3358.16.camel@localhost>
Message-ID: <4B621944.4030208@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
>> where available and only use gettimeofday() as fallback solution
>> together with times(), ftime() and time().
> 
> Ok, I've tried and it's less good than expected. Using CLOCK_MONOTONIC
> absolutely kills efficiency. CLOCK_REALTIME is ok but it has no obvious
> benefits (microsecond resolution as given by gettimeofday() is probably
> sufficient).
> 
> The explanation AFAICT is that pthread_cond_timedwait() waits for
> absolute clock values as given by CLOCK_REALTIME.
> CLOCK_MONOTONIC gives other values (the man page says: "represents
> monotonic time since some unspecified starting point"). These values are
> probably "in the past" as seen from pthread_cond_timedwait(), which
> implies a busy loop of waiting for the GIL to be released, inside of
> being suspended gracefully until the timeout.

The CLOCK_MONOTONIC timer only guarantees that you
get an accurate time count. It doesn't maintain any relationship
to the wall clock time. For the case in question you don't need
the wall clock time, though. It's more important not have the
clock go backwards or be subject to jitter.

pthreads will default to use the real time clock. In order
to have them use the monotonic timer, you have to setup
a condition variable attribute: See the man-page for
pthread_condattr_setclock().

> I can still produce a patch with only CLOCK_REALTIME but I'm not sure
> it's worth the code complication.

Even if you don't use CLOCK_MONOTONIC you should still prefer
clock_gettime() over gettimeofday() simply because it's faster.
The resolution of both will likely be the same, unless the
hardware provides a more accurate timer than kernel ticks.

The code won't get more complicated if you refactor the time
querying logic into a separate function (which the compiler can then
inline as necessary).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 29 00:31:40 2010
From: report at bugs.python.org (Ross Cohen)
Date: Thu, 28 Jan 2010 23:31:40 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B604DF5.3000505@egenix.com>
Message-ID: <20100128152826.5b0b280e@neeble>


Ross Cohen <rcohen at snurgle.org> added the comment:

I am confused by this line of reasoning. Is it ok to ignore the
deprecation process in py3k but not in 2.x? Is it only ok if a core
developer does it?

If the point of 2.7 is to make it easier for apps and packages to be
ported to py3k, then what would be the point of these platforms moving
to 2.7 in the first place? It seems perfectly reasonable not to support
platforms which are never going to care the release. If the platforms
are broken for 2.7, you'll get that much more warning before 3.2 is
released so it can be fixed.

Ross

On Wed, 27 Jan 2010 14:30:20 +0000
Marc-Andre Lemburg <report at bugs.python.org> wrote:

> Antoine Pitrou wrote:
> > More seriously, all the APIs in question (and most of their supporting
> > systems: IRIX etc.) seem practically dead. I don't want to rehash that
> > discussion here, but you can post on python-dev if you want.
> 
> No need... I'm tired of trying to get Python devs on track with
> respect to the PEP 11 process, deprecations, etc.
> 
> >> You could just as well remove them right now: if the GIL doesn't
> >> work on OS/2, then having support for it in the _thread module
> >> isn't really worth much, is it ?
> > 
> > Andrew told me he believed it possible to port the new GIL to OS/2. So
> > perhaps he'll do that before 3.2 is out.
> >
> >> With just NT and POSIX thread support, I think backporting the
> >> new GIL implementation to 2.7 is not possible - we'd have to go
> >> through a standard PEP 11 deprecation process and there are not
> >> enough 2.x releases left for that. It could only be backported
> >> as optional feature, to be enabled by a configure option.
> > 
> > Right. That's what I think too.
> 
> I'll close the issue then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 29 00:33:25 2010
From: report at bugs.python.org (Robin Schoonover)
Date: Thu, 28 Jan 2010 23:33:25 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1264721605.58.0.836379716438.issue3871@psf.upfronthosting.co.za>


Changes by Robin Schoonover <end at cornhooves.org>:


----------
nosy: +rschoon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri Jan 29 00:51:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Jan 2010 23:51:06 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B621944.4030208@egenix.com>
Message-ID: <1264722740.3479.5.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pthreads will default to use the real time clock. In order
> to have them use the monotonic timer, you have to setup
> a condition variable attribute: See the man-page for
> pthread_condattr_setclock().

I'll look at that, but I'm not thrilled at the propect of complicating
the code paths so much. There may be systems where CLOCK_MONOTONIC is
unavailable, others where pthread_condattr_setclock() is unsupported,
etc.

> The code won't get more complicated if you refactor the time
> querying logic into a separate function (which the compiler can then
> inline as necessary).

It does get more complicated, since there are several paths
(clock_gettime() and then a fallback on gettimeofday()).
I'm not talking about complexity in the executable but about maintenance
complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

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: [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:12:57 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 29 Jan 2010 00:12:57 +0000
Subject: [issue7800] Attributes of type list are static
In-Reply-To: <1264723118.05.0.241315324434.issue7800@psf.upfronthosting.co.za>
Message-ID: <1264723977.04.0.906855512656.issue7800@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The list in your example is a *class attribute* not an instance attribute, so yes it is only initialised once. You can still access it through the instance (self) because of Python member lookup rules.

If you want one list per instance then initialise it in __init__ instead of making it a class attribute.

In short, Python is not Java.

----------
nosy: +michael.foord
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7800>
_______________________________________

From report at bugs.python.org  Fri Jan 29 01:15:44 2010
From: report at bugs.python.org (Chris Carter)
Date: Fri, 29 Jan 2010 00:15:44 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1264724144.96.0.823806122293.issue7643@psf.upfronthosting.co.za>


Chris Carter <jesdisciple at gmail.com> added the comment:

Then I must ask, why did the string attribute behave differently?  I added it to allow for that, and the behavior seems inconsistent.

----------
nosy: +Chris.Carter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Jan 29 01:16:21 2010
From: report at bugs.python.org (Chris Carter)
Date: Fri, 29 Jan 2010 00:16:21 +0000
Subject: [issue7643] What is a Unicode line break character?
In-Reply-To: <1262767606.8.0.225636949209.issue7643@psf.upfronthosting.co.za>
Message-ID: <1264724181.94.0.894162487269.issue7643@psf.upfronthosting.co.za>


Chris Carter <jesdisciple at gmail.com> added the comment:

My bad, wrong bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7643>
_______________________________________

From report at bugs.python.org  Fri Jan 29 01:16:53 2010
From: report at bugs.python.org (Chris Carter)
Date: Fri, 29 Jan 2010 00:16:53 +0000
Subject: [issue7800] Attributes of type list are static
In-Reply-To: <1264723118.05.0.241315324434.issue7800@psf.upfronthosting.co.za>
Message-ID: <1264724213.8.0.598905027594.issue7800@psf.upfronthosting.co.za>


Chris Carter <jesdisciple at gmail.com> added the comment:

Then I must ask, why did the string attribute behave differently?  I added it to allow for that, and the behavior seems inconsistent.

----------

_______________________________________
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: [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 01:23:53 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 29 Jan 2010 00:23:53 +0000
Subject: [issue7800] Attributes of type list are static
In-Reply-To: <1264723118.05.0.241315324434.issue7800@psf.upfronthosting.co.za>
Message-ID: <1264724633.9.0.785540392653.issue7800@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Because strings are immutable. Your list access (self.list.append) mutates the existing list in place.

Because strings are immutable you += is exactly equivalent to the following code:

    self.string = self.string + str(i)

The first lookup of self.string actually looks up the class attribute (because on a fresh instance there is no instance attribute). The class attribute is an empty string. You then create a new string by adding the empty string to str(i) and assign an *instance* attribute to str(i).

Because you haven't mutated the class attribute (strings are immutable) the next time round with a new instance the whole process repeats and the first lookup of self.string still finds the class attribute which is still an empty string.

With your example code try the following:

    print Lister.string
    print Lister()
    print Lister.string

You will see that the class attribute is unchanged in between instantiations. The += on immutable objects probably doesn't quite behave how you expect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7800>
_______________________________________

From report at bugs.python.org  Fri Jan 29 01:25:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Jan 2010 00:25:26 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1264724726.83.0.593259708652.issue4331@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Christophe,

It looks like your patch goes out of its way to avoid creating nested partials.  This is a worthwhile goal and I think it should be done in partial_new so that partial(partial(f, x), y) returns partial(f, x, y).

If fact, I was surprised to learn that current partial implementation does not behave this way:

>>> partial(partial(f, 1), 2).func
<functools.partial object at 0x100435af8>

Does anyone know the reason for the current behavior?  It is possible that I am missing some subtlety related to keyword arguments.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Fri Jan 29 01:34:23 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Jan 2010 00:34:23 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264725263.27.0.745348912994.issue7092@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is my review of issue7092_syntax_imports_v3.diff:

- test_itertools.py: please replace
      [tuple([arg[i] if i < len(arg) else None for arg in args])
       for i in range(max(map(len, args)))]
  by something more readable (nested for loops for example)

- test_mailbox.py: why doesn't test_support.import_module('rfc822')
  specify deprecated=True? maybe the module can be imported normally...

- test_pyclbr.py:   replace self.assertTrue(key in obj) with assertIn()
- test_wsgiref.py:  replace self.assertTrue(key in h.environ)

- test_queue.py: test could be identical to the one in py3k.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 01:38:27 2010
From: report at bugs.python.org (TJ Sullivan)
Date: Fri, 29 Jan 2010 00:38:27 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two
	corrupted	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1264725507.58.0.0840967553459.issue7437@psf.upfronthosting.co.za>


TJ Sullivan <tjsulli at gmail.com> added the comment:

I would be happy to test the new package for you. I am running 10.3.9 and Had attempted to install 2.6.4 recently without realizing it, so my terminal version is 2.6.4 but idle and back at 2.5. email me if you want me to test it for you.

----------
nosy: +tjsulli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7437>
_______________________________________

From report at bugs.python.org  Fri Jan 29 02:13:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 01:13:11 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1264727591.18.0.410882231592.issue4944@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Fri Jan 29 02:18:22 2010
From: report at bugs.python.org (Michael Newman)
Date: Fri, 29 Jan 2010 01:18:22 +0000
Subject: [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 02:28:52 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jan 2010 01:28:52 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264728532.72.0.385709856804.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's mine about issue7092_check_warnings_v3.diff:

1) test_callable should keep testing callable() and the warnings should be caught;
2) in test_bsddb3 the problems should be correct in the module if possible and worth it (the module is deprecated);
3) next to the several '# Silence py3k warnings' it would be nice to have a note about what warning you are exactly silencing;
4) def test_deprecated_builtin_map -> test_deprecated_builtin_map_with_None, otherwise it seems that map is deprecated;
5) in test[_deep]_copy I'm not entirely sure that the tests are equivalent using in (and if they are you should use assertIn);
6) in test_socket I would keep callable, also shouldn't the raise in the next line raise a warning as well?;
7)  the self.assertEqual(`u2`, `d2`) in test_userdict could just use repr() instead;
8) a few tests in test_weakref should use assert[Not]In instead of assertTrue(x [not] in y).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 02:51:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jan 2010 01:51:33 +0000
Subject: [issue7802] socket.gaierror before ProtocolError for xmlrpc.client
In-Reply-To: <1264727901.97.0.79188131386.issue7802@psf.upfronthosting.co.za>
Message-ID: <1264729893.58.0.135712280911.issue7802@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW it had the same behavior already on Python 2.4.

----------
nosy: +ezio.melotti, loewis
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7802>
_______________________________________

From report at bugs.python.org  Fri Jan 29 02:55:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 01:55:36 +0000
Subject: [issue1481] test_uuid is warning about unreliable functions
In-Reply-To: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
Message-ID: <1264730136.21.0.935346803908.issue1481@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

These tests have been disabled for a little over two years now. I've run the previously disabled tests on Windows, Mac OSX, and Linux numerous times and haven't seen any instability or failures (not that it proves much). 

I wasn't around at the time to know what specific platforms caused the instability and don't see any evidence, but can we re-enable them to see if and where they cause problems today? The attached patch re-enables the disabled tests, and brings the if-statement skipping up to speed with skip decorators.

----------
keywords: +needs review, patch
nosy: +brian.curtin
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0
Added file: http://bugs.python.org/file16031/issue1481.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
_______________________________________

From report at bugs.python.org  Fri Jan 29 02:57:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jan 2010 01:57:45 +0000
Subject: [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: <1264730265.73.0.799897245015.issue7801@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +loewis
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7801>
_______________________________________

From report at bugs.python.org  Fri Jan 29 03:20:56 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Fri, 29 Jan 2010 02:20:56 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264731656.03.0.619804693086.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gmail.com> added the comment:

1) Agree. Extra checks removed.
2) My mistake. Fixed.
3) Fexed.
4) Methods documentation fixed. Also added examples.
5) Fixed
6) Allow ints in the following unary methods (all except the ones excluded by skrah in cdecimal):
- abs
- canonical
- copy_abs
- copy_decimal
- copy_negate
- exp
- is_finite
- is_infinite
- is_nan
- is_normal
- is_qnan
- is_signed
- is_snan
- is_subnormal
- is_zero
- ln
- log10
- logb
- minus
- next_minus
- next_plus
- sqrt
- to_*_string
- to_integral_*

(also documented them properly as in 4)

copy_sing fixed and documented to have the same behaibour.

Ans a change in Doc/library/decimal.rst to reflec the new behaibour.

----------
Added file: http://bugs.python.org/file16032/issue7633_jjconti3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Fri Jan 29 03:41:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jan 2010 02:41:20 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1264732880.53.0.353888216251.issue6490@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The function is still marked as deprecated in the 2.x doc and undocumented in 3.x (the function is there, but the description points somewhere else).

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Fri Jan 29 04:30:05 2010
From: report at bugs.python.org (Chris Carter)
Date: Fri, 29 Jan 2010 03:30:05 +0000
Subject: [issue7800] Attributes of type list are static
In-Reply-To: <1264723118.05.0.241315324434.issue7800@psf.upfronthosting.co.za>
Message-ID: <1264735805.44.0.307554778086.issue7800@psf.upfronthosting.co.za>


Chris Carter <jesdisciple at gmail.com> added the comment:

Ha, fun with language features.  Thanks for the detailed explanation. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7800>
_______________________________________

From report at bugs.python.org  Fri Jan 29 05:32:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 04:32:41 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1264739561.92.0.626192420927.issue1926@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Fri Jan 29 05:40:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 04:40:41 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1264740041.93.0.394599977771.issue2052@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> test needed
versions: +Python 2.6 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Fri Jan 29 05:42:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 04:42:52 +0000
Subject: [issue1927] raw_input behavior incorrect if readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1264740172.8.0.701660343484.issue1927@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> test needed
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1927>
_______________________________________

From report at bugs.python.org  Fri Jan 29 11:05:05 2010
From: report at bugs.python.org (showell)
Date: Fri, 29 Jan 2010 10:05:05 +0000
Subject: [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: <1264759505.77.0.991738748905.issue7784@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

I am attaching a new patch that does not add a new element to PyListObject, roughly following a technique that Antoine Pitrou suggested on python-dev.  When I want to lazily avoid a memmove under the new patch, I set the MSB on allocated and store the original ob_item pointer in the new ob_item[-1].

On the advice of Daniel, I ran the new patch against the Unladen benchmark suite.  The results were pretty neutral--never more than a 1% penalty but no significant gains either.  I did not expect to see gains, for the obvious reason that I am improving performance on an operation that folks have been encouraged to work around.  The new patch continues to do well on microbenchmarks. 

The new patch fails one test in test_sys related to the 12 byte garbage collection header.  The failure is definitely introduced by my patch, but I am not sure what it's doing wrong.  All other tests pass.

Because the new code piggybacks on top of of allocated instead of creating a new variable in PyListObject, the new code is a bit more complex than the original patch, which is unfortunate.  There are probably some opportunities for making the new code simpler.

----------
Added file: http://bugs.python.org/file16033/DIFF_NO_EXTRA_MEM

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Fri Jan 29 11:25:58 2010
From: report at bugs.python.org (showell)
Date: Fri, 29 Jan 2010 10:25:58 +0000
Subject: [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: <1264760758.18.0.460064229933.issue7784@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

Ok, found the offending line, now all tests pass.  

The use case where this patch will pay off the most is slicing your way through a list of tasks.  The toy program below gets about a 50x speedup.

	import time

	n = 800000

	lst = []
	for i in range(n):
		lst.append(i)

	t = time.time()
	for i in range(n):
		x = lst[:10]
		del lst[:10]

	print('time = ' + str(time.time() - t))
	print(len(lst))

----------
Added file: http://bugs.python.org/file16034/no_mem_penalty.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Fri Jan 29 11:26:21 2010
From: report at bugs.python.org (showell)
Date: Fri, 29 Jan 2010 10:26:21 +0000
Subject: [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: <1264760781.44.0.813776269582.issue7784@psf.upfronthosting.co.za>


Changes by showell <showell30 at yahoo.com>:


Removed file: http://bugs.python.org/file16033/list_top_no_extra_mem.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

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: [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 12:05:24 2010
From: report at bugs.python.org (TJ Sullivan)
Date: Fri, 29 Jan 2010 11:05:24 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two
	corrupted	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1264763124.48.0.817254878855.issue7437@psf.upfronthosting.co.za>


TJ Sullivan <tjsulli at gmail.com> added the comment:

Install was successful. PLease find the attachment with the test results you asked for. Thank you very much for making the fix to the package installer!!!!

----------
Added file: http://bugs.python.org/file16035/install test results.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7437>
_______________________________________

From report at bugs.python.org  Fri Jan 29 12:26:58 2010
From: report at bugs.python.org (Dan Simmons)
Date: Fri, 29 Jan 2010 11:26:58 +0000
Subject: [issue7803] setup hangs on disk space requirements
In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>
Message-ID: <1264764418.74.0.842010959452.issue7803@psf.upfronthosting.co.za>


Dan Simmons <sentai360 at yahoo.com> added the comment:

I think the beginers guide needs to be updated to let us know what type of download to use. x86-64 or binary. 64 bit works so is that the right one for me. I'm trying to get this graphics.py to work that came with a book. It stops working when I run a module with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7803>
_______________________________________

From report at bugs.python.org  Fri Jan 29 12:47:35 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Jan 2010 11:47:35 +0000
Subject: [issue1681842] splitext of dotfiles,
	incl backwards compat and migration
Message-ID: <1264765655.49.0.462268703779.issue1681842@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If I ever clear all the other issues off my list, I may get a chance to have a closer look at this one :)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1681842>
_______________________________________

From report at bugs.python.org  Fri Jan 29 13:21:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jan 2010 12:21:36 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264767696.33.0.591226516426.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A couple of comments about issue7092_syntax_imports_v3.diff too:
1) in test_copy you remove (k,v), but left the name 'k' even if now it represent the item and not the key;
2) in test_fractions you should probably use self.fail() instead of an assert;
3) on test_ftp you can use two separate lines and remove the ';';
4) in test_pyclbr there's one extra 'f' in the comment in assertHaskey;
5) in test_xml_etree_c you can either leave callable() and catch the warning or use isinstance(x, collections.Callable) instead (there are also a few more places where callable was used too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 14:11:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jan 2010 13:11:01 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1264770661.11.0.696884036231.issue1559298@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Fri Jan 29 14:13:04 2010
From: report at bugs.python.org (Dan Simmons)
Date: Fri, 29 Jan 2010 13:13:04 +0000
Subject: [issue7803] setup hangs on disk space requirements
In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>
Message-ID: <1264770784.06.0.705296285808.issue7803@psf.upfronthosting.co.za>


Changes by Dan Simmons <sentai360 at yahoo.com>:


----------
status: open -> closed

_______________________________________
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: [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: [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 15:05:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 14:05:47 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264773947.66.0.995338603518.issue7624@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 15:07:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 14:07:36 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1264774056.19.0.230938212999.issue7805@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed.

I got a Py3k warning on 2.7 about "unorderable types".

----------
nosy: +flox
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7805>
_______________________________________

From report at bugs.python.org  Fri Jan 29 15:16:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2010 14:16:51 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1264774611.0.0.672121861717.issue1926@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, a test could use Google or gmane (according to the FAQ, nntps is supported: http://gmane.org/faq.php ).
The test should skip gracefully (using the skipTest() API) if the connection fails, so that network errors or service unavailability don't make buildbots go red.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Fri Jan 29 15:25:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 14:25:09 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
	Files"
Message-ID: <1264775109.24.0.230268241341.issue1559298@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Florent is correct. The patch seems to fix regular popen, but popen3 sees problems. I'll see if I can fit this in and have a look.

Also of note is that the other flavors of popen are not tested...at least not in Lib/test/test_popen.py or Lib/test/test_os.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Fri Jan 29 15:29:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 14:29:08 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1264775348.19.0.500700124367.issue1926@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

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: [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 16:37:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 29 Jan 2010 15:37:23 +0000
Subject: [issue7803] setup hangs on disk space requirements
In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>
Message-ID: <1264779443.14.0.749706681175.issue7803@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Dan, there seem to be a number of possible issues in your last two messages.

It's not clear to me what the blinking light is. What type of computer do you have and what is the specific installer and version you tried to run?

Also, what do you mean when you say that it stops working when you run a module? Does the interpreter crash or is there an unhandled exception which causes the application to exit?

----------
nosy: +brian.curtin
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7803>
_______________________________________

From report at bugs.python.org  Fri Jan 29 16:44:10 2010
From: report at bugs.python.org (Dan Simmons)
Date: Fri, 29 Jan 2010 15:44:10 +0000
Subject: [issue7803] setup hangs on disk space requirements
In-Reply-To: <1264779443.14.0.749706681175.issue7803@psf.upfronthosting.co.za>
Message-ID: <645710.53183.qm@web110107.mail.gq1.yahoo.com>


Dan Simmons <sentai360 at yahoo.com> added the comment:

It seemed to work after I restarted it. It was stuck on the process of getting disk space requirements, the computer was processing something but the light on the console that tells you something is being processed was blinking once every second in a obvious loop, When I started over it just processed through it in less than a second. So there was something wrong. I don't know if it was my computer or not.

--- On Fri, 1/29/10, Brian Curtin <report at bugs.python.org> wrote:

From: Brian Curtin <report at bugs.python.org>
Subject: [issue7803] setup hangs on disk space requirements
To: sentai360 at yahoo.com
Date: Friday, January 29, 2010, 3:37 PM

Brian Curtin <curtin at acm.org> added the comment:

Dan, there seem to be a number of possible issues in your last two messages.

It's not clear to me what the blinking light is. What type of computer do you have and what is the specific installer and version you tried to run?

Also, what do you mean when you say that it stops working when you run a module? Does the interpreter crash or is there an unhandled exception which causes the application to exit?

----------
nosy: +brian.curtin
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7803>
_______________________________________

----------
Added file: http://bugs.python.org/file16036/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7803>
_______________________________________
-------------- next part --------------
<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">It seemed to work after I restarted it. It was stuck on the process of getting disk space requirements, the computer was processing something but the light on the console that tells you something is being processed was blinking once every second in a obvious loop, When I started over it just processed through it in less than a second. So there was something wrong. I don't know if it was my computer or not.<BR><BR>--- On <B>Fri, 1/29/10, Brian Curtin <I>&lt;report at bugs.python.org&gt;</I></B> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px"><BR>From: Brian Curtin &lt;report at bugs.python.org&gt;<BR>Subject: [issue7803] setup hangs on disk space requirements<BR>To: sentai360 at yahoo.com<BR>Date: Friday, January 29, 2010, 3:37 PM<BR><BR>
<DIV class=plainMail><BR>Brian Curtin &lt;<A href="http://us.mc1101.mail.yahoo.com/mc/compose?to=curtin at acm.org" ymailto="mailto:curtin at acm.org">curtin at acm.org</A>&gt; added the comment:<BR><BR>Dan, there seem to be a number of possible issues in your last two messages.<BR><BR>It's not clear to me what the blinking light is. What type of computer do you have and what is the specific installer and version you tried to run?<BR><BR>Also, what do you mean when you say that it stops working when you run a module? Does the interpreter crash or is there an unhandled exception which causes the application to exit?<BR><BR>----------<BR>nosy: +brian.curtin<BR>status: closed -&gt; open<BR><BR>_______________________________________<BR>Python tracker &lt;<A href="http://us.mc1101.mail.yahoo.com/mc/compose?to=report at bugs.python.org" ymailto="mailto:report at bugs.python.org">report at bugs.python.org</A>&gt;<BR>&lt;<A href="http://bugs.python.org/issue7803"
 target=_blank>http://bugs.python.org/issue7803</A>&gt;<BR>_______________________________________<BR></DIV></BLOCKQUOTE></td></tr></table><br>

      

From report at bugs.python.org  Fri Jan 29 17:26:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 16:26:12 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264782372.69.0.686488968066.issue7624@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Confirmed with all others "isinstance(..., collections.Hashable)" and similar.

According to the documentation, we might expect the same behavior as for new-style class.

----------
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 18:19:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2010 17:19:08 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264785548.58.0.78981063869.issue7624@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well the fix is easy for old-style classes, since we just have to use hasattr(obj, '__call__') in that case.

----------
keywords: +easy
nosy: +pitrou
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 18:29:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 17:29:34 +0000
Subject: [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: <1264786174.71.0.694817172522.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Perfect!  Applied in r77821 through r77824;  thank you.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Fri Jan 29 18:57:25 2010
From: report at bugs.python.org (showell)
Date: Fri, 29 Jan 2010 17:57:25 +0000
Subject: [issue7782] new test for test_iter.py
In-Reply-To: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>
Message-ID: <1264787845.18.0.627824891442.issue7782@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

Per Ezio's suggestions, I added clearer comments and an assert, and now the attached diff applies to trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file16037/extend_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7782>
_______________________________________

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: [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:35:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jan 2010 18:35:42 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1264790142.49.0.0743028761973.issue3892@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  That's not actually the same timeout.  What that means is that if the startup timeout triggers, then a subsequent test (one that is looking for the results of a client transaction) fails, which contradicts the earlier observation that even if the startup timeout fails then everything else still passes.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Fri Jan 29 19:38:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 18:38:08 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264790288.62.0.993917606985.issue7624@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Wow, critical issue, are you sure?

Here is the patch, with tests.
IMO, the tests may be ported to 3.x.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16038/issue7624_abc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 19:38:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jan 2010 18:38:33 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1264790313.97.0.345071689346.issue3892@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

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: [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  Fri Jan 29 19:45:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 18:45:27 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>


New submission from Florent Xicluna <laxyf at yahoo.fr>:

Patch proposed to fix the refleaks.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file16039/issue7808_bsddb3_refleak.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Fri Jan 29 19:46:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2010 18:46:38 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264790798.3.0.233756966612.issue7624@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"subtype == _InstanceType" can probably be replaced with "subtype is _InstanceType". Otherwise, the patch looks good to me.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 19:48:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jan 2010 18:48:27 +0000
Subject: [issue7782] new test for test_iter.py
In-Reply-To: <1264493526.37.0.587552008343.issue7782@psf.upfronthosting.co.za>
Message-ID: <1264790907.57.0.194893513111.issue7782@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7782>
_______________________________________

From report at bugs.python.org  Fri Jan 29 19:53:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 18:53:01 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264791181.68.0.248068084093.issue7624@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16038/issue7624_abc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 19:53:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 18:53:33 +0000
Subject: [issue7624] isinstance(... ,
	collections.Callable) fails with oldstyle class i nstances
In-Reply-To: <1262546013.12.0.84768475199.issue7624@psf.upfronthosting.co.za>
Message-ID: <1264791213.97.0.588090468082.issue7624@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

fixed

----------
Added file: http://bugs.python.org/file16040/issue7624_abc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7624>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:03:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 19:03:39 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264791819.87.0.845894831267.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The updated patch looks good---thank you!  We're getting there... :)

I'm not sure about the extra 'Operand can be Decimal or int.' in the method docstrings;  this just looks like extra clutter to me.  Rather, I think it would be a surprise worthy of documentation if these methods *didn't* accept int or long;  since they now do (with your patch), I don't think it's really worth mentioning in the docstring.  And it's not quite accurate, either, since these methods should accepts longs as well as ints (and bools, and instances of other subclasses).

Would you be content to remove these from the docstrings?  Or do others monitoring this issue think they should stay?

The extra doctests and test_decimal tests are nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:11:24 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 19:11:24 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264792284.83.0.428800144955.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> copy_sing fixed and documented to have the same behaibour.

Hmm.  Thanks for noticing this:  it looks like Decimal.copy_sign is missing a _convert_other call.  I think that should be fixed in the Decimal class rather than in the Context class (so Context.copy_sign and Decimal.copy_sign should make one _convert_other call each, instead of Context.copy_sign making two calls).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:15:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 19:15:40 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264792540.44.0.973678542855.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thank you for the review and your comments.
Here, the replies.


>
> Amaury review - msg98491
>
> Here is my review of issue7092_syntax_imports_v3.diff:
>
> - test_itertools.py: please replace
>       [tuple([arg[i] if i < len(arg) else None for arg in args])
>        for i in range(max(map(len, args)))]
>   by something more readable (nested for loops for example)

It is the 3.x syntax.
--> No change

> - test_mailbox.py: why doesn't test_support.import_module('rfc822')
>   specify deprecated=True? maybe the module can be imported normally...

Added the "deprecated=True"

> - test_pyclbr.py:   replace self.assertTrue(key in obj) with assertIn()
> - test_wsgiref.py:  replace self.assertTrue(key in h.environ)
> - test_queue.py: test could be identical to the one in py3k.

Thanks
--> Done

> 
> Ezio review - msg98494
> 
> Here's mine about issue7092_check_warnings_v3.diff:
> 
> 1) test_callable should keep testing callable() and the warnings should be caught;

Done

> 2) in test_bsddb3 the problems should be correct in the module if possible and worth it (the module is deprecated);

Ok. I prepare a separate patch to fix bsddb3

> 3) next to the several '# Silence py3k warnings' it would be nice to have a note about what warning you are exactly silencing;
> 4) def test_deprecated_builtin_map -> test_deprecated_builtin_map_with_None, otherwise it seems that map is deprecated;

Done

> 5) in test[_deep]_copy I'm not entirely sure that the tests are equivalent using in (and if they are you should use assertIn);

Will use assertSetEqual, no need to reinvent the wheel

> 6) in test_socket I would keep callable, also shouldn't the raise in the next line raise a warning as well?;

Ok to keep callable. For the next line, I do not see the warning.

> 7)  the self.assertEqual(`u2`, `d2`) in test_userdict could just use repr() instead;

Done

> 8) a few tests in test_weakref should use assert[Not]In instead of assertTrue(x [not] in y).

Done

> 
> Ezio review - msg98507
> 
> A couple of comments about issue7092_syntax_imports_v3.diff too:
> 1) in test_copy you remove (k,v), but left the name 'k' even if now it represent the item and not the key;

Changed 'k'-> 'pair' (like 3.x)

> 2) in test_fractions you should probably use self.fail() instead of an assert;

The surrounding methods use "assert "
--> No change

> 3) on test_ftp you can use two separate lines and remove the ';';

Done

> 4) in test_pyclbr there's one extra 'f' in the comment in assertHaskey;

It is not an extra f. 'iff' = "if and only if" (not obvious for non-English people)

> 5) in test_xml_etree_c you can either leave callable() and catch the warning or use isinstance(x, collections.Callable) instead (there are also a few more places where callable was used too).

It is done this way in 3.x.
I propose to fix it separately (if a fix is required).



Now I prepare the updated patches.
I follow the proposal of Amaury: create a specific "test_support.silence_py3k_warnings()" context manager.
It replaces the "check_warnings" and "filterwarnings" of the proposed patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:17:25 2010
From: report at bugs.python.org (Kaushik Ghose)
Date: Fri, 29 Jan 2010 19:17:25 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1264792645.23.0.437205179048.issue6766@psf.upfronthosting.co.za>


Kaushik Ghose <kghose at users.sf.net> added the comment:

Even with the patch, I can not resolve this problem. I can reproduce the problem with the patched version with the following code. My system is:

Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
IPython 0.10
Platform is Mac OS X (10.5.8) Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009

import multiprocessing as mp

def f(d):
  d['f'] = {}
  d['f']['msg'] = 'I am here'

manager = mp.Manager()
d = manager.dict()

p = mp.Process(target=f, args=(d,))

p.start()
p.join()

print d

d = {}
f(d)

print d

Output:

{'f': {}}
{'f': {'msg': 'I am here'}}

----------
nosy: +kghose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:23:44 2010
From: report at bugs.python.org (Clovis Fabricio)
Date: Fri, 29 Jan 2010 19:23:44 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1264793024.19.0.925836550323.issue5712@psf.upfronthosting.co.za>


Clovis Fabricio <nosklo+python at gmail.com> added the comment:

I've written a quick workaround for the issue, where I manually split the filenames and always return a tuple.

It might be useful to someone experiencing this problem, so I'm adding it to the issue here.

----------
nosy: +nosklo
Added file: http://bugs.python.org/file16041/issue5712_workaround.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:24:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 19:24:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264793048.34.0.998868956573.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16042/issue7269_bsddb3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:24:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 19:24:21 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264793061.13.0.585226874184.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16042/issue7269_bsddb3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:24:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 19:24:40 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264793080.21.0.237460185965.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16043/issue7092_bsddb3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:25:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 19:25:43 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1264793143.93.0.698449628022.issue7808@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7808>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:29:04 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 29 Jan 2010 19:29:04 +0000
Subject: [issue1475523] patch fixing #1448060 (gettext.py bug)
Message-ID: <1264793344.2.0.163744889007.issue1475523@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:30:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 19:30:59 +0000
Subject: [issue7684] decimal.py: infinity coefficients in tuples
In-Reply-To: <1263327517.52.0.041459928833.issue7684@psf.upfronthosting.co.za>
Message-ID: <1264793459.37.0.767150182776.issue7684@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Issue 1: (passing coefficients to decimal constructor):  While I agree that passing a coefficient for an infinity doesn't make a lot of sense, there's a backwards compatibility problem here: it worked in 3.1, so making it raise an exception in 3.2 might break code.  However, it seems unlikely that there's any correct code out there that's passing a coefficient other than (0,) or () for an infinity, so I'd be prepared to make this an error for coefficients other than () and (0,).

Issue 2: (inf.as_tuple() returns () instead of (0,) for coefficient).  On balance I'd prefer to leave this as it is.  It's a minor inconsistency, but I don't think it really does any harm.  Unless there's a real bug, making a minor change like this to an established API seems more likely to do harm than good.  (It could break docstrings in third-party packages, for example.)

----------
nosy: +rhettinger
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7684>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:31:04 2010
From: report at bugs.python.org (showell)
Date: Fri, 29 Jan 2010 19:31:04 +0000
Subject: [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: <1264793464.81.0.653909820286.issue7784@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

I am closing this due to mostly unanimous rejection on python-dev.

If folks reopen this in the future, the last patch that I submitted has been reasonably well tested, but it has not been code reviewed.

The 1% speed penalty could probably be driven down without too much effort, but not totally eliminated.

The constraint not to add a member to PyListObject complicates the code considerably.

In diving deep into listobject.c, I noticed a couple things unrelated to my patch:

  1) There might be a refactoring available for calls to list_resize, where callers just pass in the delta, instead of the new list size.  Lots of the callers do addition that could be pushed into list_resize.  Not sure it would lead to speed ups, but it would probably reduce code size.

  2) The optimistic realloc scheme is probably needlessly wasteful for really large lists.  If you have a million elements, I am not sure you need to allocate 12% extra space, and I think that's what the current algorithm does (untested).

  3) There might be some merit in splitting out list_resize into list_resize_bigger and list_resize_smaller.  I think the callers generally know when they are shrinking/expanding the list, so callers that are shrinking the list could call a leaner method that just shrinks the list without having to execute other instructions.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7784>
_______________________________________

From report at bugs.python.org  Fri Jan 29 20:45:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Jan 2010 19:45:29 +0000
Subject: [issue7684] decimal.py: infinity coefficients in tuples
In-Reply-To: <1263327517.52.0.041459928833.issue7684@psf.upfronthosting.co.za>
Message-ID: <1264794329.85.0.784905046493.issue7684@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I also prefer to leave as-is.  It's harmless.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7684>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:10:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 20:10:53 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264795853.26.0.332927484962.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16044/issue7092_test_support.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:11:45 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 20:11:45 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264795905.69.0.835604512918.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15925/issue7092_json.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:22:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 29 Jan 2010 20:22:25 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264796545.09.0.417557675643.issue7633@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I also think that the added docstrings are not really necessary.

Another thing: I forgot to mention 'canonical' in the list of functions
that should only accept Decimals. As with the other two (number_class
and is_canonical), this is a matter of taste. Personally I would not
expect them to work for integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:25:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 20:25:18 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264796718.55.0.137797652497.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Re: canonical.  Yes, this made me pause for a second, too.  But I don't see the harm in allowing it to accept ints and longs.  Actually, it then provides a nice public version of _convert_other.

I'd probably also allow is_canonical and number_class to accept ints and longs, just on the basis that that gives fewer special cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:33:23 2010
From: report at bugs.python.org (showell)
Date: Fri, 29 Jan 2010 20:33:23 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1264797203.38.0.541478559541.issue7770@psf.upfronthosting.co.za>


showell <showell30 at yahoo.com> added the comment:

+1 on showing off remainder_near.  I recently wrote a program where I reinvented the logic (on a unit circle too), not knowing it was already implemented in Decimal.

----------
nosy: +Steve Howell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:47:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jan 2010 20:47:02 +0000
Subject: [issue3892] bsddb: test01_basic_replication fails sometimes
In-Reply-To: <1221700704.13.0.219533717594.issue3892@psf.upfronthosting.co.za>
Message-ID: <1264798022.6.0.907702818209.issue3892@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since this isn't likely to get fixed and it is causing buildbot instability, I propose the attached patch to just skip the remainder of the test method if this second timeout happens.

----------
keywords: +patch
Added file: http://bugs.python.org/file16045/bsddb3-skip-random-failure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3892>
_______________________________________

From report at bugs.python.org  Fri Jan 29 21:58:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Jan 2010 20:58:02 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1264798682.92.0.338076981055.issue7771@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The 3.2a doc is unchanged (similarly lacking).

The situation is that view have all of the special method (operator methods) that frozen sets do but none of the named methods (.copy to .union). I think it would be helpful if the doc said so. Perhaps change

"Then these set operations are available ..."

to

"For set-like view, all of the syntax operations on sets (but none of the named methods, like set.copy,) are available ..."

I think

dictview < / <= / >= / > other:
 same as corresponding operation with two sets

might be sufficient, but list all four is ok too.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:03:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Jan 2010 21:03:49 +0000
Subject: [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264799029.99.0.648481554391.issue7767@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The proposed addition sounds entirely reasonable to me.

In your patch, is there a reason for leaving out the first PyInt_Check (compare with PyLong_AsLongAndOverflow)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7767>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:07:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 21:07:39 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264799259.1.0.836300025249.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15994/issue7092_syntax_imports_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:07:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 21:07:44 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264799264.25.0.787092464493.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15995/issue7092_check_warnings_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:07:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 21:07:48 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264799268.09.0.375027692357.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15996/issue7092_filterwarnings_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:12:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 21:12:13 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264799533.65.0.0857399572674.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16046/issue7092_test_exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:13:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 21:13:00 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264799580.21.0.956499237436.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16047/issue7092_Wd_warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:14:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 21:14:51 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264799691.49.0.826677905392.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16048/issue7092_syntax_fixes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:15:13 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Jan 2010 21:15:13 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <20100128152826.5b0b280e@neeble>
Message-ID: <4B634FDD.50700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ross Cohen wrote:
> 
> Ross Cohen <rcohen at snurgle.org> added the comment:
> 
> I am confused by this line of reasoning. Is it ok to ignore the
> deprecation process in py3k but not in 2.x? Is it only ok if a core
> developer does it?

It's normally not ok to ignore the deprecation process for 3.x,
since the 3.x branch is in a stable state, just like the 2.x
branch (3.0 and, after some discussions, 3.1 were allowed to
break things).

I don't know why this process wasn't followed for the new GIL
implementation.

It basically breaks compatibility with the other
thread implementations, but does so without actually removing
the support for them in the thread library we're using for
the _thread module.

Perhaps this was simply not known to other developers.

There's also no PEP for the new implementation, which you'd
normally require for any such major change to the internals.

> If the point of 2.7 is to make it easier for apps and packages to be
> ported to py3k, then what would be the point of these platforms moving
> to 2.7 in the first place? It seems perfectly reasonable not to support
> platforms which are never going to care the release. If the platforms
> are broken for 2.7, you'll get that much more warning before 3.2 is
> released so it can be fixed.

Breaking existing applications and ports of Python for 2.7
certainly won't make anything easier for anyone.

For 2.7 we will certainly not allow the above to happen,
since that's the version that's going to be used by most
people for a few years to come.

What we could do for 2.7, is add Py3k deprecation warnings
to the alternative thread implementations, mentioning their
removal in 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:28:33 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 29 Jan 2010 21:28:33 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264800513.3.0.304127707595.issue7092@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <exarkun at divmod.com>:


----------
nosy:  -exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Fri Jan 29 22:47:10 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 29 Jan 2010 21:47:10 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264801630.74.0.930347159441.issue7633@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, indeed 'canonical' can be justified to take an integer, if we interpret the spec as:

'canonical' takes an operand and returns the preferred _decimal_
encoding of that operand.

But then 'is_canonical' should return false for an integer, and
this would create another special case: Accept an operand and
return something meaningful _without_ converting it first.

I think this is why I have problems with those two. 'number_class'
is less of a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Fri Jan 29 23:33:31 2010
From: report at bugs.python.org (Ross Cohen)
Date: Fri, 29 Jan 2010 22:33:31 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <4B634FDD.50700@egenix.com>
Message-ID: <20100129143020.67f0ff65@neeble>


Ross Cohen <rcohen at snurgle.org> added the comment:

On Fri, 29 Jan 2010 21:15:14 +0000
Marc-Andre Lemburg <report at bugs.python.org> wrote:

> Breaking existing applications and ports of Python for 2.7
> certainly won't make anything easier for anyone.
> 
> For 2.7 we will certainly not allow the above to happen,
> since that's the version that's going to be used by most
> people for a few years to come.
> 
> What we could do for 2.7, is add Py3k deprecation warnings
> to the alternative thread implementations, mentioning their
> removal in 3.2.

What if, as you proposed earlier, the patch were to leave the old
behavior if the threading model on the given platform were not
supported?

Ross

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________

From report at bugs.python.org  Sat Jan 30 00:04:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 23:04:18 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264806258.14.0.410424782458.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16049/issue7092_silence_imports.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 00:09:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 23:09:44 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264806584.12.0.43673315066.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16050/issue7092_py3k_warnings_args.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 00:10:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 23:10:17 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264806617.45.0.252979639147.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16051/issue7092_py3k_warnings_noargs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 00:22:05 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 29 Jan 2010 23:22:05 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264807325.5.0.966176495837.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Each patch can be reviewed and committed separately (except the last 2).

[patch 1] bsddb3.diff ? related to Bsddb3
[patch 2] test_support.diff ? new helper "silence_py3k_warnings()"
[patch 3] test_exceptions.diff ? "test_pep352" and "test_exceptions"
[patch 4] Wd_warnings.diff ? fix few "-Wd" warnings
[patch 5] syntax_fixes.diff ? fix syntax only (2to3-like)
[patch 6] silence_imports.diff ? import deprecated modukes


Patches below require the new helper "silence_py3k_warnings" (patch 2)

[patch 7] py3k_warnings_args.diff ? 26 files
[patch 8] py3k_warnings_noargs.diff ? 28 files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 00:43:36 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 29 Jan 2010 23:43:36 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't
	be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1264808616.11.0.323252662101.issue5504@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5504>
_______________________________________

From report at bugs.python.org  Sat Jan 30 01:45:19 2010
From: report at bugs.python.org (=?utf-8?q?Juan_Jos=C3=A9_Conti?=)
Date: Sat, 30 Jan 2010 00:45:19 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1264812319.93.0.39731666233.issue7633@psf.upfronthosting.co.za>


Juan Jos? Conti <jjconti at gmail.com> added the comment:

Yeah... I did't like that docstring either :) Removed!
Also fixed Decimal.copy_sign, changed Context.copy_sign and added tests.

----------
Added file: http://bugs.python.org/file16052/issue7633_jjconti4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Sat Jan 30 03:19:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Jan 2010 02:19:39 +0000
Subject: [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: <1264817979.44.0.865921629842.issue7801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in trunk by r77836 (r77837) and py3k by r77838 (r77839), thanks.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7801>
_______________________________________

From report at bugs.python.org  Sat Jan 30 03:19:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Jan 2010 02:19:50 +0000
Subject: [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: <1264817990.92.0.35795684744.issue7801@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7801>
_______________________________________

From report at bugs.python.org  Sat Jan 30 03:21:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Jan 2010 02:21:27 +0000
Subject: [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: <1264818087.33.0.116805929666.issue7801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: The python3 example closed the file after the return instruction :-( I fixed that by using the with syntax, as does Python trunk example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7801>
_______________________________________

From report at bugs.python.org  Sat Jan 30 05:04:03 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 30 Jan 2010 04:04:03 +0000
Subject: [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264824243.18.0.225731376568.issue7767@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

The missing PyInt_Check is a mistake. I probably thought I was working on a py3k version.

Let me know if I should create a new patch or if I should create one for py3k.

Thanks for the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7767>
_______________________________________

From report at bugs.python.org  Sat Jan 30 05:06:22 2010
From: report at bugs.python.org (Terrence Cole)
Date: Sat, 30 Jan 2010 04:06:22 +0000
Subject: [issue6766] Cannot modify dictionaries inside dictionaries using
	Managers from multiprocessing
In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za>
Message-ID: <1264824382.31.0.719765089694.issue6766@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

Kaushik, in your example, d is a dict proxy, so assignment to d['f'] correctly ferries the assignment (a new normal dict) to the d['f'] in the original process.  The new dict, however, is not a dict proxy, it's just a dict, so assignment of d['f']['msg'] goes nowhere.  All hope is not lost, however, because the Manager can be forked to new processes.  The slightly modified example below shows how this works:

from multiprocessing import Process, Manager
def f(m, d):
    d['f'] = m.dict()
    d['f']['msg'] = 'I am here'

m = Manager()
d = m.dict()
p = Process(target=f, args=(m,d))
p.start()
p.join()
print d
{'f': <DictProxy object, typeid 'dict' at 0x7f1517902810>}
print d['f']
{'msg': 'I am here'}

With the attached patch, the above works as shown, without, it gives the same output as your original example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6766>
_______________________________________

From report at bugs.python.org  Sat Jan 30 05:14:37 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 30 Jan 2010 04:14:37 +0000
Subject: [issue1562308] uninitialized memory read in parsetok()
Message-ID: <1264824877.77.0.0476633629422.issue1562308@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This is the same as 3367, which Benjamin just closed out.

----------
nosy: +benjamin.peterson, minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1562308>
_______________________________________

From report at bugs.python.org  Sat Jan 30 05:17:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 Jan 2010 04:17:40 +0000
Subject: [issue1562308] uninitialized memory read in parsetok()
Message-ID: <1264825060.37.0.478297112113.issue1562308@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1562308>
_______________________________________

From report at bugs.python.org  Sat Jan 30 05:36:20 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 30 Jan 2010 04:36:20 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1264826180.56.0.0618994522462.issue6978@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I think this should be closed out, since the compiler package was deprecated in 2.6.

----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________

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: [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 07:15:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Jan 2010 06:15:16 +0000
Subject: [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: <1264832116.65.0.120988567648.issue7809@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It's already indicated in the documentation for random.seed([x]):
"If x is omitted or None, current system time is used; current system time is also used to initialize the generator when the module is first imported."

----------
nosy: +ezio.melotti
priority:  -> normal
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7809>
_______________________________________

From report at bugs.python.org  Sat Jan 30 07:20:20 2010
From: report at bugs.python.org (Justin Lebar)
Date: Sat, 30 Jan 2010 06:20:20 +0000
Subject: [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: <1264832420.19.0.0487862522816.issue7809@psf.upfronthosting.co.za>


Justin Lebar <starwiz at gmail.com> added the comment:

Ack.  I read it twice looking for that line!

Perhaps it should still indicate that new Random objects are automatically seeded.  And perhaps the line I missed should be a little bit louder?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7809>
_______________________________________

From report at bugs.python.org  Sat Jan 30 08:26:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Jan 2010 07:26:11 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264836371.65.0.804171192981.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Warnings for imports of deprecated modules are now silenced in r77841 (patch 6 / silence_imports.diff).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 08:37:06 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 30 Jan 2010 07:37:06 +0000
Subject: [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: <1264837026.4.0.0880665984935.issue7796@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

For more discussion on this, see http://stackoverflow.com/questions/2166818

----------
components: +Library (Lib)
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Sat Jan 30 09:43:51 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jan 2010 08:43:51 +0000
Subject: [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264841031.71.0.291219948624.issue7767@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ok, great.  I'll add the PyInt_Check back in and commit the patch, then.  I just wanted to check that I wasn't missing something obvious.  Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7767>
_______________________________________

From report at bugs.python.org  Sat Jan 30 11:03:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 10:03:37 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264845817.37.0.550708537243.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16046/issue7092_test_exceptions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 11:07:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 10:07:09 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264846029.94.0.801595190914.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Cleanup test_exceptions:
 - removed "filterwarnings" for "testSlicing"

----------
Added file: http://bugs.python.org/file16053/issue7092_test_exceptions_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 11:21:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 10:21:49 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264846909.53.0.955887300355.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16049/issue7092_silence_imports.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

From report at bugs.python.org  Sat Jan 30 11:31:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jan 2010 10:31:15 +0000
Subject: [issue7767] Add PyLong_AsLongLongAndOverflow
In-Reply-To: <1264295809.05.0.812377605004.issue7767@psf.upfronthosting.co.za>
Message-ID: <1264847475.85.0.784566004058.issue7767@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r77842 (trunk), r77843 (py3k).

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7767>
_______________________________________

From report at bugs.python.org  Sat Jan 30 11:38:36 2010
From: report at bugs.python.org (Sami Zerrade)
Date: Sat, 30 Jan 2010 10:38:36 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1264847916.58.0.40818664695.issue7567@psf.upfronthosting.co.za>


Sami Zerrade <szerrade at gmail.com> added the comment:

This is being caused by the following 2 new lines in the initscr() function of Lib/curses/__init__.py:


setupterm(term=_os.environ.get("TERM", "unknown"),
            fd=_sys.__stdout__.fileno())

Commenting them out will cause the behavior from version 2.5.  


In general, invoking the C curses library's setupterm() function after the C initscr() function has been called will cause the terminal to break the next time that endwin() is called.  In this particular case, the first call to the Python initscr() function provides the call to the C initscr() and the second call to Python's initscr() provides the call to setupterm().  The bug can be fixed by having the Python initscr() function in __init__.py make sure that initscr hasn't been called before making the call to setupterm().

----------
nosy: +Sami.Zerrade

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Sat Jan 30 12:27:19 2010
From: report at bugs.python.org (Sami Zerrade)
Date: Sat, 30 Jan 2010 11:27:19 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1264850839.43.0.584393022155.issue7567@psf.upfronthosting.co.za>


Sami Zerrade <szerrade at gmail.com> added the comment:

I'm attaching a file that patches Modules/_cursesmodule.c to make sure that initscr hasn't been called before invoking setupterm().  This fixes the bug for me; your mileage may vary.

----------
keywords: +patch
Added file: http://bugs.python.org/file16054/setupterm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Sat Jan 30 12:35:22 2010
From: report at bugs.python.org (Sami Zerrade)
Date: Sat, 30 Jan 2010 11:35:22 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1264851322.16.0.201359766898.issue7567@psf.upfronthosting.co.za>


Changes by Sami Zerrade <szerrade at gmail.com>:


Removed file: http://bugs.python.org/file16054/setupterm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Sat Jan 30 12:37:52 2010
From: report at bugs.python.org (Sami Zerrade)
Date: Sat, 30 Jan 2010 11:37:52 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1264851472.78.0.122072685252.issue7567@psf.upfronthosting.co.za>


Changes by Sami Zerrade <szerrade at gmail.com>:


Added file: http://bugs.python.org/file16055/setupterm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

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: [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 14:06:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jan 2010 13:06:52 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1264856812.31.0.858316103101.issue7544@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I didn't test the patch but some comments:
- PyThreadState_Prealloc and PyThreadState_Init should probably be prefixed with an underscore, because there's no use for them outside of the interpreter
- _PyThreadState_New should be static. Besides, static functions usually don't get the "Py" in their name and are all lowercased, so something like "new_threadstate"
- the last change ("Py_InitializeEx() calls _PyGILState_Init() before initsite()") should be part of a separate patch (and issue?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

From report at bugs.python.org  Sat Jan 30 14:07:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jan 2010 13:07:55 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1264856875.44.0.763675920233.issue7544@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, and besides, you can use the -R option to regrtest to find out if there are any reference leaks (e.g. "-R 3:2:").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7544>
_______________________________________

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: [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:29 2010
From: report at bugs.python.org (Peter Hansen)
Date: Sat, 30 Jan 2010 15:54:29 +0000
Subject: [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:57:44 2010
From: report at bugs.python.org (Peter Hansen)
Date: Sat, 30 Jan 2010 15:57:44 +0000
Subject: [issue7812] Call to gestalt('sysu') on OSX can lead to freeze in
	wxPython apps
In-Reply-To: <1264867064.8.0.669245922526.issue7812@psf.upfronthosting.co.za>
Message-ID: <1264867064.8.0.669245922526.issue7812@psf.upfronthosting.co.za>


New submission from Peter Hansen <peter at engcorp.com>:

In platform.mac_ver() there is a call to look up Mac version info, which results in a call to gestalt.gestalt('sysu').  This call is useless since, as documented in comments in the function the "sysu" option no longer exists, but the call was left in "as documentation".  

Unfortunately, as described in http://groups.google.com/group/wxpython-users/browse_thread/thread/ced6c57cc84cb252 this call has the unfortunate and mysterious (but conclusively proven) side effect of preventing a wxPython app from running the GUI main loop in any thread other than the main thread (or rather, the one in which this failing call to gestalt() is first made).

See also http://bugs.python.org/issue780461 for some related background.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
title: Call to gestalt('sysu') on -> Call to gestalt('sysu') on OSX can lead to freeze in wxPython apps

_______________________________________
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: [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:00:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Jan 2010 16:00:22 +0000
Subject: [issue7812] Call to gestalt('sysu') on OSX can lead to freeze in
	wxPython apps
In-Reply-To: <1264867064.8.0.669245922526.issue7812@psf.upfronthosting.co.za>
Message-ID: <1264867222.03.0.0899367271082.issue7812@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7812>
_______________________________________

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: [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 17:33:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Jan 2010 16:33:02 +0000
Subject: [issue7567] Messed up terminal after calling curses.initscr() twice.
In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za>
Message-ID: <1264869182.23.0.153181730014.issue7567@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7567>
_______________________________________

From report at bugs.python.org  Sat Jan 30 17:36:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 Jan 2010 16:36:10 +0000
Subject: [issue7810] fix_callable breakage
In-Reply-To: <1264856023.16.0.865675766394.issue7810@psf.upfronthosting.co.za>
Message-ID: <1264869370.25.0.606414698706.issue7810@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This should be fixed as of r77855 and r77856.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7810>
_______________________________________

From report at bugs.python.org  Sat Jan 30 17:47:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Jan 2010 16:47:25 +0000
Subject: [issue7813] Bug in command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1264870045.37.0.814703000572.issue7813@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This fails on 2.6 maint but works on trunk.  There have been several improvements to the way that that compile works in trunk, and one of those fixed the problem that you are seeing.  The source of the problem is the final line in the source file containing nothing but whitespace.  I can't find the bug/revision that fixed this, but I suspect it depends on issue 7468, which Benjamin says is not a backport candidate.  

Since the limitation on compile on 2.6 is documented (see issue 4262), this would be considered a runpy bug if someone was moved to fix it in 2.6.

----------
nosy: +benjamin.peterson, ncoghlan, r.david.murray
priority:  -> low
stage:  -> test needed
title: Bug of command-line module launcher -> Bug in command-line module launcher
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7813>
_______________________________________

From report at bugs.python.org  Sat Jan 30 18:54:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jan 2010 17:54:25 +0000
Subject: [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: <1264874065.0.0.00133320441328.issue7814@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r77857.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7814>
_______________________________________

From report at bugs.python.org  Sat Jan 30 18:57:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jan 2010 17:57:56 +0000
Subject: [issue7802] socket.gaierror before ProtocolError for xmlrpc.client
In-Reply-To: <1264727901.97.0.79188131386.issue7802@psf.upfronthosting.co.za>
Message-ID: <1264874276.3.0.130333332363.issue7802@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, that example was indeed wrong.  ProtocolError is not meant to be raised if the HTTP connection to the specified URI can't even be made, e.g. for unknown hosts.  Fixed in r77858.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7802>
_______________________________________

From report at bugs.python.org  Sat Jan 30 18:59:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jan 2010 17:59:10 +0000
Subject: [issue7798] document pydoc methods
In-Reply-To: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za>
Message-ID: <1264874350.83.0.092024573905.issue7798@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Very likely, these functions are not meant to be anything but utilities.  As API functions, they also don't belong into pydoc.

----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7798>
_______________________________________

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: [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  Sat Jan 30 19:25:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jan 2010 18:25:09 +0000
Subject: [issue7733] asyncore docs reference is unclear
In-Reply-To: <1263817956.14.0.104959185051.issue7733@psf.upfronthosting.co.za>
Message-ID: <1264875909.11.0.472772627937.issue7733@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Would you like to contribute a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7733>
_______________________________________

From report at bugs.python.org  Sat Jan 30 19:35:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Jan 2010 18:35:53 +0000
Subject: [issue7815] Regression in unittest traceback formating extensibility
In-Reply-To: <1264874450.07.0.188014948494.issue7815@psf.upfronthosting.co.za>
Message-ID: <1264876553.9.0.617214111088.issue7815@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin, michael.foord
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7815>
_______________________________________

From report at bugs.python.org  Sat Jan 30 21:15:04 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 30 Jan 2010 20:15:04 +0000
Subject: [issue7813] Bug in command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1264882504.73.0.792590056032.issue7813@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, I guess in these conditions this bugs doesn't require a patch B-)
Thanks for the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7813>
_______________________________________

From report at bugs.python.org  Sat Jan 30 21:32:59 2010
From: report at bugs.python.org (Robin Dunn)
Date: Sat, 30 Jan 2010 20:32:59 +0000
Subject: [issue7812] Call to gestalt('sysu') on OSX can lead to freeze in
	wxPython apps
In-Reply-To: <1264867064.8.0.669245922526.issue7812@psf.upfronthosting.co.za>
Message-ID: <1264883579.93.0.274890979188.issue7812@psf.upfronthosting.co.za>


Changes by Robin Dunn <robin at alldunn.com>:


----------
nosy: +robind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7812>
_______________________________________

From report at bugs.python.org  Sat Jan 30 22:26:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Jan 2010 21:26:57 +0000
Subject: [issue5484] subprocess.call() fails for .bat files on Windows,
	if executable path contains parenthesis
In-Reply-To: <1236954727.06.0.0825252452212.issue5484@psf.upfronthosting.co.za>
Message-ID: <1264886817.78.0.995378323591.issue5484@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not seeing the same thing Tim sees on 2.6, or 3.1 for that matter. Looks like this is still an issue.

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 3.1 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5484>
_______________________________________

From report at bugs.python.org  Sat Jan 30 23:24:47 2010
From: report at bugs.python.org (pmpp)
Date: Sat, 30 Jan 2010 22:24:47 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1264890287.05.0.678110211327.issue5677@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

related:
	f=open('test','w+b')
	f.write('123456789ABCDEF')
	#f.seek(0)
	print "position",f.tell()
	print '[',len(f.read()),']'
	f.close()

windows: 2.6.2 mingw/ 2.6.4 msvc builds
len(f.read()) > 0   ( 4081 when i did the test ) but should be 0
printing the buffer show binary garbage.

linux is ok f.read() return '' as expected

----------
nosy: +pmpp
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________

From report at bugs.python.org  Sat Jan 30 23:39:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 22:39:04 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1264891144.12.0.721526330596.issue7385@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Proposed test and fix.
Please comment, there's probably room for improvement.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16058/issue7385_memoryview.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7385>
_______________________________________

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: [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 00:22:00 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 23:22:00 +0000
Subject: [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1264893720.2.0.790136775647.issue7816@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file16059/issue7816_test_capi.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7816>
_______________________________________

From report at bugs.python.org  Sun Jan 31 00:23:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 23:23:49 +0000
Subject: [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1264893829.71.0.693955762829.issue7816@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7816>
_______________________________________

From report at bugs.python.org  Sun Jan 31 00:31:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 Jan 2010 23:31:32 +0000
Subject: [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1264894292.87.0.655941719785.issue7816@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Should be fixed in r77867.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7816>
_______________________________________

From report at bugs.python.org  Sun Jan 31 00:40:21 2010
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 30 Jan 2010 23:40:21 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1264894821.86.0.655015799362.issue5677@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

It seems like this is actually a problem in Windows libc or something (tested using MinGW on Windows XP):

#include <stdio.h>

main() {
    FILE *f = fopen("test", "wb");
    fwrite("test", 1, 4, f);
    char buf[2048];
    size_t k = fread(buf, 1, 2048, f);
    printf("%d\n", k);
    int i=0;
    for(; i<k; i++) printf("%02x", buf[i]);
}

This causes a lot of garbage to be printed out. Removing the fwrite causes "0" to be printed with no further output.

The garbage is not from the uninitialized buffer, since I've verified that the original contents of the buffer are not what is being printed out. Furthermore, adjusting 2048 produces a maximum output of 4092 bytes (even with 9999 in place of 2048).

Short of simply denying read() on writable files, I don't really see an easy way around this libc bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________

From report at bugs.python.org  Sun Jan 31 00:41:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 23:41:47 +0000
Subject: [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1264894907.48.0.0327282026975.issue7816@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16059/issue7816_test_capi.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7816>
_______________________________________

From report at bugs.python.org  Sun Jan 31 00:52:39 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 23:52:39 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1264895559.88.0.242989552398.issue7385@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16058/issue7385_memoryview.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7385>
_______________________________________

From report at bugs.python.org  Sun Jan 31 00:53:03 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 30 Jan 2010 23:53:03 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1264895583.52.0.919796408805.issue7385@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Removed /* XXX */ code

----------
Added file: http://bugs.python.org/file16060/issue7385_memoryview.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7385>
_______________________________________

From report at bugs.python.org  Sun Jan 31 01:27:32 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 31 Jan 2010 00:27:32 +0000
Subject: [issue6899] Base.replace breaks tree
In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
Message-ID: <1264897652.84.0.155406504312.issue6899@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I updated the patch with a few unit tests:

euclid:trunk minge$ ./python.exe Lib/test/test_lib2to3.py

...

======================================================================
FAIL: test_replace (lib2to3.tests.test_pytree.TestNodes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/minge/Research/Languages/python/trunk/Lib/lib2to3/tests/test_pytree.py", line 161, in test_replace
    self.assertEqual(l2.parent, n1)
AssertionError: None != Node(1000, [Leaf(100, 'foo'), Leaf(100, '+'), Leaf(100, 'bar')])

======================================================================
FAIL: test_replace_with_list (lib2to3.tests.test_pytree.TestNodes)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/minge/Research/Languages/python/trunk/Lib/lib2to3/tests/test_pytree.py", line 179, in test_replace_with_list
    self.assertEqual(l1.parent, n1)
AssertionError: None != Node(1000, [Leaf(100, 'foo'), Leaf(100, '+'), Leaf(100, 'baz'), Leaf(100, '*'), Leaf(100, '*'), Leaf(100, 'bar')])

----------------------------------------------------------------------
Ran 541 tests in 19.328s

FAILED (failures=2)

...

euclid:trunk minge$ patch -p0 < python.patch 
patching file Lib/lib2to3/pytree.py
Hunk #1 succeeded at 132 (offset 2 lines).
Hunk #2 succeeded at 151 (offset 2 lines).

euclid:trunk minge$ ./python.exe Lib/test/test_lib2to3.py

...

----------------------------------------------------------------------
Ran 541 tests in 19.642s

OK

----------
nosy: +minge
Added file: http://bugs.python.org/file16061/issue-6899.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6899>
_______________________________________

From report at bugs.python.org  Sun Jan 31 02:20:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 01:20:47 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1264900847.75.0.489633118286.issue7173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce the crash. Can someone write a shorter code reproducing the issue? I downloaded Cython tip and applied the patch attached to this issue.

I tried py3k, py3k compiled in pydebug mode, python 3.1 branch: none crashed. Should I clear generated files before running a new test? If yes, how?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Jan 31 02:35:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 01:35:30 +0000
Subject: [issue3194] Demo/loop.c passing "char *" instead of "wchar_t *"
In-Reply-To: <1214364326.35.0.217778159942.issue3194@psf.upfronthosting.co.za>
Message-ID: <1264901730.3.0.774786551553.issue3194@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

loop demo is still broken in py3k:
 * try to link to libpython3.0 (wrong python version)
 * there is still the argv[0] type issue

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3194>
_______________________________________

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: [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 02:45:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 01:45:55 +0000
Subject: [issue4340] xmlrpc.client - default 'SlowParser' not defined
In-Reply-To: <1226955359.62.0.344103118813.issue4340@psf.upfronthosting.co.za>
Message-ID: <1264902355.54.0.251858360429.issue4340@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce the bug on py3k nor python3.1. Reopen the issue if the bug reappears.

----------
nosy: +haypo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4340>
_______________________________________

From report at bugs.python.org  Sun Jan 31 02:46:27 2010
From: report at bugs.python.org (Dan)
Date: Sun, 31 Jan 2010 01:46:27 +0000
Subject: [issue7817] Pythonw.exe fails to start
In-Reply-To: <1264902297.56.0.0341617742607.issue7817@psf.upfronthosting.co.za>
Message-ID: <1264902387.45.0.323595994515.issue7817@psf.upfronthosting.co.za>


Dan <10equals8 at gmail.com> added the comment:

I forgot to mention that this is with a brand new install of Python 3.1.1, and a complete uninstall / reinstall did nothing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7817>
_______________________________________

From report at bugs.python.org  Sun Jan 31 03:05:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 02:05:45 +0000
Subject: [issue6409] 2to3 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1264903545.71.0.716613179618.issue6409@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm able to reproduce the bug. The problem is that "-j 4" option creates 4 working processes, and they are all writing to stdout at the same time.

Main process: main() => refactor() => refactor_file() sends tasks to child processes
Children: _child() => queue.get ~> refactor_file() => processed_file() => print_output() writes the diff to stdout using print()

A solution would be to use a lock to ensure that only one process is writing to stdout at the same time... But we may loose all advantages of using different Python processes, it's a new kind of GIL :)

A better solution would be to send output (the whole diff for one file) to the main process which will be the only process writing the stdout. I don't know multiprocessing enough to propose a patch.

Note: flush() in each child process doesn't ensure that no process is writing to stdout at the same time.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________

From report at bugs.python.org  Sun Jan 31 03:24:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 02:24:35 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1264904675.38.0.760135055939.issue7165@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

antoine's patch (fixing this issue) is commited. Can we close this issue?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

From report at bugs.python.org  Sun Jan 31 03:29:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 02:29:25 +0000
Subject: [issue7708] test_xmlrpc fails with non-ascii path
In-Reply-To: <1263576038.96.0.565214554799.issue7708@psf.upfronthosting.co.za>
Message-ID: <1264904965.21.0.939501338049.issue7708@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is a duplicate of #7606.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7708>
_______________________________________

From report at bugs.python.org  Sun Jan 31 03:31:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 02:31:07 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1264905067.69.0.975184416221.issue7606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#7608 was a duplicate issue. Copy of my message (msg98091):
-----
SimpleXMLRPCRequestHandler.do_POST() writes the traceback in the HTTP header "X-traceback". But an HTTP header value is ASCII only, whereas a traceback can contain any character (eg. an non-ASCII character from a directory name for this issue).

A simple fix would be to use the ASCII charset with the backslashreplace error handler. Attached patch uses:

   trace = str(trace.encode('ASCII', 'backslashreplace'), 'ASCII')

Is there an easier method to escape non-ASCII characters without double conversion (unicode->bytes and bytes->unicode)?
-----
I also copied my patch to this issue.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16063/xmlrpc_server_ascii_traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Sun Jan 31 03:31:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 02:31:19 +0000
Subject: [issue7708] test_xmlrpc fails with non-ascii path
In-Reply-To: <1263576038.96.0.565214554799.issue7708@psf.upfronthosting.co.za>
Message-ID: <1264905079.59.0.225890396416.issue7708@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7708>
_______________________________________

From report at bugs.python.org  Sun Jan 31 03:39:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 02:39:28 +0000
Subject: [issue7606] test_xmlrpc fails with non-ascii path
In-Reply-To: <1262209596.84.0.138157640556.issue7606@psf.upfronthosting.co.za>
Message-ID: <1264905568.85.0.674534112129.issue7606@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pitrou> If it's only about transmitting the string representation of the
pitrou> traceback, perhaps we can simply use "replace" or "ignore" as the error
pitrou> handler?

Both replace and ignore loose information. My patch keeps all information by using backslashreplace. It's consistent with Python behaviour: Python writes a backtrace to stderr which uses also the backslashreplace error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7606>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:06:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 Jan 2010 03:06:08 +0000
Subject: [issue7813] Bug in command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1264907168.36.0.5015637139.issue7813@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I meant issue 7268 in my previous message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7813>
_______________________________________

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: [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:13:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:13:31 +0000
Subject: [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: <1264907611.08.0.266495102344.issue7818@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Interpreter Core
type:  -> crash
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7818>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:15:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 31 Jan 2010 03:15:41 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264907741.58.0.813253325223.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch for bsddb3 looks good, however there's no reason (IMHO) to keep in the tests those "if sys.version_info[0] < 3:" or replace the version with (2,6) since we are already using things like assertIn that are 2.7-only. I changed it only to avoid warnings, and left it unchanged in other places (not related to this issue) and in dbtables.py (to preserve compatibility in the unlikely case that someone wants to try running 2.7's bsddb with older versions of Python).
Attached a new patch.

----------
Added file: http://bugs.python.org/file16065/issue7092_bsddb3v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7092>
_______________________________________

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: [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: [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 04:27:14 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 03:27:14 +0000
Subject: [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: <1264908434.46.0.584471632063.issue7818@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7818>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:29:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 03:29:00 +0000
Subject: [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: <1264908540.38.0.0342876555511.issue7820@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Are there test cases for this?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:35:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Jan 2010 03:35:15 +0000
Subject: [issue7813] Bug in command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1264908915.63.0.879095486856.issue7813@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Since import and direct execution will cope with files that don't end with a blank line, changing the first argument to "source + '\n'" in the pkgutil compile call seems like a reasonable workaround for the limitation in the 2.6 compile function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7813>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:44:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:44:33 +0000
Subject: [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: <1264909473.59.0.838833558315.issue7820@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file16068/parser_restore_bom-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:44:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:44:36 +0000
Subject: [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: <1264909476.69.0.351959347224.issue7820@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed 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 04:44:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:44:49 +0000
Subject: [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: <1264909489.85.0.458356738674.issue7820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Are there test cases for this?

Here you have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Jan 31 04:52:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 03:52:41 +0000
Subject: [issue7819] sys.call_tracing(): check arguments type
In-Reply-To: <1264907810.16.0.644202807752.issue7819@psf.upfronthosting.co.za>
Message-ID: <1264909961.0.0.132404902093.issue7819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Before someone is asking, i wrote a new version of my patch using an unit test. The patch also test sys.call_tracing() with valid arguments.

----------
Added file: http://bugs.python.org/file16069/sys_call_tracing-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7819>
_______________________________________

From report at bugs.python.org  Sun Jan 31 05:26:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Jan 2010 04:26:25 +0000
Subject: [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: <1264911985.45.0.355411501457.issue7818@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will think about this.  The method was supposed to be for internal use only.  May just rename it to _test_c_api() and add a docstring noting that it is only defined for "abc".  

That being said, it may be worthwhile to build-out the test to accept many different possible inputs and possibly do a more thorough exercised of possible inputs and outputs to C functions.

----------
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7818>
_______________________________________

From report at bugs.python.org  Sun Jan 31 05:36:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Jan 2010 04:36:33 +0000
Subject: [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: <1264912593.04.0.341671036223.issue7809@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ISTM, the docs are fine in this regard.  The very long history of this module suggests that this is not a recurring point of confusion.

----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7809>
_______________________________________

From report at bugs.python.org  Sun Jan 31 07:23:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Jan 2010 06:23:13 +0000
Subject: [issue7817] Pythonw.exe fails to start
In-Reply-To: <1264902297.56.0.0341617742607.issue7817@psf.upfronthosting.co.za>
Message-ID: <1264918993.51.0.51036672821.issue7817@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you think this is a bug? It's the whole point of pythonw.exe to not open any window.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7817>
_______________________________________

From report at bugs.python.org  Sun Jan 31 07:24:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Jan 2010 06:24:20 +0000
Subject: [issue7165] xmlrpc.server assumes sys.stdout will have a buffer
	attribute
In-Reply-To: <1255869649.48.0.335653342383.issue7165@psf.upfronthosting.co.za>
Message-ID: <1264919060.3.0.0204860796268.issue7165@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7165>
_______________________________________

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: [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 08:39:09 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Jan 2010 07:39:09 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1264923549.44.0.708477709826.issue7173@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Looks like this is one of those bugs that run away when you look too close...

I can get it to crash reliably for me with the latest py3k branch (and all Python 3.x release versions) when I run the test suite completely, so here's a new recipe. The intention is to keep CPython from importing Cython built modules to make sure it's not related to the C code that Cython generates. I thought it was when I hit this problem ages ago (1 or 2 years?), but I can now assure you, it's not. To reproduce, run:

    python3.2 runtests.py --no-cpp --no-pyregr --no-doctest \
          --no-fork --cython-only --no-refnanny -vv 'run\.'

The "--cython-only" switch makes sure the modules are not run through the C compiler, so no binary modules are built and only the pure Python code of the Cython compiler runs here. The output is a little badly formatted, but it basically prints the name of the modules it compiles and crashes after a while (also without the patch).

You don't have to do anything for cleanup, the test runner does that.

Writing a shorter code snippet is really not easy as there seem to be various things involved here, apparently including exception handling, recursion and generators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Jan 31 10:50:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Jan 2010 09:50:06 +0000
Subject: [issue7821] Command line option -U not documented
In-Reply-To: <1264919490.48.0.0177386547442.issue7821@psf.upfronthosting.co.za>
Message-ID: <1264931406.4.0.928389908325.issue7821@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This switch is intentionally not documented.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7821>
_______________________________________

From report at bugs.python.org  Sun Jan 31 12:09:17 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 31 Jan 2010 11:09:17 +0000
Subject: [issue7821] Command line option -U not documented
In-Reply-To: <1264919490.48.0.0177386547442.issue7821@psf.upfronthosting.co.za>
Message-ID: <1264936157.73.0.201964139478.issue7821@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

If the switch is intentionally not documented, perhaps it should be removed from here:

http://docs.python.org/using/cmdline.html#command-line

where it is listed but not explained anywhere. As it stands now, the *existence* of the switch is documented, but not the purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7821>
_______________________________________

From report at bugs.python.org  Sun Jan 31 13:39:05 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Jan 2010 12:39:05 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1264941545.53.0.244287005925.issue7173@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I'll add a couple of comments about the relevant parts of the code that appears to trigger the crash.

The code runs through the parse tree and applies transformations to it.

1) For node matching, we use a dispatcher (in Visitor.py) that looks up methods for node class names (or the nearest matching class in its MRO hierarchy), e.g. a plain "Node" type would be handled by a "visit_Node" method, whereas an ExprNode(Node) type would match "visit_ExprNode" if it exists and "visit_Node" otherwise. The handler then recursively calls back into the dispatch code to visit its children.

For performance reasons, we sometimes reuse existing methods for this through assignment, e.g. instead of reimplementing the default fallback "visit_Node" all over the place, we assign an existing superclass method to it as in "visit_Node = VisitorTransform.recurse_to_children". This may or may not have an impact on this problem (it shouldn't - normally).

So far, all of this appears to work perfectly fine also in Py3. It's the next step that seems to be required to trigger the crash.

2) To specify assertions in our test suite, we use an XPath-like language for node tests (poor man's Schematron, sort-of). The implementation in TreePath.py (based on "ElementPath" in ElementTree 1.3) makes heavy use of generators to traverse the tree. It is used by the TreeAssertVisitor in TestUtils.py, which is itself a recursive tree visitor (as described above).

So the situation is as follows. Cython traverses the parse tree recursively, several times in a pipeline, dispatching to methods that further recurse into the tree. One of the pipeline steps is the tree assertion visitor, which, on matching functions, applies the generator-based path language to the tree, that tries to find nodes by iterating over a chain of generators.

At some point in this process, somehow, sys.exc_info gets corrupted, and the doctest/unittest framework crashes the runtime with a segfault when trying to print an exception (raised unexpectedly by the "pure" test).

I hope this makes it clearer a) what happens and b) why it's not easy to cut this down into a simple test case. As the previous comments show, it's already hard enough to reproduce it reliably with a reduced test setup.

Please do not hesitate to contact me if you need any further information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Sun Jan 31 13:43:22 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Sun, 31 Jan 2010 12:43:22 +0000
Subject: [issue7733] asyncore docs reference is unclear
In-Reply-To: <1263817956.14.0.104959185051.issue7733@psf.upfronthosting.co.za>
Message-ID: <1264941802.74.0.586770791094.issue7733@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Yeah, I'll get to it. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7733>
_______________________________________

From report at bugs.python.org  Sun Jan 31 14:17:39 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 31 Jan 2010 13:17:39 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1264943859.96.0.419691478536.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I wonder if this is technically a bug. The stream is not opened for reading and yet you do an fread. I quickly glanced through the
C-Standard and I did not find an _explicit_ paragraph that this is
undefined behavior, but personally I'd expect it to be.

Regarding the last C example. Also here, you do not open using "w+".
Now, even if you used "w+", by the standard you'd have to do an fflush,
fseek, fsetpos or rewind before reading. I don't see a libc bug.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________

From report at bugs.python.org  Sun Jan 31 15:24:10 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 31 Jan 2010 14:24:10 +0000
Subject: [issue5077] 2to3 fixer for the removal of operator functions
In-Reply-To: <1233036818.57.0.126807970128.issue5077@psf.upfronthosting.co.za>
Message-ID: <1264947850.73.0.995361665124.issue5077@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Attached an updated patch with:
  (1) The two review issues fixed.
  (2) Merged the functionality of the initial patch into the existing
      fixer in 'Lib/lib2to3/fixes/fix_operator.py' + a little 
      refactoring.
  (3) Added matching test cases.
  (4) Updated the documentation.

----------
keywords: +patch
nosy: +minge
Added file: http://bugs.python.org/file16070/issue-5077.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5077>
_______________________________________

From report at bugs.python.org  Sun Jan 31 15:59:22 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 31 Jan 2010 14:59:22 +0000
Subject: [issue5664] 2to3 wont convert Cookie.Cookie properly
In-Reply-To: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za>
Message-ID: <1264949962.87.0.250095184645.issue5664@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

There is already a fixer for this in 'Lib/lib2to3/fixes/fix_imports.py'.  It was merged to the trunk in r64286.

----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5664>
_______________________________________

From report at bugs.python.org  Sun Jan 31 16:17:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Jan 2010 15:17:53 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1264951073.65.0.00860322776223.issue4709@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now tried reproducing the problem, and still failed to. I downloaded, from http://sourceforge.net/projects/mingw-w64/files/, the distribution mingw-w32-bin_i686-mingw_20100123_sezero.zip.

With this, I get

c:\cygwin\mingw64\bin\gcc.exe -mno-cygwin -shared -s build\temp.win-amd64-2.6\Release\w64test.o build\temp.win-amd64-2.6\Release\w64test.def -LC:\Python26\libs -LC:\Python26\PCbuild\amd64 -lpython26 -lmsvcr90 -o build\lib.win-amd64-2.6\w64test.pyd
c:/cygwin/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.4.3/../../../../x86_64-w64
-mingw32/bin/ld.exe: cannot find -lmsvcr90
collect2: ld returned 1 exit status 

How am I supposed to link with this toolchain? If linking with -lmscvr90 is incorrect, what should I use instead? If it is correct, where do I get the proper import library from?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Sun Jan 31 16:22:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 31 Jan 2010 15:22:31 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1264951351.39.0.743107148991.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Bug or not, this can be handled since fread sets EBADF on Windows.

----------
keywords: +patch
Added file: http://bugs.python.org/file16071/fileread-errno.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________

From report at bugs.python.org  Sun Jan 31 16:51:59 2010
From: report at bugs.python.org (Dan)
Date: Sun, 31 Jan 2010 15:51:59 +0000
Subject: [issue7817] Pythonw.exe fails to start
In-Reply-To: <1264902297.56.0.0341617742607.issue7817@psf.upfronthosting.co.za>
Message-ID: <1264953119.53.0.451121408647.issue7817@psf.upfronthosting.co.za>


Dan <10equals8 at gmail.com> added the comment:

Well now I feel really dumb.  I was under the impression that pythonw.exe was a GUI version of python.exe, which I though was console-only since up until now I had only tried running it from the command prompt.  Problem solved, thanks for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7817>
_______________________________________

From report at bugs.python.org  Sun Jan 31 16:59:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 Jan 2010 15:59:44 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1264953584.99.0.624986252738.issue7749@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> pydoc doesn't work from the command line

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7749>
_______________________________________

From report at bugs.python.org  Sun Jan 31 17:01:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 Jan 2010 16:01:05 +0000
Subject: [issue7817] Pythonw.exe fails to start
In-Reply-To: <1264902297.56.0.0341617742607.issue7817@psf.upfronthosting.co.za>
Message-ID: <1264953665.18.0.208180104045.issue7817@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7817>
_______________________________________

From report at bugs.python.org  Sun Jan 31 17:04:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 31 Jan 2010 16:04:16 +0000
Subject: [issue7328] pydoc doesn't work from the command line
In-Reply-To: <1258295679.52.0.0670175954257.issue7328@psf.upfronthosting.co.za>
Message-ID: <1264953856.81.0.937594322417.issue7328@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7328>
_______________________________________

From report at bugs.python.org  Sun Jan 31 17:18:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Jan 2010 16:18:51 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1264954731.78.0.606081367833.issue5677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch should come with a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5677>
_______________________________________

From report at bugs.python.org  Sun Jan 31 17:20:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 31 Jan 2010 16:20:21 +0000
Subject: [issue3020] doctest should have lib2to3 integration
In-Reply-To: <1212331047.91.0.677781535819.issue3020@psf.upfronthosting.co.za>
Message-ID: <1264954821.22.0.778832564982.issue3020@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3020>
_______________________________________

From report at bugs.python.org  Sun Jan 31 17:20:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 31 Jan 2010 16:20:26 +0000
Subject: [issue5616] Distutils 2to3 support doesn't have the doctest_only flag.
In-Reply-To: <1238452498.24.0.140926416369.issue5616@psf.upfronthosting.co.za>
Message-ID: <1264954826.85.0.566126484169.issue5616@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5616>
_______________________________________

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: [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 18:20:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 17:20:59 +0000
Subject: [issue7822] 2to3 does not convert output lines in doctests
In-Reply-To: <1264957218.46.0.892120848573.issue7822@psf.upfronthosting.co.za>
Message-ID: <1264958459.78.0.0451184006267.issue7822@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The output line can be anything, so it's impossible for 2to3 to know that it is a Python expression that needs to be converted.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7822>
_______________________________________

From report at bugs.python.org  Sun Jan 31 18:28:22 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 17:28:22 +0000
Subject: [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: <1264958902.93.0.120897251146.issue7820@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think the test should be in test_pep263.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Jan 31 18:36:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 31 Jan 2010 17:36:53 +0000
Subject: [issue7822] 2to3 does not convert output lines in doctests
In-Reply-To: <1264958459.78.0.0451184006267.issue7822@psf.upfronthosting.co.za>
Message-ID: <4B65BFAD.5090306@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> to know that it is a Python expression that needs to be converted.

Oh, of course. I have made two assumptions here: output lines are not 
always the repr of a Python object, and the repr is not always a valid 
Python expression.

I?ll have to subclass build_2to3 in my setup script. *groans*

Thank you for answering.

Merwok

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7822>
_______________________________________

From report at bugs.python.org  Sun Jan 31 19:02:29 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 18:02:29 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1264960949.97.0.465982971676.issue7671@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

These patches cause the Windows buildbot to fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7671>
_______________________________________

From report at bugs.python.org  Sun Jan 31 19:12:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 31 Jan 2010 18:12:45 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1264961565.52.0.696135094665.issue7671@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7671>
_______________________________________

From report at bugs.python.org  Sun Jan 31 19:13:49 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 18:13:49 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1264961629.07.0.306168438764.issue7671@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

These patches cause the Windows buildbot to fail.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7671>
_______________________________________

From report at bugs.python.org  Sun Jan 31 19:31:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Jan 2010 18:31:11 +0000
Subject: [issue7821] Command line option -U not documented
In-Reply-To: <1264919490.48.0.0177386547442.issue7821@psf.upfronthosting.co.za>
Message-ID: <1264962671.0.0.763655691606.issue7821@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think changing anything is necessary here. Having the option listed gives the curious a chance to discover a piece of Python history :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7821>
_______________________________________

From report at bugs.python.org  Sun Jan 31 22:14:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 21:14:03 +0000
Subject: [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: <1264972443.46.0.307862683804.issue7818@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The method was supposed to be for internal use only

I found this bug by fuzzing.

> it may be worthwhile to build-out the test to accept many different possible inputs (...)

Yeah, but I just want to avoid an assertion error :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7818>
_______________________________________

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: [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>
_______________________________________

From report at bugs.python.org  Sun Jan 31 22:28:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Jan 2010 21:28:12 +0000
Subject: [issue7823] multiplying a list of dictionaries
In-Reply-To: <1264972707.42.0.603624170105.issue7823@psf.upfronthosting.co.za>
Message-ID: <1264973292.42.0.723999914985.issue7823@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is because multiply the list produces a reference to the same object 3 times.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7823>
_______________________________________

From report at bugs.python.org  Sun Jan 31 22:46:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 21:46:46 +0000
Subject: [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: <1264974406.3.0.132770990556.issue7820@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think the test should be in test_pep263.

Right! I always hesitate when adding a new test.

----------
Added file: http://bugs.python.org/file16072/parser_restore_bom-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Jan 31 22:46:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 21:46:52 +0000
Subject: [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: <1264974412.49.0.271968099916.issue7820@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file16068/parser_restore_bom-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7820>
_______________________________________

From report at bugs.python.org  Sun Jan 31 23:08:41 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 31 Jan 2010 22:08:41 +0000
Subject: [issue7819] sys.call_tracing(): check arguments type
In-Reply-To: <1264907810.16.0.644202807752.issue7819@psf.upfronthosting.co.za>
Message-ID: <1264975721.31.0.452405275412.issue7819@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This very fix was already done in py3k with issue3661.
Unfortunately it was decided at the time that 2.6 is not affected...
Patch is OK, please apply.

----------
nosy: +amaury.forgeotdarc
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7819>
_______________________________________

From report at bugs.python.org  Sun Jan 31 23:32:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Jan 2010 22:32:51 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264977171.42.0.637754124558.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your patch lacked a fix for test_largefile (I think it is skipped under Windows). I added this and committed it in r77890. Will port to py3k.

----------
resolution:  -> accepted
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6939>
_______________________________________

From report at bugs.python.org  Sun Jan 31 23:37:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 22:37:09 +0000
Subject: [issue7819] sys.call_tracing(): check arguments type
In-Reply-To: <1264907810.16.0.644202807752.issue7819@psf.upfronthosting.co.za>
Message-ID: <1264977429.08.0.78125590848.issue7819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This very fix was already done in py3k with issue3661.

Oh! My patch is *very* close to this one. I just choosed 10 instead of 2 in the unit test :-) (and I added a test to check a valid argument, py3k doesn't check it).

> Patch is OK, please apply.

Done:  r77892 (r77893).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7819>
_______________________________________

From report at bugs.python.org  Sun Jan 31 23:37:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 22:37:20 +0000
Subject: [issue7819] sys.call_tracing(): check arguments type
In-Reply-To: <1264907810.16.0.644202807752.issue7819@psf.upfronthosting.co.za>
Message-ID: <1264977440.36.0.393834115057.issue7819@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7819>
_______________________________________