From report at bugs.python.org  Fri Feb  1 12:18:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Feb 2008 11:18:48 -0000
Subject: [New-bugs-announce] [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>>> x = io.StringIO(1)
>>> x.read()
'1'

----------
components: Extension Modules
messages: 61957
nosy: georg.brandl
priority: high
severity: normal
status: open
title: io.StringIO allows any parameter
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Fri Feb  1 19:13:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2008 18:13:48 -0000
Subject: [New-bugs-announce] [issue1995] localeconv() does not encode
	returned strings
In-Reply-To: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>
Message-ID: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Some values in the dict returned by localeconv() may be non-ASCII
strings, yet they are not decoded according to the locale's character
set. This can be observed when the currency symbol is the euro sign:

>>> import locale
>>> locale.setlocale(locale.LC_MONETARY, 'fr_FR.UTF-8')
'fr_FR.UTF-8'
>>> locale.localeconv()['currency_symbol']
'\xe2\x82\xac'
>>> locale.setlocale(locale.LC_MONETARY, 'fr_FR.ISO8859-15')
'fr_FR.ISO8859-15'
>>> locale.localeconv()['currency_symbol']
'\xa4'

localeconv() is defined in the _locale module, which has no knowledge of
the current encoding - but the locale module does. So we could redefine
localeconv() in locale as a wrapper, to do the proper encoding dance.

----------
components: Extension Modules
messages: 61970
nosy: pitrou
severity: normal
status: open
title: localeconv() does not encode returned strings
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1995>
__________________________________

From report at bugs.python.org  Fri Feb  1 20:45:02 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2008 19:45:02 -0000
Subject: [New-bugs-announce] [issue1996] float.as_integer_ratio() needs to
	return fraction in lowest terms
In-Reply-To: <1201895102.84.0.505025801473.issue1996@psf.upfronthosting.co.za>
Message-ID: <1201895102.84.0.505025801473.issue1996@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Just before the sign bit is restored, add code with the following effect:

    while not top&1:
        top >>= 1
        e += 1

Tests: 
  math.pi --> (884279719003555, 281474976710656)
  7.5 --> (15, 2)
  0.875 --> (7, 8)

----------
files: tmp_float_conv.py
messages: 61975
nosy: rhettinger
severity: normal
status: open
title: float.as_integer_ratio() needs to return fraction in lowest terms
Added file: http://bugs.python.org/file9344/tmp_float_conv.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1996>
__________________________________

From report at bugs.python.org  Fri Feb  1 22:18:45 2008
From: report at bugs.python.org (Aaron Watters)
Date: Fri, 01 Feb 2008 21:18:45 -0000
Subject: [New-bugs-announce] [issue1997] unicode and string compare should
	not cause an exception
In-Reply-To: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>
Message-ID: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>


New submission from Aaron Watters:

As I understand it comparisons between two objects should
always work.  I get this at the interpreter prompt:

Python 2.6a0 (trunk, Jan 11 2008, 11:40:59) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> unichr(0xffff) < chr(128)
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)
>>> 

I think the fix for this case is to do something
arbitrary but consistent if possible?

----------
components: Interpreter Core
messages: 61976
nosy: aaron_watters
severity: normal
status: open
title: unicode and string compare should not cause an exception
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:02:07 2008
From: report at bugs.python.org (Mick Charles Beaver)
Date: Sat, 02 Feb 2008 01:02:07 -0000
Subject: [New-bugs-announce] [issue1998] documentation grammatical error
In-Reply-To: <1201914127.03.0.970500113974.issue1998@psf.upfronthosting.co.za>
Message-ID: <1201914127.03.0.970500113974.issue1998@psf.upfronthosting.co.za>


New submission from Mick Charles Beaver:

On page:
http://docs.python.org/lib/sqlite3-Module-Contents.html

The following:
If you want to use other types, like you have to add support for them
yourself.

Should be:
If you want to use other types, you'll have to add support for them
yourself.

----------
components: Documentation
messages: 61985
nosy: mickbeaver
severity: minor
status: open
title: documentation grammatical error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1998>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:06:00 2008
From: report at bugs.python.org (Mick Charles Beaver)
Date: Sat, 02 Feb 2008 01:06:00 -0000
Subject: [New-bugs-announce] [issue1999] wrong tracker
In-Reply-To: <1201914360.49.0.525669196275.issue1999@psf.upfronthosting.co.za>
Message-ID: <1201914360.49.0.525669196275.issue1999@psf.upfronthosting.co.za>


New submission from Mick Charles Beaver:

When I found a small mistake in the documentation, I went to the
following URL, which in turn sent me to SourceForge, which then sent me
to the Roundup bug database.

http://docs.python.org/lib/about.html

----------
components: Documentation
messages: 61986
nosy: mickbeaver
severity: urgent
status: open
title: wrong tracker
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1999>
__________________________________

From report at bugs.python.org  Sat Feb  2 19:19:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 02 Feb 2008 18:19:38 -0000
Subject: [New-bugs-announce] [issue2000] Undefined symbols: _PyOS_mystrnicmp
	on Mac OS X
In-Reply-To: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>
Message-ID: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

On Mac OS X, make fails with the following error
..
/usr/bin/ld: Undefined symbols:
_PyOS_mystrnicmp
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1

The attached patch fixes the issue.

----------
components: Build
files: make-patch.diff
messages: 62006
nosy: belopolsky
severity: normal
status: open
title: Undefined symbols: _PyOS_mystrnicmp on Mac OS X
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file9349/make-patch.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2000>
__________________________________

From report at bugs.python.org  Sun Feb  3 00:05:53 2008
From: report at bugs.python.org (Ron Adam)
Date: Sat, 02 Feb 2008 23:05:53 -0000
Subject: [New-bugs-announce] [issue2001] Pydoc interactive browsing
	enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>


New submission from Ron Adam:

This patch removes the gui tk control panel and replaces it with a
navigation bar on the served web pages.

This offers a nicer user experience because one no longer needs to jump
back and forth between windows.

The navbar supports getting specific modules, searching modules, and
returning to the main module index. I believe the file source view is
safer also.

Possible issues...
 
+ Restarting the server without ending it causes an error do to the port
already being used.  I think this is not new.

+ There may be some brakage if other applications depend on the tk
interface, but I don't think any do.  Or at least none that I know of.

+ I haven't tested this on windows.  (It works well on Ubuntu 7.10)

----------
components: Library (Lib)
files: pydocnotk.diff
messages: 62012
nosy: ron_adam
severity: normal
status: open
title: Pydoc interactive browsing enhancement
type: rfe
Added file: http://bugs.python.org/file9350/pydocnotk.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Sun Feb  3 00:44:52 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 23:44:52 -0000
Subject: [New-bugs-announce] [issue2002] Make int() fall back to trunc()
In-Reply-To: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>
Message-ID: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

Per http://mail.python.org/pipermail/python-dev/2008-January/076564.html.

----------
assignee: jyasskin
messages: 62014
nosy: jyasskin
priority: high
severity: normal
status: open
title: Make int() fall back to trunc()
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Sun Feb  3 03:33:26 2008
From: report at bugs.python.org (Thane Plummer)
Date: Sun, 03 Feb 2008 02:33:26 -0000
Subject: [New-bugs-announce] [issue2003] Incorrect definition of new-style
	class
In-Reply-To: <1202006006.49.0.160716735552.issue2003@psf.upfronthosting.co.za>
Message-ID: <1202006006.49.0.160716735552.issue2003@psf.upfronthosting.co.za>


New submission from Thane Plummer:

Python Reference Manual section 3.3 (p3 s2) contains the fragment "A 
new-style class neither more nor less than a user-defined type."  A 
well placed 2-letter verb would transform this sad little fragment into 
a delightful, pleasing, and ultimately useful sentence.

----------
components: Documentation
messages: 62015
nosy: thaneplummer
severity: minor
status: open
title: Incorrect definition of new-style class
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2003>
__________________________________

From report at bugs.python.org  Sun Feb  3 04:59:13 2008
From: report at bugs.python.org (Michael Brown)
Date: Sun, 03 Feb 2008 03:59:13 -0000
Subject: [New-bugs-announce] [issue2004] tarfile extractall() allows local
	attacker to overwrite files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>


New submission from Michael Brown:

python 2.5.1
tarfile.py line 1516 in extractall() 

sets directories created to world-writeable while extracting which means
an attacker can change/modify files before perms are fixed. Suggest 770
while extracting to fix.

----------
components: Library (Lib)
messages: 62016
nosy: mebrown
severity: major
status: open
title: tarfile extractall() allows local attacker to overwrite files while extracting
type: security
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Sun Feb  3 20:58:45 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 03 Feb 2008 19:58:45 -0000
Subject: [New-bugs-announce] [issue2005] posixmodule expects
	sizeof(pid_t/gid_t/uid_t) <= sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The posix module except that a pid_t, uid_t and gid_t always fit into a
long or can be parsed by "i". On some OSes and combination of 64bit
typess and 32bit long it's an invalid assumption.

The code should use long long where available or at least do some
overflow checks.

See r1983

----------
components: Extension Modules
keywords: easy
messages: 62026
nosy: tiran
priority: normal
severity: normal
status: open
title: posixmodule expects sizeof(pid_t/gid_t/uid_t) <= sizeof(long)
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
__________________________________

From report at bugs.python.org  Mon Feb  4 06:52:07 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 05:52:07 -0000
Subject: [New-bugs-announce] [issue2006] asyncore loop lacks timers and work
	tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>


New submission from Bill Janssen:

I've been reading asyncore lately, and feel that it's showing its age. 
Most loops of this sort (we developed something similar for ILU, about
15 years ago) contain handlers for timers and work tasks, in addition to
input handling.  For timers, typically there's a list of tasks and
times, often with a repeat period.  A system timer is set to the time of
the next task to fire, and the select() loop is exited when it fires. 
The loop handler then looks down the list of timer tasks, and executes
those ready to run.  Similarly, most loops of this sort include a list
of work tasks, and a policy for executing them, such as "take one task
from the front of the list and run it, then do the select".  This allows
background tasks to get run that don't have associated input or output fds.

----------
components: Library (Lib)
messages: 62034
nosy: janssen
severity: normal
status: open
title: asyncore loop lacks timers and work tasks
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Mon Feb  4 20:35:53 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 19:35:53 -0000
Subject: [New-bugs-announce] [issue2007] cookielib lacks FileCookieJar class
	for Internet Explorer
In-Reply-To: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>
Message-ID: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>


New submission from Bill Janssen:

cookielib contains an implementation of FileCookieJar for Mozilla
Firefox, which will work with most of the various Mozilla browsers, but
no implementation for Internet Explorer, standard on Windows and used by
some 80% of computer users.

----------
components: Library (Lib)
messages: 62046
nosy: janssen
severity: normal
status: open
title: cookielib lacks FileCookieJar class for Internet Explorer
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2007>
__________________________________

From report at bugs.python.org  Mon Feb  4 20:37:26 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 19:37:26 -0000
Subject: [New-bugs-announce] [issue2008] cookielib lacks FileCookieJar class
	for Safari
In-Reply-To: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>
Message-ID: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>


New submission from Bill Janssen:

cookielib has no FileCookieJar class for Safari, Apple's standard and
default browser for OS X.

----------
components: Library (Lib)
messages: 62047
nosy: janssen
severity: normal
status: open
title: cookielib lacks FileCookieJar class for Safari
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2008>
__________________________________

From report at bugs.python.org  Tue Feb  5 01:19:50 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 05 Feb 2008 00:19:50 -0000
Subject: [New-bugs-announce] [issue2009] Grammar change to prevent
	shift/reduce problem with varargslist
In-Reply-To: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>
Message-ID: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>


New submission from Andrew Dalke:

I wrote a translator from the CFG used in the Grammar file into a form for PLY.  I 
found one problem with

varargslist: ((fpdef ['=' test] ',')*
              ('*' NAME [',' '**' NAME] | '**' NAME) |
              fpdef ['=' test] (',' fpdef ['=' test])* [','])

This grammar definition is ambiguous until the presence/lack of a "*".  PLY 
complains:

state 469

    (28) varargslist -> fpdef EQUAL test COMMA .
    (32) varargslist_star -> fpdef EQUAL test COMMA .
    (35) varargslist_star3 -> COMMA . fpdef
    (36) varargslist_star3 -> COMMA . fpdef EQUAL test
    (39) fpdef -> . NAME
    (40) fpdef -> . LPAR fplist RPAR

  ! shift/reduce conflict for NAME resolved as shift.
  ! shift/reduce conflict for LPAR resolved as shift.

    RPAR            reduce using rule 28 (varargslist -> fpdef EQUAL test COMMA .)
    COLON           reduce using rule 28 (varargslist -> fpdef EQUAL test COMMA .)
    STAR            reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA .)
    DOUBLESTAR      reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA .)
    NAME            shift and go to state 165
    LPAR            shift and go to state 163

  ! NAME            [ reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA 
.) ]
  ! LPAR            [ reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA 
.) ]

    fpdef                          shift and go to state 515



My fix was to use this definition when I did the translation.

varargslist: ((fpdef ['=' test] (',' fpdef ['=' test])* 
                   (',' '*' NAME [',' '**' NAME] | ',' '**' NAME | [','])) |
              ('*' NAME [',' '**' NAME]) |
              ('**' NAME))


So far I've not found a functional difference between these two definitions, and 
the only change to ast.c is to update the comment based on this section.

By making this change it would be easier for the handful of people who write 
parsers for Python based on a yacc-like look-ahead(1) parser to use that file more 
directly.

----------
components: None
messages: 62055
nosy: dalke
severity: minor
status: open
title: Grammar change to prevent shift/reduce problem with varargslist
type: rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2009>
__________________________________

From report at bugs.python.org  Tue Feb  5 01:33:32 2008
From: report at bugs.python.org (Karl Norby)
Date: Tue, 05 Feb 2008 00:33:32 -0000
Subject: [New-bugs-announce] [issue2010] Link to howto section on re module
	documentation incorrect
In-Reply-To: <1202171612.68.0.248444949572.issue2010@psf.upfronthosting.co.za>
Message-ID: <1202171612.68.0.248444949572.issue2010@psf.upfronthosting.co.za>


New submission from Karl Norby:

The link on "http://docs.python.org/lib/re-syntax.html" to the HOWTO
section of documentation redirects incorrectly to
"http://docs.python.org/dev/howto/index.html/". It should be
"http://docs.python.org/dev/howto/" or
"http://docs.python.org/dev/howto/index.html".

----------
components: Documentation
messages: 62056
nosy: knorby
severity: minor
status: open
title: Link to howto section on re module documentation incorrect
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2010>
__________________________________

From report at bugs.python.org  Tue Feb  5 01:46:41 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 05 Feb 2008 00:46:41 -0000
Subject: [New-bugs-announce] [issue2011] compiler.parse("1;
	") adds unexpected extra Discard(Const(None)) to parse tree
In-Reply-To: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>
Message-ID: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>


New submission from Andrew Dalke:

Python 2.6a0 (trunk:60565M, Feb  4 2008, 01:21:28) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from compiler import parse
>>> parse("1;")
Module(None, Stmt([Discard(Const(1)), Discard(Const(None))]))

I did not expect the Discard(Const(None)).  Instead, I expected

Module(None, Stmt([Discard(Const(1))]))

----------
components: Library (Lib)
messages: 62057
nosy: dalke
severity: minor
status: open
title: compiler.parse("1;") adds unexpected extra Discard(Const(None)) to parse tree
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2011>
__________________________________

From report at bugs.python.org  Tue Feb  5 02:32:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 01:32:31 -0000
Subject: [New-bugs-announce] [issue2012] Add migration step for DictMixin ->
	collections.MutableMapping
In-Reply-To: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>
Message-ID: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>


New submission from Christian Heimes:

See r60577

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 62058
nosy: collinwinter, tiran
priority: normal
severity: normal
status: open
title: Add migration step for DictMixin -> collections.MutableMapping
type: rfe
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2012>
__________________________________

From report at bugs.python.org  Tue Feb  5 04:07:48 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 03:07:48 -0000
Subject: [New-bugs-announce] [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch adds a free list of long objects with size 1 or -1. It has
quite a tremendous effect on code like list(range(1000)).

$ ./python -m timeit "for i in range(100): list(range(1000))"

Without patch:
10 loops, best of 3: 79 msec per loop

With patch:
10 loops, best of 3: 20.8 msec per loop

----------
components: Interpreter Core
files: long_freelist.patch
keywords: patch
messages: 62060
nosy: tiran
priority: normal
severity: normal
status: open
title: Long object free list optimization
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9355/long_freelist.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
__________________________________

From report at bugs.python.org  Wed Feb  6 00:12:37 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 05 Feb 2008 23:12:37 -0000
Subject: [New-bugs-announce] [issue2014] xmlrpclib cannot send datetime
	objects with dates before 1900
In-Reply-To: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>
Message-ID: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

xmlrpclib uses datetime.strftime which cannot handle dates before 1900.
this patch adds a custom date formatting function, which does not have
this restriction. It also contains 2 additional unit tests, which both
fail with the unpatched version.

----------
components: Library (Lib)
files: xmlrpc_date_before_1900.txt
messages: 62082
nosy: schmir
severity: normal
status: open
title: xmlrpclib cannot send datetime objects with dates before 1900
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9358/xmlrpc_date_before_1900.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Wed Feb  6 01:45:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Feb 2008 00:45:15 -0000
Subject: [New-bugs-announce] [issue2015] Possible optimisations in kwargs
	handling
In-Reply-To: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>
Message-ID: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This is a reminder for the comment on top of ceval.c:
/* XXX TO DO:
   XXX speed up searching for keywords by using a dictionary
   XXX document it!
   */

It was also suggested to disallow subclasses of str in variable names,
in order to optimize comparisons. This restriction is not necessary if a
dict lookup is used: comparisons are less frequent and will often
succeed when comparing pointers of interned strings.

----------
messages: 62085
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Possible optimisations in kwargs handling
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2015>
__________________________________

From report at bugs.python.org  Wed Feb  6 02:01:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Feb 2008 01:01:11 -0000
Subject: [New-bugs-announce] [issue2016] Crash when modifying the **kwargs
	passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

The following script exploits a comment in funcobject.c:
   /* XXX This is broken if the caller deletes dict items! */
Because the code only borrows references to the items, it is possible to
have them destroyed before they are copied into the called frame.

class Name(str):
  def __eq__(self, other):
     del x[self]
     return str.__eq__(self, other)
  def __hash__(self):
     return str.__hash__(self)

x = {Name("a"):1, Name("b"):2}
def f(a, b): print a,b

f(**x)   # Segfault

----------
messages: 62086
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Crash when modifying the **kwargs passed to a function.
type: crash
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 06:44:28 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Wed, 06 Feb 2008 05:44:28 -0000
Subject: [New-bugs-announce] [issue2017] Calendar.yeardatescalendar etc. do
	not take 'month' argument
In-Reply-To: <1202276668.89.0.427395659293.issue2017@psf.upfronthosting.co.za>
Message-ID: <1202276668.89.0.427395659293.issue2017@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi:

Similar to the issue 1046,
The documentation of Calendar.year*calendar incorrectly have 'month'
argument.

>>> cal = calendar.Calendar(5)
>>> cal.yeardatescalendar(2008,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: yeardatescalendar() takes at most 3 arguments (4 given)
>>>

----------
components: Documentation
messages: 62088
nosy: mft
severity: normal
status: open
title: Calendar.yeardatescalendar etc. do not take 'month' argument
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2017>
__________________________________

From report at bugs.python.org  Wed Feb  6 10:42:01 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Wed, 06 Feb 2008 09:42:01 -0000
Subject: [New-bugs-announce] [issue2018] TextCalendar.formatmonth is not
	influenced by setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi:

TextCalendar.formatmonth is not influenced by setfirstweekday,
but the argument of constructor.

Documentation:
Depends on the first weekday as set by setfirstweekday().

actual behavior:
>>> cal0 = calendar.TextCalendar()
>>> print cal0.formatmonth(2008, 2)
   February 2008
Mo Tu We Th Fr Sa Su
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

>>> calendar.setfirstweekday(4)
>>> print cal0.formatmonth(2008, 2)
   February 2008
Mo Tu We Th Fr Sa Su
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

----------
components: Documentation
messages: 62090
nosy: mft
severity: normal
status: open
title: TextCalendar.formatmonth is not influenced by setfirstweekday
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Wed Feb  6 15:48:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 14:48:08 -0000
Subject: [New-bugs-announce] [issue2019] API to clear most free lists
In-Reply-To: <1202309288.05.0.27913279331.issue2019@psf.upfronthosting.co.za>
Message-ID: <1202309288.05.0.27913279331.issue2019@psf.upfronthosting.co.za>


New submission from Christian Heimes:

As discussed at
http://permalink.gmane.org/gmane.comp.python.python-3000.devel/11694 the
patch adds several PyName_ClearFreelist() functions and extends
sys._compact_freelists() to clear all free lists.

----------
components: Interpreter Core
files: trunk_clearfreelists.patch
keywords: patch
messages: 62097
nosy: brett.cannon, tiran
priority: normal
severity: normal
status: open
title: API to clear most free lists
versions: Python 2.6
Added file: http://bugs.python.org/file9359/trunk_clearfreelists.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2019>
__________________________________

From report at bugs.python.org  Wed Feb  6 16:45:44 2008
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 06 Feb 2008 15:45:44 -0000
Subject: [New-bugs-announce] [issue2020] _sha256 module missing if openssl
	is not in a "normal" directory.
In-Reply-To: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>
Message-ID: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>


New submission from Peter Saunders:

When compiling python 2.5.1 on Solaris 10 (sparc and x86), with openssl
0.9.8e - test_md5 fails with No module named _sha256. (As does doing an
"import md5")

When compiling, setup.dist was modified, the ssl parts were uncommented,
and modified to use the directory that we have ssl installed in.

SSL=/opt/IB
_ssl _ssl.c \
       -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
       -L$(SSL)/lib -R$(SSL)/lib -lssl -lcrypto

The compiling env (on sol x86):
CC=cc
CFLAGS=-xO5 -m32 -xarch=sse3 -xcache=generic -xchip=generic
CPPFLAGS=-I/opt/IB/include
CXX=CC
CXXFLAGS=-xO5 -m32 -xarch=sse3 -xcache=generic -xchip=generic
LDFLAGS=-L/opt/IB/lib -R/opt/IB/lib
LD_RUN_PATH=/opt/IB/lib
PATH=/usr/bin:/sbin:/usr/sbin:/opt/IB/bin:/usr/ccs/bin:/opt/SUNWspro/bin

configure --prefix=/opt/IBpython/2.5.1 --without-gcc --with-threads

However, if I modify setup.py, and replace every occurrence of
"/usr/local" with "/opt/IB" (we don't use /usr/local) - then it compiles
fine, and the md5 module works correctly.

Is it possible for this to be made a configure argument, or a
environment setting?

----------
components: Build
messages: 62101
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: _sha256 module missing if openssl is not in a "normal" directory.
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2020>
__________________________________

From report at bugs.python.org  Wed Feb  6 17:14:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 06 Feb 2008 16:14:24 -0000
Subject: [New-bugs-announce] [issue2021] Turn NamedTemporaryFile into a
	context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

In the spirit of files becoming context managers in 2.5, the attached
patch defines __enter__ and __exit__ methods for
tempfile.NamedTemporaryFile.

BTW, I was not able to add a "patch" keyword which seems appropriate here.

----------
components: Library (Lib)
files: with_NamedTemporaryFile.diff
messages: 62102
nosy: belopolsky
severity: normal
status: open
title: Turn NamedTemporaryFile into a context manager
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9360/with_NamedTemporaryFile.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:25:18 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:25:18 -0000
Subject: [New-bugs-announce] [issue2022] test_al converted to unittest
In-Reply-To: <1202325918.42.0.816019175645.issue2022@psf.upfronthosting.co.za>
Message-ID: <1202325918.42.0.816019175645.issue2022@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment.

----------
files: test_al.diff
messages: 62119
nosy: giampaolo.rodola
severity: normal
status: open
title: test_al converted to unittest
Added file: http://bugs.python.org/file9367/test_al.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2022>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:40:27 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:40:27 -0000
Subject: [New-bugs-announce] [issue2023] test_cd converted to unittest
In-Reply-To: <1202326827.71.0.0542752440376.issue2023@psf.upfronthosting.co.za>
Message-ID: <1202326827.71.0.0542752440376.issue2023@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. All existent tests are unchanged.

----------
components: Tests
files: test_cd.diff
messages: 62121
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_cd converted to unittest
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9368/test_cd.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2023>
__________________________________

From report at bugs.python.org  Wed Feb  6 21:16:06 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 20:16:06 -0000
Subject: [New-bugs-announce] [issue2024] test_gl.py converted to unittest
In-Reply-To: <1202328966.17.0.238328227675.issue2024@psf.upfronthosting.co.za>
Message-ID: <1202328966.17.0.238328227675.issue2024@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. All existing tests are unchanged.

----------
components: Tests
files: test_gl.diff
messages: 62124
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_gl.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9369/test_gl.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2024>
__________________________________

From report at bugs.python.org  Thu Feb  7 00:10:20 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Feb 2008 23:10:20 -0000
Subject: [New-bugs-announce] [issue2025] tuples are instances of
	collections.Sequence but do not support count() and index()
In-Reply-To: <1202339420.02.0.567663678477.issue2025@psf.upfronthosting.co.za>
Message-ID: <1202339420.02.0.567663678477.issue2025@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Remineder to self to add the two missing methods.

http://mail.python.org/pipermail/python-3000/2008-February/012021.html

----------
assignee: rhettinger
components: Interpreter Core
messages: 62127
nosy: rhettinger
severity: normal
status: open
title: tuples are instances of collections.Sequence but do not support count() and index()
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2025>
__________________________________

From report at bugs.python.org  Thu Feb  7 00:48:16 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 23:48:16 -0000
Subject: [New-bugs-announce] [issue2026] test_largefile.py converted to
	unittest
In-Reply-To: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za>
Message-ID: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. The original tests are unchanged.
Tested under Windows XP and Linux Ubuntu 7.04.

----------
components: Tests
files: test_largefile.diff
messages: 62128
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_largefile.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9370/test_largefile.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2026>
__________________________________

From report at bugs.python.org  Thu Feb  7 05:45:42 2008
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 07 Feb 2008 04:45:42 -0000
Subject: [New-bugs-announce] [issue2027] Module containing C implementations
	of common text algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>


New submission from Matt Chaput:

Add a module to the standard library containing fast (C) implementations 
of common text/language related algorithms, to begin specifically Porter 
(and perhaps other) stemming and Levenshtein (and perhaps other) edit 
distance. Both these algorithms are useful in multiple domains, well 
known and understood, and have sample implementations all over the Web, 
but are compute-intensive and prohibitively expensive when implemented 
in pure Python.

----------
components: Library (Lib)
messages: 62134
nosy: mchaput
severity: normal
status: open
title: Module containing C implementations of common text algorithms
type: rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:21:45 2008
From: report at bugs.python.org (=?utf-8?q?Zden=C4=9Bk_Pavlas?=)
Date: Thu, 07 Feb 2008 12:21:45 -0000
Subject: [New-bugs-announce] [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>


New submission from Zden?k Pavlas:

Please consider setting the default file mode to O_BINARY.  O_TEXT
breaks many unix programs and Windows has stopped to use CRLF files for
anything of use since the introduction of Win95's registry anyway.

Days when majority of "C" codebase actually DID process text files AND
CRLF files were used are long over and since Python is NOT "C" it should
reflect that.

----------
components: Windows
messages: 62144
nosy: zde
severity: minor
status: open
title: _fmode = O_TEXT is obsolete
type: behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:24:54 2008
From: report at bugs.python.org (Ben Bass)
Date: Thu, 07 Feb 2008 12:24:54 -0000
Subject: [New-bugs-announce] [issue2029] "python -m pydoc -g"  fails
In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>
Message-ID: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>


New submission from Ben Bass:

To quickly open a PyDoc browser, I want to be able to run the following:

python -m pydoc -g

This works fine on Python2.4, but fails on 2.5(.1), with following
traceback (tested on both WinXP and Solaris 8, same result):

Traceback (most recent call last):
  File "c:\python25\lib\runpy.py", line 95, in run_module
    filename, loader, alter_sys)
  File "c:\python25\lib\runpy.py", line 52, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "c:\python25\lib\runpy.py", line 32, in _run_code
    exec code in run_globals
  File "c:\python25\lib\pydoc.py", line 2255, in <module>
    if __name__ == '__main__': cli()
  File "c:\python25\lib\pydoc.py", line 2191, in cli
    gui()
  File "c:\python25\lib\pydoc.py", line 2162, in gui
    gui = GUI(root)
  File "c:\python25\lib\pydoc.py", line 2052, in __init__
    import threading
ImportError: No module named threading


When running pydoc.py -g directly (i.e. without the -m) it works fine,
but this requires knowing the specific location of pydoc library file,
so is less helpful.

----------
components: Library (Lib)
messages: 62145
nosy: bpb
severity: normal
status: open
title: "python -m pydoc -g"  fails
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2029>
__________________________________

From report at bugs.python.org  Thu Feb  7 16:05:51 2008
From: report at bugs.python.org (Richard Mason)
Date: Thu, 07 Feb 2008 15:05:51 -0000
Subject: [New-bugs-announce] [issue2038] win32pdh.EnumObjects fails on
	Windows Server 2003 R2
In-Reply-To: <1202396751.1.0.830265852808.issue2038@psf.upfronthosting.co.za>
Message-ID: <1202396751.1.0.830265852808.issue2038@psf.upfronthosting.co.za>


New submission from Richard Mason:

The following test script works OK on all windows platforms apart from 
Windows Server 2003 R2:

import win32pdh
win32pdh.EnumObjects(None, None, 0, 1)

When I run on Windows Server 2003 R2 get the following dump:

E:\fusiondx\lib>test.py
Traceback (most recent call last):
  File "E:\fusiondx\lib\test.py", line 2, in <module>
    win32pdh.EnumObjects(None, None, 0, 1)
pywintypes.error: (-2147481648, 'EnumObjects for buffer size', 'No 
error message is available')

----------
components: Extension Modules
messages: 62152
nosy: rmason
severity: critical
status: open
title: win32pdh.EnumObjects fails on Windows Server 2003 R2
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2038>
__________________________________

From report at bugs.python.org  Thu Feb  7 18:19:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Feb 2008 17:19:20 -0000
Subject: [New-bugs-announce] [issue2039] Pymalloc patch for int and float
	objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch removes the special allocation schema for ints and floats and
replaces it but a standard PyObject_MALLOC schema with a limited free_list.

----------
components: Interpreter Core
files: trunk_intfloat_freelist.patch
keywords: patch
messages: 62158
nosy: tiran
priority: normal
severity: normal
status: open
title: Pymalloc patch for int and float objects
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9379/trunk_intfloat_freelist.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Thu Feb  7 18:38:48 2008
From: report at bugs.python.org (Jag Ginsberg)
Date: Thu, 07 Feb 2008 17:38:48 -0000
Subject: [New-bugs-announce] [issue2040] Class instance attributes that are
	property() should appear in __dict__
In-Reply-To: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>
Message-ID: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>


New submission from Jag Ginsberg:

If I have a class:

class Foo(object):
  bar = property(lambda self: 'baz') # ignore the value's trivial nature

and then run:

>>> foo_obj = Foo()
>>> foo_obj.__dict__

... I would expect to see:

{'bar': 'baz'}

... and not:

{}

This would seem consistent with what a property is supposed to
masquerade as. Do you disagree?

-jag

----------
components: Interpreter Core
messages: 62159
nosy: jag
severity: minor
status: open
title: Class instance attributes that are property() should appear in __dict__
type: behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2040>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:19:21 2008
From: report at bugs.python.org (Stefan Seefeld)
Date: Thu, 07 Feb 2008 18:19:21 -0000
Subject: [New-bugs-announce] [issue2041] __getslice__ still called
In-Reply-To: <1202408361.12.0.538007423172.issue2041@psf.upfronthosting.co.za>
Message-ID: <1202408361.12.0.538007423172.issue2041@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

The python documentation states that since python 2.0 __getslice__ is
obsoleted by __getitem__. However, testing with python 2.3 as well as
2.5, I find the following surprising behavior:

class Tuple(tuple):

  def __getitem__(self, i): print '__getitem__', i
  def __getslice__(self, i): print '__getslice__', i

t = Tuple()
t[0] # __getitem__ called with type(i) == int
t[0:2] # __getslice__ called with type(i) == slice
t[0:2:1] # __getitem__ called with type(i) == slice

----------
components: Interpreter Core
messages: 62162
nosy: stefan
severity: major
status: open
title: __getslice__ still called
type: behavior
versions: Python 2.3, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2041>
__________________________________

From report at bugs.python.org  Thu Feb  7 21:00:09 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 20:00:09 -0000
Subject: [New-bugs-announce] [issue2042] test_audioop.py converted to
	unittest
In-Reply-To: <1202414409.05.0.332435353831.issue2042@psf.upfronthosting.co.za>
Message-ID: <1202414409.05.0.332435353831.issue2042@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. Original tests are unchanged.

----------
components: Tests
files: test_audioop.diff
messages: 62176
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_audioop.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9383/test_audioop.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2042>
__________________________________

From report at bugs.python.org  Thu Feb  7 21:18:30 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 20:18:30 -0000
Subject: [New-bugs-announce] [issue2043] test_cl.py converted to unittest
In-Reply-To: <1202415510.1.0.944242978203.issue2043@psf.upfronthosting.co.za>
Message-ID: <1202415510.1.0.944242978203.issue2043@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment.

----------
components: Tests
files: test_cl.diff
messages: 62178
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_cl.py converted to unittest
versions: Python 2.6
Added file: http://bugs.python.org/file9385/test_cl.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2043>
__________________________________

From report at bugs.python.org  Thu Feb  7 22:06:55 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 21:06:55 -0000
Subject: [New-bugs-announce] [issue2044] test_sunaudiodev.py converted to
	unittest
In-Reply-To: <1202418415.34.0.91216503558.issue2044@psf.upfronthosting.co.za>
Message-ID: <1202418415.34.0.91216503558.issue2044@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment.
I didn't try it since I don't have a SunOS system but it should be ok
(it's very minimalistic).
As far as I can tell it should work also for Python 3.0.

----------
components: Tests
files: test_sunaudiodev.diff
messages: 62182
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_sunaudiodev.py converted to unittest
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9386/test_sunaudiodev.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2044>
__________________________________

From report at bugs.python.org  Thu Feb  7 23:35:31 2008
From: report at bugs.python.org (jason kirtland)
Date: Thu, 07 Feb 2008 22:35:31 -0000
Subject: [New-bugs-announce] [issue2045] defaultdict subclasses segfault
	with a bound method set as a default_factory
In-Reply-To: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>
Message-ID: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>


New submission from jason kirtland:

Python 2.5.1 (r251:54863, May 23 2007, 16:25:53) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import defaultdict
>>> class sub(defaultdict):
...     def __init__(self):
...         self.default_factory = self._factory
...     def _factory(self):
...         return []
... 
>>> s = sub()
>>> repr(s)
Segmentation fault

----------
components: Library (Lib)
messages: 62185
nosy: jek
severity: normal
status: open
title: defaultdict subclasses segfault with a bound method set as a default_factory
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2045>
__________________________________

From report at bugs.python.org  Fri Feb  8 00:44:08 2008
From: report at bugs.python.org (Eduardo Padoan)
Date: Thu, 07 Feb 2008 23:44:08 -0000
Subject: [New-bugs-announce] [issue2046] patch to fix_import: UserDict ->
	collections
In-Reply-To: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>
Message-ID: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>


New submission from Eduardo Padoan:

UserDict moved from UserDict module (deleted) to collections on py3k.
This patch adds this case to fix_import.py on 2to3.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_import_udict.diff
messages: 62186
nosy: collinwinter, eopadoan, rhettinger
severity: normal
status: open
title: patch to fix_import: UserDict -> collections
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9388/fix_import_udict.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2046>
__________________________________

From report at bugs.python.org  Fri Feb  8 07:15:38 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Fritzsche?=)
Date: Fri, 08 Feb 2008 06:15:38 -0000
Subject: [New-bugs-announce] [issue2047] shutil.destinsrc returns wrong
	result when source path matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>


New submission from Andr? Fritzsche:

shutil.destinsrc(src,dst)

Checks if 'dst' starts with 'src', which can return a wrong result if
'dst' even starts with 'scr' but isn't really a subdirector of it. E.g.
(src=r'C:\data', dst=r'C:\data.old') returned true, although dst isn't a
subdirectory of src.

I tried to fix this creating the absolute paths of 'dst' and 'src'
appended the path seperator, if there wasn't one. Then did the check
again and now the result is correct.

See the diff file I've appended (and hopefully created correctly)

----------
components: Library (Lib)
files: shutil.diff
messages: 62193
nosy: computercrustie
severity: normal
status: open
title: shutil.destinsrc returns wrong result when source path matches beginning of destination path
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file9389/shutil.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Fri Feb  8 11:19:18 2008
From: report at bugs.python.org (Atro Tossavainen)
Date: Fri, 08 Feb 2008 10:19:18 -0000
Subject: [New-bugs-announce] [issue2048] Python 2.5.1 woes on IRIX, Solaris
In-Reply-To: <1202465958.71.0.917319505775.issue2048@psf.upfronthosting.co.za>
Message-ID: <1202465958.71.0.917319505775.issue2048@psf.upfronthosting.co.za>


New submission from Atro Tossavainen:

Building and testing on Solaris 8 on SPARC with Sun compilers:
cc: Sun C 5.8 2005/10/13
CC: Sun C++ 5.8 2005/10/13

281 tests OK.
40 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes
    test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev
    test_macfs test_macostools test_nis test_normalization
    test_ossaudiodev test_pep277 test_plistlib test_scriptpackages
    test_socket_ssl test_socketserver test_sqlite test_startfile
    test_sunaudiodev test_tcl test_timeout test_unicode_file
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_zipfile64
4 skips unexpected on sunos5:
    test_tcl test_sunaudiodev test_ctypes test_nis

...
test_tcl skipped -- No module named _tkinter
...

I have applied the _ctypes patch in #1516, however.  What gives?

Building and testing on IRIX 6.5.30 with MIPS compilers 7.4.4, the test
suite fails to complete:

test_xml_etree
gmake: *** [test] Segmentation fault

----------
components: Build, Tests
messages: 62194
nosy: atossava
severity: normal
status: open
title: Python 2.5.1 woes on IRIX, Solaris
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2048>
__________________________________

From report at bugs.python.org  Fri Feb  8 13:34:30 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 08 Feb 2008 12:34:30 -0000
Subject: [New-bugs-announce] [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>


New submission from Tal Einat:

When IDLE is run with a subprocess, add a 'Restart Shell & Run Module'
item to the 'Run' menu in editor windows. Also add Alt-F5 as a hotkey
for this item.

This is what the 'Run Module' (F5) item used to do (when there was a
subprocess). As of this patch 'Run Module' will not restart the shell
under any circumstances.


The advantages of this are that the user has more control (can run a
module in the shell either with or without restarting). It also avoids
surprising users which wouldn't expect 'Run Module' to restart the shell.


Based on changes proposed by Doug on idle-dev:
http://mail.python.org/pipermail/idle-dev/2007-January/002541.html

----------
components: IDLE
files: IDLE_restart_shell_and_run_module.080208.patch
messages: 62195
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Restart Shell & Run Module
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9390/IDLE_restart_shell_and_run_module.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Fri Feb  8 13:45:47 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 08 Feb 2008 12:45:47 -0000
Subject: [New-bugs-announce] [issue2050] IDLE - make ScriptBinding event
	handlers return 'break'
In-Reply-To: <1202474747.18.0.823869647576.issue2050@psf.upfronthosting.co.za>
Message-ID: <1202474747.18.0.823869647576.issue2050@psf.upfronthosting.co.za>


New submission from Tal Einat:

Event handlers in ScriptBinding.py were not returning 'break', although
they should have been.

----------
components: IDLE
files: IDLE_ScriptBinding.080208.patch
messages: 62196
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - make ScriptBinding event handlers return 'break'
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9391/IDLE_ScriptBinding.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2050>
__________________________________

From report at bugs.python.org  Fri Feb  8 20:28:32 2008
From: report at bugs.python.org (stocker81)
Date: Fri, 08 Feb 2008 19:28:32 -0000
Subject: [New-bugs-announce] [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>


New submission from stocker81:

Python's interpreter doesn't keep proper file permissions after
importing library. See the fallowing:

mk at laptop ~ $ echo "key='top secret'" > key.py
mk at laptop ~ $ chmod 600 key.py 
mk at laptop ~ $ python
Python 2.4.4 (#1, Jan  8 2008, 21:22:16) 
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import key
>>> 
mk at laptop ~ $ ls -l key.py*
-rw------- 1 mk mk  17 II  8 20:09 key.py
-rw-r--r-- 1 mk mk 120 II  8 20:09 key.pyc
mk at laptop ~ $ 

So, interpreter creates 644 pyo file (visible for all) which contains
secret data from 600 py file.
I think it should keep the original permissions, someone can save a
important data (eg. SQL login/pwd into Django's settings.py) into
library and makes it visible for all by an accident.

----------
components: None
messages: 62203
nosy: stocker81
severity: normal
status: open
title: PYO file permission problem
type: security
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Fri Feb  8 22:21:54 2008
From: report at bugs.python.org (josephoenix)
Date: Fri, 08 Feb 2008 21:21:54 -0000
Subject: [New-bugs-announce] [issue2052] Lack of difflib.HtmlDiff unicode
	support
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>


New submission from josephoenix:

When passed unicode strings, difflib.HtmlDiff.make_file and make_table 
fail with a UnicodeEncodeError. Also, the html outputted by make_file 
seems to be hardcoded to use charset=ISO-8859-1 (line 1584 of difflib.py)

----------
components: Library (Lib)
messages: 62208
nosy: josephoenix
severity: normal
status: open
title: Lack of difflib.HtmlDiff unicode support
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
__________________________________

From report at bugs.python.org  Sat Feb  9 01:10:21 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 09 Feb 2008 00:10:21 -0000
Subject: [New-bugs-announce] [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>


New submission from Tal Einat:

In many places in the code, tkMessageBox dialogs were being used
directly, with the master (parent) widget being set explicitly to the
EditorWindow's text widget. Only in some cases was the focus being set
to the text widget afterwards, although in most this is the Right Thing
To Do.

This patch adds a decorator which wraps a tkMessage box (or similar)
function to use the EditorWindow's text widget as a parent by default
and set focus back to it afterwards. This is used to wrap the showerror
and ask* methods. It also changes the code to use these methods wherever
appropriate.

All in all, the change in functionality is that the dialogs' parent
widget will always be the text widget, and that focus will always be
returned to it. This makes the interface more consistent. As a bonus, a
lot of repetitive cruft is removed from the code, and writing extensions
is made another bit simpler.

----------
components: IDLE
files: IDLE_standardize_dialogs.080208.patch
messages: 62214
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - standardize dialogs
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9394/IDLE_standardize_dialogs.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sat Feb  9 03:16:06 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 09 Feb 2008 02:16:06 -0000
Subject: [New-bugs-announce] [issue2054] add ftp-tls support to ftplib - RFC
	4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

ftplib does not support ftp over SSL / TLS as described in RFC 4217. 
This would be a nice thing for someone wanting to contribute something
to add.

----------
components: Library (Lib)
messages: 62217
nosy: gregory.p.smith
severity: normal
status: open
title: add ftp-tls support to ftplib - RFC 4217
type: rfe
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
__________________________________

From report at bugs.python.org  Sat Feb  9 17:31:35 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 09 Feb 2008 16:31:35 -0000
Subject: [New-bugs-announce] [issue2055] test_fcntl.py converted to unittest
In-Reply-To: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>
Message-ID: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. All existing tests are unchanged.

----------
components: Tests
files: test_fcntl.diff
messages: 62225
nosy: facundobatista, giampaolo.rodola, tiran
severity: normal
status: open
title: test_fcntl.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9397/test_fcntl.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2055>
__________________________________

From report at bugs.python.org  Sun Feb 10 03:05:45 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sun, 10 Feb 2008 02:05:45 -0000
Subject: [New-bugs-announce] [issue2056] install command rejects --compiler
	option
In-Reply-To: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>
Message-ID: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom:

The install command returns the following error when the --compiler
option is provided on the command line:

>python setup.py install --compiler=mingw32
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --compiler not recognized

This is problematic on Windows when MinGW is being used in place of
Visual C. A package can be built with --compiler=mingw32, but if no
compiler is specified for install the following error occurs:

>python setup.py install
running install
running build
running build_py
running build_ext
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin
installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.


The work-around is to specify compiler=mingw32 in a setup.cfg file under
a [build] or [build_ext] heading. But this would be inconvenient for
someone who has both Visual C and MinGW and wants to choose.

----------
components: Distutils
messages: 62241
nosy: kermode
severity: normal
status: open
title: install command rejects --compiler option
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2056>
__________________________________

From report at bugs.python.org  Sun Feb 10 08:32:52 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Feb 2008 07:32:52 -0000
Subject: [New-bugs-announce] [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

difflib alone and bundled Tools\Scripts\diff.py utility are both very
useful, esp. on windows platforms where standard unix diffutils are
absent. However, python difflib still doesn't have a patch counterpart
to apply at least unified diff format.

----------
components: Demos and Tools
messages: 62244
nosy: techtonik
severity: normal
status: open
title: difflib: add patch capability
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
__________________________________

From report at bugs.python.org  Sun Feb 10 12:44:03 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 10 Feb 2008 11:44:03 -0000
Subject: [New-bugs-announce] [issue2058] reduce tarfile memory footprint
In-Reply-To: <1202643843.0.0.134352659823.issue2058@psf.upfronthosting.co.za>
Message-ID: <1202643843.0.0.134352659823.issue2058@psf.upfronthosting.co.za>


New submission from Lars Gust?bel:

tarfile.py wastes lots of memory resources. The memory consumption does
not depend on the size of an archive but on the numbers of members in it.
The attached patch reduces memory usage by about 60% and consists of two
independent strategies (each with about 30% reduction):

1. Add __slots__ to the TarInfo class. This was proposed in issue1540385
a while ago but rejected due to backward-compatibility issues.

2. Remove the undocumented buf attribute of the TarInfo class. buf
stores the original 512-byte header block read from the archive. This
was introduced in r45954 and is rather useless except for GNUTYPE_SPARSE
processing. This might as well be a candidate for backporting to 2.6.

----------
assignee: lars.gustaebel
components: Library (Lib)
files: tarfile-memory.diff
keywords: patch
messages: 62248
nosy: lars.gustaebel
priority: normal
severity: normal
status: open
title: reduce tarfile memory footprint
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file9399/tarfile-memory.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2058>
__________________________________

From report at bugs.python.org  Sun Feb 10 16:55:40 2008
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 10 Feb 2008 15:55:40 -0000
Subject: [New-bugs-announce] [issue2059] OptionMenu class is defined both in
	Tkinter and Tix
In-Reply-To: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za>
Message-ID: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za>


New submission from Ilya Sandler:

Given that Tix imports all names from Tkinter this is likely to result
in confusion.

E.g.

>>> from Tix import *
>>> print Button
Tkinter.Button
>>> print OptionMenu
Tix.OptionMenu

To get to Tkinter's OptionMenu, one needs to do something like

import Tkinter
Tkinter.OptionMenu

----------
components: Library (Lib)
messages: 62250
nosy: isandler
severity: normal
status: open
title: OptionMenu class is defined both in Tkinter and Tix
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2059>
__________________________________

From report at bugs.python.org  Sun Feb 10 23:15:30 2008
From: report at bugs.python.org (Eduardo Padoan)
Date: Sun, 10 Feb 2008 22:15:30 -0000
Subject: [New-bugs-announce] [issue2060] python2.6 -3 gives "warning:
	callable() not supported in 3.x" on startup
In-Reply-To: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>
Message-ID: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>


New submission from Eduardo Padoan:

Running python2.6 with the -3 option, you get 6 warnings about callable():

edcrypt at DEADBEEF:~/dev/svn/python2.6$ python2.6 -3
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
Python 2.6a0 (trunk:60717, Feb 10 2008, 19:53:48) 
[GCC 4.2.3 (Ubuntu 4.2.3-1ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
components: Interpreter Core
messages: 62260
nosy: eopadoan
severity: minor
status: open
title: python2.6 -3 gives "warning: callable() not supported in 3.x" on startup
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2060>
__________________________________

From report at bugs.python.org  Sun Feb 10 23:46:06 2008
From: report at bugs.python.org (Tal Einat)
Date: Sun, 10 Feb 2008 22:46:06 -0000
Subject: [New-bugs-announce] [issue2061] IDLE - autocompletion to support
	alternate patch separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>


New submission from Tal Einat:

This patch makes the auto-completion of file names support possible
alternate separator characters (e.g. '/' in windows).

----------
components: IDLE
files: IDLE_AutoComplete_path_separators.080211.patch
messages: 62263
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - autocompletion to support alternate patch separators
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9400/IDLE_AutoComplete_path_separators.080211.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Mon Feb 11 00:36:53 2008
From: report at bugs.python.org (Tal Einat)
Date: Sun, 10 Feb 2008 23:36:53 -0000
Subject: [New-bugs-announce] [issue2062] IDLE - autocompletion logic
	optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>


New submission from Tal Einat:

Improve the code in AutoCompleteWindow._complete_string to be more
efficient.

(this is to be followed up by a more extensive patch, which builds on
this change to support case-insensitive completion)

----------
components: IDLE
files: IDLE_AutoComplete_complete_string_optimization.080211.patch
messages: 62265
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - autocompletion logic optimization
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9402/IDLE_AutoComplete_complete_string_optimization.080211.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 08:41:37 2008
From: report at bugs.python.org (Kuang-che Wu)
Date: Mon, 11 Feb 2008 07:41:37 -0000
Subject: [New-bugs-announce] [issue2063] os.times() utime and stime
	exchanged on windows
In-Reply-To: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>
Message-ID: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>


New submission from Kuang-che Wu:

According to document, os.times()[0] is process user time, [1] is system
time. However this two value was implemented exchanged on windows.

Python all versions have this issue. Attached patch is for trunk.

----------
components: Extension Modules, Windows
files: diff-win-os-times.txt
messages: 62274
nosy: kcwu
severity: normal
status: open
title: os.times() utime and stime exchanged on windows
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9406/diff-win-os-times.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2063>
__________________________________

From report at bugs.python.org  Mon Feb 11 10:39:52 2008
From: report at bugs.python.org (Heather)
Date: Mon, 11 Feb 2008 09:39:52 -0000
Subject: [New-bugs-announce] [issue2064] List of Dicts problem
In-Reply-To: <1202722792.28.0.719517232523.issue2064@psf.upfronthosting.co.za>
Message-ID: <1202722792.28.0.719517232523.issue2064@psf.upfronthosting.co.za>


New submission from Heather:

I have tried both Python 2.4.4 and 2.5.1 and for both, I get the
following results when running the following code:
IDLE 1.2.1      
>>> class Style:
       stylename=''
       value=''

>>> class Widget:
       styles = {}
       def setStyle(self, stylename, value):
               style = Style()
               style.stylename = stylename
               style.value = value
               self.styles[stylename]=style

>>> class Container:
       widgets = []
       def addWidget(self, stylename, value):
               widget = Widget()
               widget.setStyle(stylename,value)
               self.widgets.append(widget)

>>> container = Container()
>>> container.addWidget('backgroundColor','red')
>>> container.widgets[0].styles['backgroundColor'].value
'red'
>>> container.addWidget('backgroundColor','blue')
>>> container.widgets[0].styles['backgroundColor'].value
'blue'
>>> container.widgets[1].styles['backgroundColor'].value
'blue'
>>> 
If I am doing something wrong here, please let me know. But it seems to
me to be an error that List.append() will overwrite existing entries
when using the code above - - 
Thank you,

-Heather

----------
components: None
messages: 62275
nosy: sunaluak
severity: major
status: open
title: List of Dicts problem
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2064>
__________________________________

From report at bugs.python.org  Mon Feb 11 11:50:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 Feb 2008 10:50:39 -0000
Subject: [New-bugs-announce] [issue2065] trunk version does not compile with
	vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

Since r60696, WINVER is forced to _WIN32_WINNT_WIN2K. This has two problems:
- Vs8 (and before) does not define _WIN32_WINNT_WIN2K. It should be
replaced with 0x500.
- When WINVER is set to 0x500, vc6 gives a long warning because at the
time, windows nt 5.0 was only at beta stage. Moreover, there are other
clashes between winsock.h and winsock2.h, that show up when WINVER is 0x500.

To correct this, I propose:
- To replace _WIN32_WINNT_WIN2K and similar constants by their values.
- That 0x500 is not the required value, but the *maximum* value
necessary when targeting win2k. VC6 can set it to 0x400.

I'll try a patch later tonight.

----------
components: Windows
messages: 62276
nosy: amaury.forgeotdarc
severity: normal
status: open
title: trunk version does not compile with vs8 and vc6
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:58:54 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Mon, 11 Feb 2008 11:58:54 -0000
Subject: [New-bugs-announce] [issue2066] Adding new CNS11643 support,
	a *huge* charset, in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>


New submission from Hye-Shik Chang:

This patch adds CNS11643 support into Python unicode codecs.
CNS11643 is a huge character which is used in EUC-TW and ISO-2022-CN.
CJKCodecs have had the CNS11643 support for 4 years at least,
but I dropped it because of its huge size in integrating into Python.
EUC-TW and ISO-2022-CN aren't being used widely while they are
still regarded as part of major encodings yet.

In my patch, disabling the CNS11643 charset support is possible by
adding -DNO_CNS11643 in CFLAGS for light platforms. Mapping source
code size of the charset is 900K and it adds about 350K into
_codecs_tw.so (in POSIX) or python26.dll (in Win32).

What do you think about adding this code?

----------
components: Unicode
files: cns11643-r1.diff.gz
messages: 62282
nosy: hyeshik.chang
priority: low
severity: normal
status: open
title: Adding new CNS11643 support, a *huge* charset, in cjkcodecs
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9408/cns11643-r1.diff.gz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Mon Feb 11 16:11:55 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Feb 2008 15:11:55 -0000
Subject: [New-bugs-announce] [issue2067] file.__exit__ does not call
	subclass' close method
In-Reply-To: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>
Message-ID: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Attached patch makes file.__exit__ call subclass' close method.

----------
components: Interpreter Core
files: file_exit.diff
messages: 62289
nosy: belopolsky
severity: normal
status: open
title: file.__exit__ does not call subclass' close method
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9410/file_exit.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2067>
__________________________________

From report at bugs.python.org  Mon Feb 11 20:09:29 2008
From: report at bugs.python.org (Stefan Schwarzburg)
Date: Mon, 11 Feb 2008 19:09:29 -0000
Subject: [New-bugs-announce] [issue2072] SimpleXMLRPCServer documentation
	about rpc_paths might be wrong
In-Reply-To: <1202756969.25.0.603492596378.issue2072@psf.upfronthosting.co.za>
Message-ID: <1202756969.25.0.603492596378.issue2072@psf.upfronthosting.co.za>


New submission from Stefan Schwarzburg:

In the documentation for SimpleXMLRPCServer
(http://docs.python.org/lib/simple-xmlrpc-servers.html)it is said, that
the SimpleXMLRPCServer object has an attribute "rpc_paths" that could be
set to  valid path portions.
This would mean that changing the example code on the same page by
adding a line like:
[...] 
server = SimpleXMLRPCServer(("localhost", 8000))
server.rpc_paths = ('/test')
[...]
would result in a call to 'http://localhost:8000/test' be processed
correctly. But this is not the case.
The server object has no attribute 'rpc_paths' nor does creating an
attribute like this change anything.

What however works is a line like this:
[...]
server.RequestHandlerClass.rpc_paths = ('/test')
[...]

The reason for this is that the test 'is_rpc_path_valid' is a method of
the class SimpleXMLRPCRequestHandler which tests if the path is in  the
class attribute 'rpc_paths' of SimpleXMLRPCRequestHandler. This class is
saved as RequestHandlerClass in SimpleXMLRPCServer. 

So the behavior of the code is understandable but is not described by
the documentation.

----------
components: Documentation
files: SimpleXMLRPCServerTEST.tgz
messages: 62291
nosy: schwarz
severity: normal
status: open
title: SimpleXMLRPCServer documentation about  rpc_paths might be wrong
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9412/SimpleXMLRPCServerTEST.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2072>
__________________________________

From report at bugs.python.org  Mon Feb 11 23:17:32 2008
From: report at bugs.python.org (Mike Coleman)
Date: Mon, 11 Feb 2008 22:17:32 -0000
Subject: [New-bugs-announce] [issue2073] asynchat push always sends 512
	bytes (ignoring ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>


New submission from Mike Coleman:

In asynchat, 'push' doesn't specify 'buffer_size', so the default of 512
is used.  This is bogus and causes poor performance--it should use the
value of 'ac_out_buffer_size' instead.

----------
components: Library (Lib)
messages: 62294
nosy: mkc
severity: normal
status: open
title: asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
__________________________________

From report at bugs.python.org  Tue Feb 12 03:47:19 2008
From: report at bugs.python.org (Simon Percivall)
Date: Tue, 12 Feb 2008 02:47:19 -0000
Subject: [New-bugs-announce] [issue2074] pprint._safe_repr() unsafe on
	ordering differently types objects with same str represenation
In-Reply-To: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za>
Message-ID: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za>


New submission from Simon Percivall:

_safe_repr() tries to handle the case where two objects are unorderable by 
ordering on (str(type(key)), key, value), but this fails when 
str(type(key)) is equal for two objects, but key is different and 
unorderable. Easy fix: order just on the string representation.

----------
components: Library (Lib)
files: pprint.diff
messages: 62303
nosy: percivall
severity: normal
status: open
title: pprint._safe_repr() unsafe on ordering differently types objects with same str represenation
versions: Python 3.0
Added file: http://bugs.python.org/file9413/pprint.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2074>
__________________________________

From report at bugs.python.org  Tue Feb 12 06:36:04 2008
From: report at bugs.python.org (will)
Date: Tue, 12 Feb 2008 05:36:04 -0000
Subject: [New-bugs-announce] [issue2075] Float number comparision problem
In-Reply-To: <1202794564.07.0.200566904668.issue2075@psf.upfronthosting.co.za>
Message-ID: <1202794564.07.0.200566904668.issue2075@psf.upfronthosting.co.za>


New submission from will:

c=22.99*5.0
print c==114.95
"""This will produce false"""

c=22.99*4.0
print c==91.96
"""This will produce true"""

"""This is not expected behavior for python"""

----------
components: Interpreter Core, Library (Lib)
messages: 62306
nosy: tsxy
severity: normal
status: open
title: Float number comparision problem
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2075>
__________________________________

From report at bugs.python.org  Tue Feb 12 12:04:12 2008
From: report at bugs.python.org (Erno Kuusela)
Date: Tue, 12 Feb 2008 11:04:12 -0000
Subject: [New-bugs-announce] [issue2076] xmlrpclib closes connection after
	each call
In-Reply-To: <1202814252.95.0.393197834217.issue2076@psf.upfronthosting.co.za>
Message-ID: <1202814252.95.0.393197834217.issue2076@psf.upfronthosting.co.za>


New submission from Erno Kuusela:

xmlrpclib is using the old HTTP and HTTPS classes from httplib which are
to quote the docstring, "Compatibility classes with httplib.py from 1.5."
and force the use of HTTP 1.0. This prevents connection reuse and
pipelining.

Attacked is some code we are using as a workaround.

Is the xmlrpclib in the standard library required to keep compatibility
with old python versions?

----------
components: Library (Lib)
files: transport.py
messages: 62309
nosy: erno
severity: normal
status: open
title: xmlrpclib closes connection after each call
versions: Python 2.5
Added file: http://bugs.python.org/file9414/transport.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2076>
__________________________________

From report at bugs.python.org  Tue Feb 12 12:50:25 2008
From: report at bugs.python.org (Rupert Summerton)
Date: Tue, 12 Feb 2008 11:50:25 -0000
Subject: [New-bugs-announce] [issue2077] Interpreter crash on shutdown
In-Reply-To: <1202817025.41.0.0817912479052.issue2077@psf.upfronthosting.co.za>
Message-ID: <1202817025.41.0.0817912479052.issue2077@psf.upfronthosting.co.za>


New submission from Rupert Summerton:

1. Description: The Python interpretor is crashing on shutdown due to a
segmentation fault:

Unhandled exception at 0x1e03d41f in python.exe: 0xC0000005: Access
violation reading location 0x0000002c.

2. Reproducibility: At least 10% on Windows XP Professional SP2, P4
3.20GHz, 2.00GB RAM, when running the attached module, threadpool.py.
(Running with Python 2.5.1). Unfortunately I cannot get the attached
test case to crash on Linux or Solaris. However, executing this code as
part of our Python test framework (see context below), with Python
2.4.1, what looks like the same crash produced the following backtrace:

#0  reset_exc_info (tstate=0x8254458) at
/tools/src/python/python-2.4.1/Python/ceval.c:2861
        tstate = (PyThreadState *) 0x8254458
        frame = (PyFrameObject *) 0x0
        tmp_type = (PyObject *) 0x82a3a18
        tmp_value = (PyObject *) 0x0
        tmp_tb = (PyObject *) 0x2
#1  0x080a9b56 in PyEval_EvalFrame (f=0x82a38ac) at
/tools/src/python/python-2.4.1/Python/ceval.c:2490
        stack_pointer = (PyObject **) 0x82a3a18
        next_instr = (unsigned char *) 0x81d4f1e ""
        opcode = 136660056
        oparg = 0
        why = WHY_RETURN
        err = 0
        x = (PyObject *) 0x810d940
        v = (PyObject *) 0x81d4f1e
        w = (PyObject *) 0xf6462fc0
        u = (PyObject *) 0xf642ec50
        t = (PyObject *) 0x0
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82a39f8
        freevars = (PyObject **) 0x82a3a18
        retval = (PyObject *) 0x810d940
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf6134c60
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81d4d9c "|"
        names = (PyObject *) 0xf63d762c
        consts = (PyObject *) 0xf6134c2c
#2  0x080aa263 in PyEval_EvalCodeEx (co=0xf6134c60, globals=0xf6075824,
locals=0x0, args=0x82c1080, argcount=2, kws=0x82c1088, kwcount=0,
defs=0xf6414298, 
    defcount=1, closure=0x0) at
/tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf6134c60
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0x82c1080
        argcount = 2
        kws = (PyObject **) 0x82c1088
        kwcount = 0
        defs = (PyObject **) 0xf6414298
        defcount = 1
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x82a38ac
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82a39f8
        freevars = (PyObject **) 0x82a3a18
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x82a38ac
#3  0x080acda7 in fast_function (func=0xf613e8b4, pp_stack=0xe951f3dc,
n=2, na=2, nk=0) at /tools/src/python/python-2.4.1/Python/ceval.c:3643
        func = (PyObject *) 0x82a38ac
        co = (PyCodeObject *) 0x8254458
        globals = (PyObject *) 0xf6075824
        argdefs = (PyObject *) 0x8254458
        d = (PyObject **) 0xf6414298
        nd = 1
#4  0x080ab08a in call_function (pp_stack=0xe951f3dc, oparg=1) at
/tools/src/python/python-2.4.1/Python/ceval.c:3568
        oparg = 136660056
        na = 2
        nk = 0
        n = 2
        pfunc = (PyObject **) 0x82c1080
        func = (PyObject *) 0xf613e8b4
        x = (PyObject *) 0x8172f54
        w = (PyObject *) 0x82a38ac
#5  0x080a9338 in PyEval_EvalFrame (f=0x82c0f1c) at
/tools/src/python/python-2.4.1/Python/ceval.c:2163
        sp = (PyObject **) 0x82c1088
        stack_pointer = (PyObject **) 0x82c1088
        next_instr = (unsigned char *) 0x81f58cc "\001q\225"
        opcode = 136660056
        oparg = 1
        why = WHY_NOT
        err = 0
        x = (PyObject *) 0x82a37ec
        v = (PyObject *) 0x81f58cc
        w = (PyObject *) 0xf6444de0
        u = (PyObject *) 0xf642ec50
        t = (PyObject *) 0x1
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82c1068
        freevars = (PyObject **) 0x82c1080
        retval = (PyObject *) 0x0
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf618c920
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81f57f4 "|"
        names = (PyObject *) 0xf63a484c
        consts = (PyObject *) 0xf6164a1c
#6  0x080aa263 in PyEval_EvalCodeEx (co=0xf618c920, globals=0xf5d658ac,
locals=0x0, args=0x827d690, argcount=1, kws=0x827d694, kwcount=1,
defs=0xf5d77e78, 
    defcount=2, closure=0x0) at
/tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf618c920
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0x8136f18
        argcount = 1
        kws = (PyObject **) 0x827d694
        kwcount = 1
        defs = (PyObject **) 0xf5d77e78
        defcount = 2
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x82c0f1c
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82c1068
        freevars = (PyObject **) 0x82c1080
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x82c0f1c
#7  0x080acda7 in fast_function (func=0xf616af7c, pp_stack=0xe951f5ac,
n=3, na=1, nk=1) at /tools/src/python/python-2.4.1/Python/ceval.c:3643
        func = (PyObject *) 0x82a38ac
        co = (PyCodeObject *) 0x8254458
        globals = (PyObject *) 0xf5d658ac
        argdefs = (PyObject *) 0x8254458
        d = (PyObject **) 0xf5d77e78
        nd = 2
#8  0x080ab08a in call_function (pp_stack=0xe951f5ac, oparg=256) at
/tools/src/python/python-2.4.1/Python/ceval.c:3568
        oparg = 136660056
        na = 1
        nk = 1
        n = 3
        pfunc = (PyObject **) 0x827d690
        func = (PyObject *) 0xf616af7c
        x = (PyObject *) 0x81284cc
        w = (PyObject *) 0x82a38ac
#9  0x080a9338 in PyEval_EvalFrame (f=0x827d534) at
/tools/src/python/python-2.4.1/Python/ceval.c:2163
        sp = (PyObject **) 0x827d69c
        stack_pointer = (PyObject **) 0x827d69c
        next_instr = (unsigned char *) 0x81f9e53 "}\002"
        opcode = 136660056
        oparg = 256
        why = WHY_NOT
        err = 0
        x = (PyObject *) 0x8136f18
        v = (PyObject *) 0x81f9e53
        w = (PyObject *) 0xf63cabe0
        u = (PyObject *) 0x18c
        t = (PyObject *) 0x100
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827d680
        freevars = (PyObject **) 0x827d690
        retval = (PyObject *) 0x0
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf613f8a0
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81f9d6c "z\n\003y?\002x?\002|"
        names = (PyObject *) 0xf63cc8c4
        consts = (PyObject *) 0xf6165e9c
#10 0x080acd43 in fast_function (func=0xf6171064, pp_stack=0xe951f6ec,
n=1, na=1, nk=0) at /tools/src/python/python-2.4.1/Python/ceval.c:3629
        retval = (PyObject *) 0x827d680
        fastlocals = (PyObject **) 0x827d680
        i = 136660056
        f = (PyFrameObject *) 0x827d534
        tstate = (PyThreadState *) 0x8254458
        stack = (PyObject **) 0x82a38ac
        func = (PyObject *) 0x82a38ac
        co = (PyCodeObject *) 0x8254458
        globals = (PyObject *) 0x827d680
        argdefs = (PyObject *) 0x8254458
        d = (PyObject **) 0x8254458
        nd = 0
#11 0x080ab08a in call_function (pp_stack=0xe951f6ec, oparg=0) at
/tools/src/python/python-2.4.1/Python/ceval.c:3568
        oparg = 136660056
        na = 1
        nk = 0
        n = 1
        pfunc = (PyObject **) 0x827b2a8
        func = (PyObject *) 0xf6171064
        x = (PyObject *) 0x7f
        w = (PyObject *) 0x82a38ac
#12 0x080a9338 in PyEval_EvalFrame (f=0x827b14c) at
/tools/src/python/python-2.4.1/Python/ceval.c:2163
        sp = (PyObject **) 0x827b2ac
        stack_pointer = (PyObject **) 0x827b2ac
        next_instr = (unsigned char *) 0x81d4b2f "\001Wn)\001\004t\021"
        opcode = 136660056
        oparg = 0
        why = WHY_NOT
        err = 0
        x = (PyObject *) 0xf5e7cd4c
        v = (PyObject *) 0x81d4b2f
        w = (PyObject *) 0xf61360e0
        u = (PyObject *) 0xf5e87f4c
        t = (PyObject *) 0x0
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827b298
        freevars = (PyObject **) 0x827b2a8
        retval = (PyObject *) 0x0
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf61386e0
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81d4a84 "z?\001t"
        names = (PyObject *) 0xf643295c
        consts = (PyObject *) 0xf613a0cc
#13 0x080aa263 in PyEval_EvalCodeEx (co=0xf61386e0, globals=0xf6075824,
locals=0x0, args=0xf5de6f38, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, 
    closure=0x0) at /tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf61386e0
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0xf5de6f38
        argcount = 1
        kws = (PyObject **) 0x0
        kwcount = 0
        defs = (PyObject **) 0x0
        defcount = 0
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x827b14c
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827b298
        freevars = (PyObject **) 0x827b2a8
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x827b14c
#14 0x080ee2b7 in function_call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/funcobject.c:548
        result = (PyObject *) 0x0
        argdefs = (PyObject *) 0x0
        d = (PyObject **) 0x0
        k = (PyObject **) 0x0
        nk = 136660056
        nd = 0
#15 0x0805a7f4 in PyObject_Call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf5de6f2c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
#16 0x08061497 in instancemethod_call (func=0xf613edbc, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/classobject.c:2431
        arg = (PyObject *) 0xf5de6f2c
        self = (PyObject *) 0x0
        class = (PyObject *) 0xf5de6f2c
        result = (PyObject *) 0xf5de6f2c
#17 0x0805a7f4 in PyObject_Call (func=0xf5e858c4, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf642902c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
        co = (PyCodeObject *) 0xf61386e0
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81d4a84 "z?\001t"
        names = (PyObject *) 0xf643295c
        consts = (PyObject *) 0xf613a0cc
#13 0x080aa263 in PyEval_EvalCodeEx (co=0xf61386e0, globals=0xf6075824,
locals=0x0, args=0xf5de6f38, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, 
    closure=0x0) at /tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf61386e0
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0xf5de6f38
        argcount = 1
        kws = (PyObject **) 0x0
        kwcount = 0
        defs = (PyObject **) 0x0
        defcount = 0
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x827b14c
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827b298
        freevars = (PyObject **) 0x827b2a8
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x827b14c
#14 0x080ee2b7 in function_call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/funcobject.c:548
        result = (PyObject *) 0x0
        argdefs = (PyObject *) 0x0
        d = (PyObject **) 0x0
        k = (PyObject **) 0x0
        nk = 136660056
        nd = 0
#15 0x0805a7f4 in PyObject_Call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf5de6f2c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
#16 0x08061497 in instancemethod_call (func=0xf613edbc, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/classobject.c:2431
        arg = (PyObject *) 0xf5de6f2c
        self = (PyObject *) 0x0
        class = (PyObject *) 0xf5de6f2c
        result = (PyObject *) 0xf5de6f2c
#17 0x0805a7f4 in PyObject_Call (func=0xf5e858c4, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf642902c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
---Type <return> to continue, or q <return> to quit---
#18 0x080ac52b in PyEval_CallObjectWithKeywords (func=0xf5e858c4,
arg=0xf642902c, kw=0x0) at
/tools/src/python/python-2.4.1/Python/ceval.c:3419
        arg = (PyObject *) 0xf642902c
        kw = (PyObject *) 0x0
        result = (PyObject *) 0x0
#19 0x080d0c86 in t_bootstrap (boot_raw=0x82543f8) at
/tools/src/python/python-2.4.1/Modules/threadmodule.c:432
        boot_raw = (void *) 0x82543f8
        gstate = PyGILState_UNLOCKED
        res = (PyObject *) 0x82a38ac
#20 0xf65cede8 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
#21 0xf654693a in clone () from /lib/tls/libc.so.6


3. Context: We have an automated test framework written in Python. To
speed up execution it has been multi-threaded so that tests can be run
in parallel. Rather than re-invent the wheel we simply used this
threadpool (http://chrisarndt.de/en/software/python/threadpool/), work
requests essentially being calls to a method that runs an individual
test case. However, we have substantially modified the code to add
functionality. Specifically, we need to find a way to limit the number
of tests that can run concurrently because: (1) different tests place
different loads on a machine, and (2) different machines have different
capacities (CPUs, memory, etc.).  We do this by associating a cost with
each work request, and by using the number of CPUs on the machine as a
limit (crude, but reasonably effective) -- if running the next job would
exceed the cost limit, the thread sleeps, and then checks again. In
order to verify that this cost logic works, we have also added some
logging code that can be activated by setting a flag. The other
significant modification has been to extend the Python Queue module to
add a peek method, because peeking at the front of the job queue to
determine the cost of the next job, and not removing it until there is
sufficient capacity to run it, speeds up the execution of tests. The
crash in the Python interpretor occurs only when (1) the cost logging is
switched on AND (2) the module peekablequeue is used instead of the
built in Queue module. I am quite willing to believe that these
modifications could be better implemented, but however bad the code, the
Python interpretor should not crash.

----------
components: Interpreter Core
files: python_crash_test.zip
messages: 62310
nosy: rupert.summerton
severity: normal
status: open
title: Interpreter crash on shutdown
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9415/python_crash_test.zip

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2077>
__________________________________

From report at bugs.python.org  Tue Feb 12 17:02:12 2008
From: report at bugs.python.org (Jean-Philippe Laverdure)
Date: Tue, 12 Feb 2008 16:02:12 -0000
Subject: [New-bugs-announce] [issue2078] CSV Sniffer does not function
	properly on single column .csv files
In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za>
Message-ID: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za>


New submission from Jean-Philippe Laverdure:

When attempting to sniff() the dialect for the attached .csv file,
csv.Sniffer.sniff() returns an unusable dialect:

>>> import csv
>>> file = open('listB2Mforblast.csv', 'r')
>>> dialect = csv.Sniffer().sniff(file.readline())
>>> file.seek(0)
>>> file.readline()
>>> file.seek(0)
>>> reader = csv.DictReader(file, dialect)
>>> reader.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/soft/bioinfo/linux/python-2.5/lib/python2.5/csv.py", line 93,
in next
    d = dict(zip(self.fieldnames, row))
TypeError: zip argument #1 must support iteration

However, this works fine:
>>> file.seek(0)
>>> reader = csv.DictReader(file)
>>> reader.next()
{'Sequence': 'AALENTHLL'}

If I use a 2 column file, sniff() works perfectly.
It only seems to have a problem with single column .csv files (which are
still .csv files in my opinion)

Thanks for looking into this.

----------
components: Extension Modules
files: listB2Mforblast.csv
messages: 62319
nosy: jplaverdure
severity: normal
status: open
title: CSV Sniffer does not function properly on single column .csv files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9416/listB2Mforblast.csv

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2078>
__________________________________

From report at bugs.python.org  Tue Feb 12 17:29:03 2008
From: report at bugs.python.org (Gabriel Sean Farrell)
Date: Tue, 12 Feb 2008 16:29:03 -0000
Subject: [New-bugs-announce] [issue2079] UserDict documentation typo
In-Reply-To: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>
Message-ID: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>


New submission from Gabriel Sean Farrell:

2nd paragraph of documentation at
http://docs.python.org/lib/module-UserDict.html should read as follows:

This module also defines a class...

The "also" is out of place.

----------
components: Documentation
messages: 62322
nosy: gsf
severity: minor
status: open
title: UserDict documentation typo
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2079>
__________________________________

From report at bugs.python.org  Tue Feb 12 18:19:52 2008
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 12 Feb 2008 17:19:52 -0000
Subject: [New-bugs-announce] [issue2085] Syntax for property set method
In-Reply-To: <1202836792.56.0.267768565577.issue2085@psf.upfronthosting.co.za>
Message-ID: <1202836792.56.0.267768565577.issue2085@psf.upfronthosting.co.za>


New submission from David W. Lambert:

# proposed syntax:
# object.property = *args,**kwargs

# python 3k could accept property setter with multiple arguments

class c:
    def f(self,a,b,c):
        print a,b,c
    F=property(None,f)

c().F=*'hi',**{'c':'third setter argument'}

----------
components: None
messages: 62323
nosy: LambertDW
severity: minor
status: open
title: Syntax for property set method
type: rfe
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2085>
__________________________________

From report at bugs.python.org  Tue Feb 12 21:50:37 2008
From: report at bugs.python.org (hauser)
Date: Tue, 12 Feb 2008 20:50:37 -0000
Subject: [New-bugs-announce] [issue2090] __import__ with fromlist=['']
	causes double initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>


New submission from hauser:

This construction:

__import__( 'pkg', {}, {}, [''] )

Will cause double initialization of package 'pkg', once with name 'pkg'
and second one with name 'pkg.' (trailing dot). Implementation tries to
import subpackage of 'pkg' with empty name, and imports the same package
twice.

This kind of construction is used as a hacky way to obtain exact module
instead of top-level module in return value. It is a hack, but should
not cause this kind of side effects.

----------
components: Interpreter Core
files: empty_import.tgz
messages: 62333
nosy: hauser
severity: minor
status: open
title: __import__ with fromlist=[''] causes double initialization of modules
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9420/empty_import.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:55:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2008 22:55:09 -0000
Subject: [New-bugs-announce] [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The docs on file's constructor says that the 'U' mode should not work
with '+', and yet 'rU+' does not throw an error.

----------
components: Interpreter Core
messages: 62343
nosy: brett.cannon
severity: normal
status: open
title: file accepts 'rU+' as a mode
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
__________________________________

From report at bugs.python.org  Wed Feb 13 03:37:04 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 13 Feb 2008 02:37:04 -0000
Subject: [New-bugs-announce] [issue2092] PEP-3100 should reflect removal of
	'cmp' parameter in sort() and sorted()
In-Reply-To: <1202870223.96.0.851994555787.issue2092@psf.upfronthosting.co.za>
Message-ID: <1202870223.96.0.851994555787.issue2092@psf.upfronthosting.co.za>


New submission from Kurt B. Kaiser:

Document the decision to remove the comparision ('cmp') 
parameter from list.sort() and builtin.sorted()

----------
assignee: rhettinger
components: Documentation
files: pep-3100.patch
messages: 62346
nosy: kbk, rhettinger
priority: normal
severity: normal
status: open
title: PEP-3100 should reflect removal of 'cmp' parameter in sort() and sorted()
versions: Python 3.0
Added file: http://bugs.python.org/file9422/pep-3100.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2092>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:03:32 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 13 Feb 2008 06:03:32 -0000
Subject: [New-bugs-announce] [issue2096] Reporting bugs page refers to old
	site
In-Reply-To: <1202882612.84.0.928632969277.issue2096@psf.upfronthosting.co.za>
Message-ID: <1202882612.84.0.928632969277.issue2096@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich:

http://www.python.org/doc/ext/reporting-bugs.html refers to
http://sourceforge.net/bugs/?group_id=5470 instead  of
http://bugs.python.org

----------
components: Documentation
messages: 62347
nosy: Yinon
severity: minor
status: open
title: Reporting bugs page refers to old site
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2096>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:05:05 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 13 Feb 2008 06:05:05 -0000
Subject: [New-bugs-announce] [issue2097] typo in exception-handling tutorial
In-Reply-To: <1202882705.49.0.845697699561.issue2097@psf.upfronthosting.co.za>
Message-ID: <1202882705.49.0.845697699561.issue2097@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich:

At http://docs.python.org/tut/node10.html#SECTION0010300000000000000000
there is "One my also instantiate" instead of "One may also instantiate"

----------
components: Documentation
messages: 62348
nosy: Yinon
severity: normal
status: open
title: typo in exception-handling tutorial
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2097>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:07:05 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 13 Feb 2008 06:07:05 -0000
Subject: [New-bugs-announce] [issue2099] unclear error message on bug
	reporting
In-Reply-To: <1202882825.69.0.96074029618.issue2099@psf.upfronthosting.co.za>
Message-ID: <1202882825.69.0.96074029618.issue2099@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich:

When filing a new bug on http://bugs.python.org/issue and not filling
the "Change Note" the following message appears: "Error: list index out
of range"... instead of "please fill the change notes" or something alike...

----------
messages: 62349
nosy: Yinon
severity: normal
status: open
title: unclear error message on bug reporting
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2099>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:21:04 2008
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 13 Feb 2008 14:21:04 -0000
Subject: [New-bugs-announce] [issue2100] unit test UnicodeWarning
In-Reply-To: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za>
Message-ID: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

I receive the following warning when running the test_unicode_file unit
tests out of the trunk (60758)

python  -E -tt ../../lib/test/regrtest.py -g "test_unicode_file"
test_unicode_file
D:\work\pytrunk\lib\test\test_unicode_file.py:103: UnicodeWarning:
Unicode equal comparison failed to convert both arguments to Unicode -
interpreting them as being unequal
  filename1==filename2
D:\work\pytrunk\lib\shutil.py:36: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  os.path.normcase(os.path.abspath(dst)))
1 test OK.

It looks like the warning was meant to be suppressed in
test_unicode_file.py line 104:

# Try using shutil on the filenames.
try:
    filename1==filename2
except UnicodeDecodeError:
    # these filenames can't be compared - shutil.copy tries to do
    # just that.  This is really a bug in 'shutil' - if one of shutil's
    # 2 params are Unicode and the other isn't, it should coerce the
    # string to Unicode with the filesystem encoding before comparison.
    pass


This does not handle the UnicodeWarning, was it meant to?

----------
components: Tests
messages: 62358
nosy: JosephArmbruster
severity: normal
status: open
title: unit test UnicodeWarning
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2100>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:37:14 2008
From: report at bugs.python.org (Stefan Seefeld)
Date: Wed, 13 Feb 2008 14:37:14 -0000
Subject: [New-bugs-announce] [issue2101] xml.dom documentation doesn't match
	implementation
In-Reply-To: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>
Message-ID: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

The docs at http://docs.python.org/lib/dom-element-objects.html
claim that removeAttribute(name) silently ignores the attempt to
remove an unknown attribute. However, the current implementation
in the minidom module (part of _xmlplus) raises an xml.dom.NotFoundErr
exception.

----------
components: Documentation, XML
messages: 62359
nosy: stefan
severity: normal
status: open
title: xml.dom documentation doesn't match implementation
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2101>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:51:15 2008
From: report at bugs.python.org (Wummel)
Date: Wed, 13 Feb 2008 14:51:15 -0000
Subject: [New-bugs-announce] [issue2102] New style classes __ror__()
	operator overloading problem
In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>
Message-ID: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>


New submission from Wummel:

Hi,

the attached code in t.py fails to run:
class C (object):
    def __ror__ (self, other):
        return 42
print C() | C()

$ python t.py
Traceback (most recent call last):
  File "t.py", line 5, in ?
    print C() | C()
TypeError: unsupported operand type(s) for |: 'C' and 'C'

If I use old style classes (ie. "class C:" instead of "class
C(object):"), the code runs fine. I suspect that the method lookup for
special operator methods is different in new style classes, but why?
This might also be related to issue #643841 but I am not sure.

----------
components: Interpreter Core
files: t.py
messages: 62361
nosy: calvin
severity: normal
status: open
title: New style classes __ror__()  operator overloading problem
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9425/t.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2102>
__________________________________

From report at bugs.python.org  Wed Feb 13 19:41:32 2008
From: report at bugs.python.org (bob gailer)
Date: Wed, 13 Feb 2008 18:41:32 -0000
Subject: [New-bugs-announce] [issue2103] __x should be _x in documentation
	of property()
In-Reply-To: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>
Message-ID: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>


New submission from bob gailer:

Library Reference 2.1 under property():

class C(object):
   def __init__(self): self.__x = None

__x should be _x

----------
components: Documentation
messages: 62368
nosy: bgailer
severity: normal
status: open
title: __x should be _x in documentation of property()
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2103>
__________________________________

From report at bugs.python.org  Thu Feb 14 09:01:35 2008
From: report at bugs.python.org (susanna)
Date: Thu, 14 Feb 2008 08:01:35 -0000
Subject: [New-bugs-announce] [issue2109] ?
In-Reply-To: <1202976095.92.0.353026153278.issue2109@psf.upfronthosting.co.za>
Message-ID: <1202976095.92.0.353026153278.issue2109@psf.upfronthosting.co.za>


New submission from susanna:

question: 
i open python and type: 

from pylab import *
plot([1,2,3,4])
show()

an EMPTY gui pops up, the line is not plotted.
why?

this is on MAC OSX 10.4.11

----------
messages: 62381
nosy: susanna
severity: normal
status: open
title: ?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2109>
__________________________________

From report at bugs.python.org  Thu Feb 14 14:04:15 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Feb 2008 13:04:15 -0000
Subject: [New-bugs-announce] [issue2110] Implement __format__ for Decimal
In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>
Message-ID: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>


New submission from Facundo Batista:

A remainder.

----------
assignee: facundobatista
components: Library (Lib)
messages: 62389
nosy: facundobatista
severity: normal
status: open
title: Implement __format__ for Decimal
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2110>
__________________________________

From report at bugs.python.org  Thu Feb 14 15:40:04 2008
From: report at bugs.python.org (Thomas Herve)
Date: Thu, 14 Feb 2008 14:40:04 -0000
Subject: [New-bugs-announce] [issue2111] mmap segfaults when trying to write
	a block opened with PROT_READ
In-Reply-To: <1203000004.58.0.354729016159.issue2111@psf.upfronthosting.co.za>
Message-ID: <1203000004.58.0.354729016159.issue2111@psf.upfronthosting.co.za>


New submission from Thomas Herve:

Basically, the write method of mmap objects check the state with
is_writable, which check the writability with the access attributes. But
the mmap object can be opened correctly specifying the rights with
prot=mmap.PROt_READ.

Attached patch corrects the problem by setting access to ACCESS_READ
with prot is set to PROT_READ, with a test.

----------
components: Library (Lib)
files: mmap.diff
messages: 62390
nosy: therve
severity: normal
status: open
title: mmap segfaults when trying to write a block opened with PROT_READ
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9429/mmap.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2111>
__________________________________

From report at bugs.python.org  Thu Feb 14 15:57:50 2008
From: report at bugs.python.org (Thomas Herve)
Date: Thu, 14 Feb 2008 14:57:50 -0000
Subject: [New-bugs-announce] [issue2112] mmap.error should be a subclass of
	EnvironmentError and not a direct EnvironmentError
In-Reply-To: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>
Message-ID: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>


New submission from Thomas Herve:

mmap.error in mmapmodule is a direct reference to
PyExc_EnvironmentError, whereas it should be a subclass. It makes it
provide a specific string representation, and allows to be more specific
when catching exceptions.

The attached patch tries to provide that.

----------
components: Library (Lib)
files: mmap2.diff
messages: 62391
nosy: therve
severity: normal
status: open
title: mmap.error should be a subclass of EnvironmentError and not a direct EnvironmentError
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9430/mmap2.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2112>
__________________________________

From report at bugs.python.org  Thu Feb 14 16:39:03 2008
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 14 Feb 2008 15:39:03 -0000
Subject: [New-bugs-announce] [issue2113] Bad interaction between signal and
	subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

During Popen.communicate(), if a signal is caught during the select(),
an unhandled exception is raised, and the output gathered is lost.

This means that a long running or hanged process can't be killed after a
timeout (as shown in the attached example, where the output collected
before the signal is valuable)

The bug happens only when stdout and stderr are not merged and is tested
on linux platform.

----------
files: subprocess_signal_bug.py
messages: 62392
nosy: piro
severity: normal
status: open
title: Bad interaction between signal and subprocess
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9431/subprocess_signal_bug.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:17:28 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 14 Feb 2008 16:17:28 -0000
Subject: [New-bugs-announce] [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

test_decimal fails on Mac OS X 10.3 when using Python 2.5.2c1. I haven't 
tested other python versions. The same test passes on OSX 10.4 and 10.5 
(both on Intel and PPC machines), this was done using the same binaries 
(the Python.org build for 2.5.2c1).

The end of the output of "python test_decimal.py" is:


======================================================================
FAIL: test_normalize (__main__.DecimalTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_decimal.py", line 1351, in <lambda>
    tester = lambda self, f=filename: self.eval_file(directory + f)
  File "test_decimal.py", line 213, in eval_file
    self.fail('Exception "'+exception.__class__.__name__ + '" raised on 
line '+line)
AssertionError: Exception "Clamped" raised on line nrmx218 normalize  
0.001E-999       ->   0         Inexact Rounded Subnormal Underflow

----------------------------------------------------------------------
Ran 189 tests in 35.947s

FAILED (failures=1)
Traceback (most recent call last):
  File "test_decimal.py", line 1376, in <module>
    test_main(arith=True, verbose=True)
  File "test_decimal.py", line 1357, in test_main
    run_unittest(*test_classes)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/test/te
st_support.py", line 451, in run_unittest
    run_suite(suite, testclass)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/test/te
st_support.py", line 436, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "test_decimal.py", line 1351, in <lambda>
    tester = lambda self, f=filename: self.eval_file(directory + f)
  File "test_decimal.py", line 213, in eval_file
    self.fail('Exception "'+exception.__class__.__name__ + '" raised on 
line '+line)
AssertionError: Exception "Clamped" raised on line nrmx218 normalize  
0.001E-999       ->   0         Inexact Rounded Subnormal Underflow

----------
components: Library (Lib)
messages: 62395
nosy: ronaldoussoren
severity: normal
status: open
title: test_decimal failure on OSX 10.3
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 19:01:38 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 14 Feb 2008 18:01:38 -0000
Subject: [New-bugs-announce] [issue2115] __slots__ make attribute setting
	10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

(On a MacBook Pro 2.33 GHz)

$ ./python.exe -m timeit -s 'class Foo(object): pass' -s 'f = Foo()'
'f.num = 3'
10000000 loops, best of 3: 0.13 usec per loop
$ ./python.exe -m timeit -s 'class Foo(object): __slots__ = ["num"]' -s
'f = Foo()' 'f.num = 3'
1000000 loops, best of 3: 1.24 usec per loop

Attribute reading isn't affected:
$ ./python.exe -m timeit -s 'class Foo(object): pass' -s 'f = Foo();
f.num = 3' 'g = f.num'
10000000 loops, best of 3: 0.107 usec per loop
$ ./python.exe -m timeit -s 'class Foo(object): __slots__ = ["num"]' -s
'f = Foo(); f.num = 3' 'g = f.num'
10000000 loops, best of 3: 0.101 usec per loop

----------
components: Interpreter Core
messages: 62408
nosy: jyasskin
severity: normal
status: open
title: __slots__ make attribute setting 10x slower
type: resource usage
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 22:22:35 2008
From: report at bugs.python.org (Rick Harris)
Date: Thu, 14 Feb 2008 21:22:35 -0000
Subject: [New-bugs-announce] [issue2116] weakref copy module interaction
In-Reply-To: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>
Message-ID: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>


New submission from Rick Harris:

The copy module will not properly copy/deepcopy weakrefs, it will bomb
out with __new__ not having enough args. This is a problem b/c it makes
deepcopying of objects that make use of Weak(Key|Value)Dictionaries
difficult.

To replicate:

import copy, weakref
class Test(object): pass
t = Test()
wr = weakref.ref(t)
wr_new = copy.copy(wr)

----------
components: Library (Lib)
files: copy.patch
messages: 62413
nosy: rharris
severity: normal
status: open
title: weakref copy module interaction
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9433/copy.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2116>
__________________________________

From report at bugs.python.org  Thu Feb 14 23:23:13 2008
From: report at bugs.python.org (stranger4good)
Date: Thu, 14 Feb 2008 22:23:13 -0000
Subject: [New-bugs-announce] [issue2118] smtplib.SMTP() raises socket.error
	rather than SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>


New submission from stranger4good:

smtplib.SMTP() raises socket.error rather than SMTPConnectError

just try this on a non-responding address

>>> srv=smtplib.SMTP('192.168.13.22')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python25\lib\smtplib.py", line 244, in __init__
    (code, msg) = self.connect(host, port)
  File "c:\python25\lib\smtplib.py", line 311, in connect
    (code, msg) = self.getreply()
  File "c:\python25\lib\smtplib.py", line 352, in getreply
    line = self.file.readline()
  File "C:\Python25\lib\socket.py", line 346, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: (10054, 'Connection reset by peer')

----------
components: Library (Lib)
messages: 62416
nosy: stranger4good
severity: normal
status: open
title: smtplib.SMTP() raises socket.error rather than SMTPConnectError
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Thu Feb 14 23:51:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Feb 2008 22:51:34 -0000
Subject: [New-bugs-announce] [issue2119] Empty test
Message-ID: <1203029494.75.0.298873586511.issue2119@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
nosy: loewis
severity: normal
status: open
title: Empty test

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2119>
__________________________________

From report at bugs.python.org  Fri Feb 15 01:16:53 2008
From: report at bugs.python.org (Ori Avtalion)
Date: Fri, 15 Feb 2008 00:16:53 -0000
Subject: [New-bugs-announce] [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>


New submission from Ori Avtalion:

The file python/trunk/Doc/howto/advocacy.rst has two broken links:

"http://www.catb.org/ esr/jargon/html/C/compact.html"
should be
"http://www.catb.org/~esr/jargon/html/C/compact.html"

"http://homepages.cwi.nl/ steven/abc/" (line-wrapped in the source)
should be
"http://homepages.cwi.nl/~steven/abc/"

----------
components: Documentation
messages: 62419
nosy: georg.brandl, salty-horse
severity: minor
status: open
title: broken links in advocacy HOWTO
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Fri Feb 15 09:15:17 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2008 08:15:17 -0000
Subject: [New-bugs-announce] [issue2121] complex constructor doesn't accept
	string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This is a reminder.

The issue makes the complex(repr(...)) round-trip impossible when either
the real or imag part is nan or infinite.

----------
components: Interpreter Core
messages: 62422
nosy: tiran
priority: normal
severity: normal
status: open
title: complex constructor doesn't accept string with nan and inf
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
__________________________________

From report at bugs.python.org  Fri Feb 15 14:20:03 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 15 Feb 2008 13:20:03 -0000
Subject: [New-bugs-announce] [issue2122] mmap.flush does not check for
	errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

mmap.flush returns the result of the call to FlushViewOfFile as an
integer, and does not check for errors. On unix it does check for
errors. The function should return None and raise an exception if an
error occurs...
This bug can lead to data loss...

Here's the current version of that function:

static PyObject *
mmap_flush_method(mmap_object *self, PyObject *args)
{
	Py_ssize_t offset = 0;
	Py_ssize_t size = self->size;
	CHECK_VALID(NULL);
	if (!PyArg_ParseTuple(args, "|nn:flush", &offset, &size))
		return NULL;
	if ((size_t)(offset + size) > self->size) {
		PyErr_SetString(PyExc_ValueError, "flush values out of range");
		return NULL;
	}
#ifdef MS_WINDOWS
	return PyInt_FromLong((long) FlushViewOfFile(self->data+offset, size));
#elif defined(UNIX)
	/* XXX semantics of return value? */
	/* XXX flags for msync? */
	if (-1 == msync(self->data + offset, size, MS_SYNC)) {
		PyErr_SetFromErrno(mmap_module_error);
		return NULL;
	}
	return PyInt_FromLong(0);
#else
	PyErr_SetString(PyExc_ValueError, "flush not supported on this system");
	return NULL;
#endif
}

----------
components: Library (Lib)
messages: 62427
nosy: schmir
severity: major
status: open
title: mmap.flush does not check for errors on windows
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
__________________________________

From report at bugs.python.org  Fri Feb 15 15:25:05 2008
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 15 Feb 2008 14:25:05 -0000
Subject: [New-bugs-announce] [issue2123] ctypes pointer not always keeping
	target alive
In-Reply-To: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>
Message-ID: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>


New submission from Armin Rigo:

It's hard to tell for sure, given the lack of precise definition, but I
believe that the attached piece of code "should" work.  What it does is
make p1 point to c_long(20).  So ctypes should probably keep the
c_long(20) alive as long as p1 is alive (and not further modified). 
This test shows that the c_long(20) gets freed instead, making the
p1.contents reference garbage.

----------
components: Extension Modules
files: x.py
messages: 62429
nosy: arigo
severity: normal
status: open
title: ctypes pointer not always keeping target alive
Added file: http://bugs.python.org/file9436/x.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2123>
__________________________________

From report at bugs.python.org  Fri Feb 15 15:42:55 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 14:42:55 -0000
Subject: [New-bugs-announce] [issue2124] xml.sax and xml.dom fetch DTDs by
	default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

The W3C posted an item at
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
describing how their DTDs are being fetched up to 130M times per day.  

The Python parsers are part of the problem, as 
noted by Paul Boddie on the python-advocacy list:

There are two places which stand out:

xml/dom/xmlbuilder.py
xml/sax/saxutils.py

What gives them away is the way as the cause of the described problem is
that 
they are both fetching things which are given as "system identifiers" - the 
things you get in the document type declaration at the top of an XML
document 
which look like a URL.

If you then put some trace statements into the code and then try and parse 
something using, for example, the xml.sax API, it becomes evident that by 
default the parser attempts to fetch lots of DTD-related resources, not 
helped by the way that stuff like XHTML is now "modular" and thus employs 
lots of separate files in the DTD. This is obvious because you get
something 
like this printed to the terminal:

saxutils: opened http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlstyle-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-framework-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-datatypes-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-qname-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-events-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-attribs-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml11-model-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-charent-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-lat1.ent
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-symbol.ent
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-special.ent
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-text-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlstruct-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlphras-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-blkstruct-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-blkphras-1.mod

Of course, the "best practice" with APIs like SAX is that you define
your own 
resolver or handler classes which don't go and fetch DTDs from the W3C all 
the time, but this isn't the "out of the box" behaviour. Instead, 
implementers have chosen the most convenient behaviour which arguably 
involves the least effort in telling people how to get hold of DTDs so that 
they may validate their documents, but which isn't necessarily the "right 
thing" in terms of network behaviour. Naturally, since defining specific 
resolvers/handlers involves a lot of boilerplate (and you should try it in 
Java!) then a lot of developers just incur the penalty of having the
default 
behaviour, instead of considering the finer points of the various W3C 
specifications (which is never really any fun).

Anyway, I posted a comment saying much the same on the blog referenced
at the 
start of this thread, but we should be aware that this is default standard 
library behaviour, not rogue application developer behaviour.

----------
components: XML
messages: 62430
nosy: akuchling
severity: normal
status: open
title: xml.sax and xml.dom fetch DTDs by default
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Fri Feb 15 17:35:37 2008
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 15 Feb 2008 16:35:37 -0000
Subject: [New-bugs-announce] [issue2125] [patch] Read support for Records in
	msilib
In-Reply-To: <1203093337.85.0.620181363068.issue2125@psf.upfronthosting.co.za>
Message-ID: <1203093337.85.0.620181363068.issue2125@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe:

The msilib documentation mentions that read support of MSI files is
supported, however the actual methods on the Record class for it are
missing.  This patch wraps two more functions from the MSI API to the
record class, enabling to read integers and strings.  The only one left
then (AFAIK) is "Stream" but I didn't need that so couldn't test it.

----------
components: Extension Modules, Library (Lib), Windows
files: msilib.diff
messages: 62432
nosy: flub
severity: normal
status: open
title: [patch] Read support for Records in msilib
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9437/msilib.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2125>
__________________________________

From report at bugs.python.org  Sat Feb 16 14:16:58 2008
From: report at bugs.python.org (June Kim)
Date: Sat, 16 Feb 2008 13:16:58 -0000
Subject: [New-bugs-announce] [issue2126] BaseHTTPServer.py
Message-ID: <1203167818.82.0.906473822.issue2126@psf.upfronthosting.co.za>


Changes by June Kim:


----------
components: Library (Lib)
nosy: juneaftn, rhettinger
severity: normal
status: open
title: BaseHTTPServer.py
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2126>
__________________________________

From report at bugs.python.org  Sat Feb 16 15:08:48 2008
From: report at bugs.python.org (Damien Elmes)
Date: Sat, 16 Feb 2008 14:08:48 -0000
Subject: [New-bugs-announce] [issue2127] sqlite3 docs should mention utf8
	requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>


New submission from Damien Elmes:

The docs on http://docs.python.org/lib/sqlite3-Module-Contents.html
should mention that the connection string should always be UTF-8,
regardless of the encoding system of the underlying filesystem. See the
'note to windows users' on 

http://www.sqlite.org/c3ref/open.html

----------
components: Documentation
messages: 62456
nosy: resolve1
severity: normal
status: open
title: sqlite3 docs should mention utf8 requirement
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Sat Feb 16 17:27:46 2008
From: report at bugs.python.org (Giovanni Bajo)
Date: Sat, 16 Feb 2008 16:27:46 -0000
Subject: [New-bugs-announce] [issue2128] sys.argv is wrong for unicode
	strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>


New submission from Giovanni Bajo:

Under Windows, sys.argv is created through the Windows ANSI API.

When you have a file/directory which can't be represented in the 
system encoding (eg: a japanese-named file or directory on a Western 
Windows), Windows will encode the filename to the system encoding using
what we call the "replace" policy, and thus sys.argv[] will contain an
entry like "c:\\foo\\??????????????.dat".

My suggestion is that:

* At the Python level, we still expose a single sys.argv[], which will 
contain unicode strings. I think this exactly matches what Py3k does now. 

* At the C level, I believe it involves using GetCommandLineW() and 
CommandLineToArgvW() in WinMain.c, but should Py_Main/PySys_SetArgv() be 
changed to also accept wchar_t** arguments? Or is it better to allow for 
NULL to be passed (under Windows at least), so that the Windows
code-path in there can use GetCommandLineW()/CommandLineToArgvW() to get
the current process' arguments?

----------
components: Interpreter Core
messages: 62458
nosy: giovannibajo
severity: normal
status: open
title: sys.argv is wrong for unicode strings
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Sat Feb 16 17:32:41 2008
From: report at bugs.python.org (June Kim)
Date: Sat, 16 Feb 2008 16:32:41 -0000
Subject: [New-bugs-announce] [issue2129] Link error of gethostbyaddr and
	gethostname in Python Manuals (the chm file)
In-Reply-To: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za>
Message-ID: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za>


New submission from June Kim:

Finding gethostname and gethostbyaddr entities from the index tab and 
clicking them in Python25.chm results in showing up the wrong section 
of 14.1.1 Process Parameters, instead of the proper section 17.2 
socket.

----------
components: Documentation
messages: 62459
nosy: juneaftn
severity: minor
status: open
title: Link error of gethostbyaddr and gethostname in Python Manuals (the chm file)
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2129>
__________________________________

From report at bugs.python.org  Sat Feb 16 22:15:09 2008
From: report at bugs.python.org (Technologov)
Date: Sat, 16 Feb 2008 21:15:09 -0000
Subject: [New-bugs-announce] [issue2130] [feature-request] Please add bool
	data type to "optparse" module
In-Reply-To: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>
Message-ID: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>


New submission from Technologov:

hi !

Currently "optparse" module lacks "bool" data type parsing. It would be
nice to add this feature.

-Technologov, 16.02.2008.

----------
components: Extension Modules
messages: 62469
nosy: Technologov
severity: normal
status: open
title: [feature-request] Please add bool data type to "optparse" module
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2130>
__________________________________

From report at bugs.python.org  Sat Feb 16 22:30:47 2008
From: report at bugs.python.org (Technologov)
Date: Sat, 16 Feb 2008 21:30:47 -0000
Subject: [New-bugs-announce] [issue2131] "codecs" module on Windows uses
	incorrect end-of-line, wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>


New submission from Technologov:

"codecs" module on Windows writes incorrect end-of-line, making it
impossible to write Unicode files.

See below, how-to reproduce bug (Python 2.5.1 on Windows XP)
===================================================================

#buggy unicode support module:
import codecs
filewr=codecs.open('myfile.txt','w','utf-8')
filewr.write("abc"+"\n")
===================================================================
Now, try to open this 'myfile.txt' using Windows Notepad.
The bug is perfectly visible.

The code below, will give correct results however:
===================================================================

filewr=open('myfile.txt','w')

filewr.write("abc"+"\n")
===================================================================
Basically this bugs _prevents_ me from writing Unicode text files.

NOTE: I'm not sure, if this bug should relate to "Windows" or "Unicode"
component.
NOTE: This bug is reproducible, even without writing Unicode characters.

-Technologov, 16.02.2008.

----------
components: Unicode
messages: 62470
nosy: Technologov
severity: normal
status: open
title: "codecs" module on Windows uses incorrect end-of-line, wiriting broken Unicode (UTF-8) files
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sun Feb 17 19:56:54 2008
From: report at bugs.python.org (Nathan Duran)
Date: Sun, 17 Feb 2008 18:56:54 -0000
Subject: [New-bugs-announce] [issue2132] Blocking sockets take entirely too
	long to timeout
In-Reply-To: <1203274614.89.0.5704894361.issue2132@psf.upfronthosting.co.za>
Message-ID: <1203274614.89.0.5704894361.issue2132@psf.upfronthosting.co.za>


New submission from Nathan Duran:

The following code:

import smtplib

test = smtplib.SMTP('mail.host.com')

will hang the entire script for about ten minutes when run on a machine 
which is connected to the internet via an ISP who blocks port 25 (which is 
pretty much all of them these days). Closer inspection of the smtplib 
sources reveals that it is making use of blocking sockets, which is all 
well and good, but I do not believe they should be allowed to block for 
such a ridiculously lengthy period of time. 

My task is to walk the list of MX records provided by a DNS query, connect 
to each server listed and check a user-supplied address for validity. If I 
have to wait 10 minutes for an exception to be thrown for each 
unresponsive server, this process could easily take hours per address, 
which is completely unacceptable. 

My workaround is to ditch smtplib entirely and write my own socket code, 
but setting a timeout on a socket throws it into non-blocking mode, which 
is not entirely what I want, either. PHP allows one to apply a perfectly 
sane timeout to a blocking socket without any difficulty, and this is 
something I'm frankly rather surprised to see Python choke on.

What I'd expect to see is an exception after less than a minute's worth of 
repeated failures so the caller can catch it and try another port.

----------
components: Library (Lib)
messages: 62498
nosy: khiltd
severity: normal
status: open
title: Blocking sockets take entirely too long to timeout
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2132>
__________________________________

From report at bugs.python.org  Sun Feb 17 20:30:38 2008
From: report at bugs.python.org (Elliott Hughes)
Date: Sun, 17 Feb 2008 19:30:38 -0000
Subject: [New-bugs-announce] [issue2133] a typo in pydoc.py causes modules
	to be cyan instead of white
In-Reply-To: <1203276638.12.0.749996572649.issue2133@psf.upfronthosting.co.za>
Message-ID: <1203276638.12.0.749996572649.issue2133@psf.upfronthosting.co.za>


New submission from Elliott Hughes:

A typo ('#fffff' instead of '#ffffff') in pydoc.py causes the "Modules"
section to have cyan text instead of white text. I don't believe this is
deliberate because (a) it looks wrong and (b) anyone doing that
deliberately would have put a '0' in the color to make it look
deliberate. This patch doesn't address the large-scale duplication of
'#ffffff' (instead of using a constant, or even the named color
'white'), and just adds the single missing character.

----------
components: Demos and Tools
files: no-cyan-modules.diff.txt
messages: 62501
nosy: elliotth
severity: normal
status: open
title: a typo in pydoc.py causes modules to be cyan instead of white
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9450/no-cyan-modules.diff.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2133>
__________________________________

From report at bugs.python.org  Mon Feb 18 00:00:30 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 17 Feb 2008 23:00:30 -0000
Subject: [New-bugs-announce] [issue2134] function generate_tokens at
	tokenize.py yields wrong token for colon
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>


New submission from Guilherme Polo:

function generate_tokes at tokenize.py yields token OP (51) for colon,
while it should be token COLON (11). It probably affects other python
versions as well.

I'm attaching a minor sample that demonstrates this, running it returns
the following output:

1 'if' (1, 0) (1, 2) if a == 2:
1 'a' (1, 3) (1, 4) if a == 2:
51 '==' (1, 5) (1, 7) if a == 2:
2 '2' (1, 8) (1, 9) if a == 2:
51 ':' (1, 9) (1, 10) if a == 2:
1 'print' (2, 0) (2, 5) print 'hey'
3 "'hey'" (2, 6) (2, 11) print 'hey'
0 '' (3, 0) (3, 0)

I didn't check if there are problems with other tokens, I noticed this
with colon because I was trying to make some improvements on tabnanny.

----------
components: Library (Lib)
files: tokenize_sample.py
messages: 62509
nosy: gpolo
severity: normal
status: open
title: function generate_tokens at tokenize.py yields wrong token for colon
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9452/tokenize_sample.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
__________________________________

From report at bugs.python.org  Mon Feb 18 00:11:19 2008
From: report at bugs.python.org (Douglas Greiman)
Date: Sun, 17 Feb 2008 23:11:19 -0000
Subject: [New-bugs-announce] [issue2135] Restructure import.c into PEP 302
	importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>


New submission from Douglas Greiman:

This patch reorganizes import.c to move functionality into two new PEP
302-style Importer objects.  I attempted to change as little as
feasible, but the patch is still ~4700 lines long, about 1000 of which
is new tests.

BuiltinImporter: handles C_BUILTIN and PY_FROZEN modules
DirectoryImporter: handles PY_SOURCE, PY_COMPILED, PKG_DIRECTORY,
C_EXTENSION modules

BuiltinImporter is put on sys.meta_path, DirectoryImporter is put on
sys.path_hooks.

To preserve backward compatibility of methods like imp.find_module(),
they use new variables sys.builtin_meta_path and sys.builtin_path_hooks
which are analogous to sys.meta_path and sys.path_hook but contain only
the two importer objects above.

Character encoding issues were substantial.  The existing code was
somewhat inscrutable in this regard.  The tests disabled in issue 1377
were re-added with more safeguards and harder tests.  It is possible to
import modules with non-ascii names from non-ascii paths.  Tested on
Windows XP and Linux.

Areas for discussion:

Naming: Names of the importer classes, names of variables, etc

sys: I added three variables to sys.  Is there a better alternative?

ModuleInfo: The importers use a somewhat tricky way to store an open
file between calls to importer.find_module() and importer.load_module(),
so that the new code doesn't do any more system calls that the old code.

semantics: There are many import corner cases where the semantics are
unknown or unclear.  

Frozen packages: the __path__ of a frozen package is a string rather
than a list, and it is possible to replace that string to change how
imports inside that package are resolved.  I have attempted to keep that
functionality intact but it's not clear that it's a feature rather than
a bug.

----------
components: Interpreter Core
files: builtin_importer-20080217.diff
messages: 62510
nosy: dgreiman
severity: normal
status: open
title: Restructure import.c into PEP 302 importer objects
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9453/builtin_importer-20080217.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Mon Feb 18 02:02:48 2008
From: report at bugs.python.org (Atul Varma)
Date: Mon, 18 Feb 2008 01:02:48 -0000
Subject: [New-bugs-announce] [issue2136] urllib2 basic auth handler doesn't
	handle realm names in single-quoted strings
In-Reply-To: <1203296568.46.0.747126970867.issue2136@psf.upfronthosting.co.za>
Message-ID: <1203296568.46.0.747126970867.issue2136@psf.upfronthosting.co.za>


New submission from Atul Varma:

This isn't necessarily a bug in Python--it's really a bug in websites
that produce what are technically malformed WWW-Authenticate headers, I
believe.

According to RFC 2617, a WWW-Authenticate header should be of the form:

  WWW-Authenticate: Basic realm="Private"

However, some websites, produce the header using single-quotes:

  WWW-Authenticate: Basic realm='Private'

The Firefox browser deals with this gracefully, but Python's urllib2
does not; specifically, an AbstractBasicAuthHandler does not recognize
the second type of header as an auth header at all, and as a result it's
impossible to access sites protected with such headers.

The attached patch alters the behavior of the class to deal with this
situation gracefully, and also adds a unit test to ensure that the
functionality works.

Implementation notes: This isn't the most well-engineered fix in the
world; in particular, I didn't change the regex used to parse
WWW-Authenticate headers, in part because (A) such a regex was difficult
to compose and (B) it would've been quite difficult to read, and I
didn't want to inadvertently mess up the current behavior of the code.

----------
components: Library (Lib)
files: urllib2_single_quoted_auth_fix.patch
messages: 62513
nosy: varmaa
severity: minor
status: open
title: urllib2 basic auth handler doesn't handle realm names in single-quoted strings
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9455/urllib2_single_quoted_auth_fix.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2136>
__________________________________

From report at bugs.python.org  Mon Feb 18 09:43:11 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 18 Feb 2008 08:43:11 -0000
Subject: [New-bugs-announce] [issue2137] test_crasher in test_struct uses 8
	GB memory on 64 bit systems
In-Reply-To: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>
Message-ID: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

I think this should be disabled on 64 bit systems. It makes running
regrtest.py for me basically impossible.
Martin, I've put you on the nosy list, as you have committed this one in
revision 60793.

----------
files: test_crasher_only_on_32bit.txt
messages: 62519
nosy: loewis, schmir
severity: normal
status: open
title: test_crasher in test_struct uses 8 GB memory on 64 bit systems
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9457/test_crasher_only_on_32bit.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2137>
__________________________________

From report at bugs.python.org  Mon Feb 18 11:09:28 2008
From: report at bugs.python.org (David Albert Torpey)
Date: Mon, 18 Feb 2008 10:09:28 -0000
Subject: [New-bugs-announce] [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>


New submission from David Albert Torpey:

Add a factorial method.  Everybody understands what it means before 
they are out of high school and it comes up all the time in statistics 
and combinatorics.  Ruby has a factorial method and heck even basic 
calculators have a factorial key.

print n.factorial()

Maybe raise ValueError if n is negative.

----------
components: Interpreter Core
messages: 62520
nosy: dtorp
severity: normal
status: open
title: Factorial
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 11:50:40 2008
From: report at bugs.python.org (carlo verr)
Date: Mon, 18 Feb 2008 10:50:40 -0000
Subject: [New-bugs-announce] [issue2139] sqlite3 module needs upgrading
In-Reply-To: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>
Message-ID: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>


New submission from carlo verr:

In Python 2.5.2.c1 the sqlite3 module contains (exactly as Python 2.5.1
does) PySQLite 2.3.2 with SQLite 3.3.4, which is very old and very
buggy, it hungs randomly.

Last available version of SQLite is 3.5.6. Last available version of
PySQLite for Python 2.5 is 2.4.1, which contains SQLite 3.5.2.

----------
components: Library (Lib)
messages: 62521
nosy: carloverre
severity: normal
status: open
title: sqlite3 module needs upgrading
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2139>
__________________________________

From report at bugs.python.org  Mon Feb 18 13:18:06 2008
From: report at bugs.python.org (Markus Stoll)
Date: Mon, 18 Feb 2008 12:18:06 -0000
Subject: [New-bugs-announce] [issue2140] calculation bug in long() function
Message-ID: <1203337086.17.0.763664362769.issue2140@psf.upfronthosting.co.za>


Changes by Markus Stoll:


----------
components: None
nosy: must21
severity: normal
status: open
title: calculation bug in long() function
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2140>
__________________________________

From report at bugs.python.org  Mon Feb 18 15:18:55 2008
From: report at bugs.python.org (moreilcon)
Date: Mon, 18 Feb 2008 14:18:55 -0000
Subject: [New-bugs-announce] [issue2141] Pydoc interactive browser misses
	some docs
In-Reply-To: <1203344335.25.0.229282723234.issue2141@psf.upfronthosting.co.za>
Message-ID: <1203344335.25.0.229282723234.issue2141@psf.upfronthosting.co.za>


New submission from moreilcon:

#no mention about formatdate at all:
% pydoc rfc822 | grep formatdate | wc -l
0
# but rfc822.formatdate docstring exists:
% pydoc rfc822.formatdate | wc -l
12
# also same behavior :
% pydoc codecs | getwriter | wc -l
0

Reproduced at:
Python 2.5.1 (r251:54863, Jan 17 2008, 09:20:17) 
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2

Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

Python 2.5.1 (r251:54863, Feb 18 2008, 13:35:09)
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7

----------
components: Library (Lib)
messages: 62530
nosy: moreilcon
severity: normal
status: open
title: Pydoc interactive browser misses some docs
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2141>
__________________________________

From report at bugs.python.org  Mon Feb 18 21:16:57 2008
From: report at bugs.python.org (Trent Mick)
Date: Mon, 18 Feb 2008 20:16:57 -0000
Subject: [New-bugs-announce] [issue2142] naive use of
	''.join(difflib.unified_diff(...)) results in bogus diffs
	with inputs that don't end with end-of-line char
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>


New submission from Trent Mick:

When comparing content with difflib, if the resulting diff covers the
last line of one or both of the inputs that that line doesn't end with
an end-of-line character(s), then the generated diff lines don't include
an EOL. Fair enough.

Naive (and I suspect typical) usage of difflib.unified_diff(...) is:

  diff = ''.join(difflib.unified_diff(...))

This results in an *incorrect* unified diff for the conditions described
above.

>>> from difflib import *
>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
...                    "one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
 one
 two
-three+trois


The proper behaviour would be:

>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
...                    "one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
 one
 two
-three
\ No newline at end of file
+trois
\ No newline at end of file


I *believe* that "\ No newline at end of file" are the appropriate
markers -- that tools like "patch" will know how to use. At least this
is what "svn diff" generates.


I'll try to whip up a patch. 

Do others concur that this should be fixed?

----------
components: Library (Lib)
messages: 62543
nosy: trentm
severity: normal
status: open
title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
__________________________________

From report at bugs.python.org  Tue Feb 19 20:53:04 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 19 Feb 2008 19:53:04 -0000
Subject: [New-bugs-announce] [issue2143] smtplib.SSLFakeFile hangs forever
	if "\n" is not encountered
In-Reply-To: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za>
Message-ID: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

By looking through the smtplib module code I think I've found a
potential issue in the SSLFakeFile class code since there's a while loop
which is supposed to be stopped only when the "\n" character is encountered:

        def readline(self):
            str = ""
            chr = None
            while chr != "\n":
                chr = self.sslobj.read(1)
                str += chr
            return str


The patch in attachment just adds a break statement to prevent the while
loop to hang forever in case the "\n" character is never encountered.

----------
components: Library (Lib)
files: smptlib.diff
messages: 62569
nosy: facundobatista, giampaolo.rodola, gregory.p.smith
severity: normal
status: open
title: smtplib.SSLFakeFile hangs forever if "\n" is not encountered
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9465/smptlib.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2143>
__________________________________

From report at bugs.python.org  Tue Feb 19 22:56:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Feb 2008 21:56:52 -0000
Subject: [New-bugs-announce] [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

This patch changes os.environ to inherit builtin dict rather than UserDict.

----------
files: environ-modern.diff
messages: 62571
nosy: gutworth
severity: normal
status: open
title: os.environ should inherit dict
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9466/environ-modern.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 01:57:59 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 00:57:59 -0000
Subject: [New-bugs-announce] [issue2145] ctypes.util.find_library(): posix
	.so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ctypes.util.find_library() fails to locate distorm64.so library 
because it has no SONAME entry:

$ objdump -p -j .dynamic /usr/local/lib/libdistorm64.so
/usr/local/lib/libdistorm64.so:     file format elf32-i386
(...)
Dynamic Section:
  NEEDED      libc.so.6
  INIT        0x12f4c
  FINI        0x1bf84
  HASH        0xb4
  (...)

Compare to libm.so:

$ objdump -p -j .dynamic /usr/lib/libm.so
/usr/lib/libm.so:     file format elf32-i386
(...)
Dynamic Section:
  NEEDED      ld-linux.so.2
  NEEDED      libc.so.6
  SONAME      libm.so.6
  INIT        0x335c
  (...)

I don't know why find_library() does use objdump to get SONAME.

Workaround to find_library() "bug": _get_soname() should return 
os.path.basename(f) instead of None. Is it correct?

Note: libdistorm64.so compilation is maybe broken (it's maybe not 
a "real" so library), but I'm able to use it with ctypes :-)

----------
components: Library (Lib)
messages: 62580
nosy: haypo
severity: normal
status: open
title: ctypes.util.find_library(): posix .so without SONAME
type: rfe
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Wed Feb 20 02:55:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 01:55:14 -0000
Subject: [New-bugs-announce] [issue2146] ctypes: support double for calling
	function
In-Reply-To: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>
Message-ID: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ctypes doesn't support transparent conversion of double arguments. 
Example code:

from ctypes import cdll, c_double
libm = cdll.LoadLibrary("libm.so")
sqrt = libm.sqrt
sqrt.argstype = (c_double,)
sqrt.restype = c_double
print sqrt(4.0)

I wrote a patch to fix it: see attached patch

----------
components: Extension Modules
files: ctypes_callproc_double.patch
messages: 62581
nosy: haypo
severity: normal
status: open
title: ctypes: support double for calling function
type: rfe
versions: Python 2.5
Added file: http://bugs.python.org/file9467/ctypes_callproc_double.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2146>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:27:38 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 20 Feb 2008 04:27:38 -0000
Subject: [New-bugs-announce] [issue2147] int operations no longer overflow
In-Reply-To: <1203481658.28.0.135415143163.issue2147@psf.upfronthosting.co.za>
Message-ID: <1203481658.28.0.135415143163.issue2147@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

Georg, I hope you don't mind me assigning this to you.  Feel free to
unassign.  A colleague pointed me to section 5.7 in the old ref doc:

http://docs.python.org/ref/shifting.html

It says that shifting operations lose data on overflow.  This info is
outdated based on PEP 237.  I suspect there may be other inaccuracies
related to int overflow.  So the purpose of this bug is to point out the
specific problem as well as to log that we need to find all invalid
references to overflow.

----------
assignee: georg.brandl
components: Documentation
messages: 62586
nosy: georg.brandl, nnorwitz
severity: normal
status: open
title: int operations no longer overflow
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2147>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:30:31 2008
From: report at bugs.python.org (Ernst Persson)
Date: Wed, 20 Feb 2008 12:30:31 -0000
Subject: [New-bugs-announce] [issue2148] nis module not supporting group
	aliases
In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>
Message-ID: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>


New submission from Ernst Persson:

Nis (applications?) has a line limit in the "group" entry, so you can't 
have very long lines (=many users)
The way to solve this is to put aliases in the group map, like this:
MY_GROUP::123:user1,user2
MY_GROUP::123:user3,user4

This is supported by the OS, grp.getgrall(), etc, but
nis.cat("group")
only puts the last entry into the dict it returns.

I guess the best thing if you want to return a dict is to merge the 
members if both the name and gid matches.

----------
components: None
messages: 62591
nosy: ernstp
severity: normal
status: open
title: nis module not supporting group aliases
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2148>
__________________________________

From report at bugs.python.org  Wed Feb 20 22:09:20 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Wed, 20 Feb 2008 21:09:20 -0000
Subject: [New-bugs-announce] [issue2149] Queue.maxsize,
	__init__() accepts any value as maxsize
Message-ID: <1203541760.62.0.918259488665.issue2149@psf.upfronthosting.co.za>


Changes by Rafael Zanella:


----------
components: Library (Lib)
nosy: zanella
severity: minor
status: open
title: Queue.maxsize, __init__() accepts any value as maxsize
type: security
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 10:24:24 2008
From: report at bugs.python.org (Neil Roques)
Date: Thu, 21 Feb 2008 09:24:24 -0000
Subject: [New-bugs-announce] [issue2150] Broken Link to New Style Classes
	Documentation
In-Reply-To: <1203585864.58.0.589732806546.issue2150@psf.upfronthosting.co.za>
Message-ID: <1203585864.58.0.589732806546.issue2150@psf.upfronthosting.co.za>


New submission from Neil Roques:

http://docs.python.org/ref/node33.html (also packaged in the Python
documentation which comes with Python) links to:

http://www.python.org/doc/newstyle.html for information on new style classes

However, this link has moved, as should now read:

http://www.python.org/doc/newstyle/

----------
components: Documentation
messages: 62612
nosy: passage
severity: normal
status: open
title: Broken Link to New Style Classes Documentation
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2150>
__________________________________

From report at bugs.python.org  Thu Feb 21 10:52:53 2008
From: report at bugs.python.org (paul rubin)
Date: Thu, 21 Feb 2008 09:52:53 -0000
Subject: [New-bugs-announce] [issue2151] no way to get http result status
	from urllib
In-Reply-To: <1203587573.07.0.565348381729.issue2151@psf.upfronthosting.co.za>
Message-ID: <1203587573.07.0.565348381729.issue2151@psf.upfronthosting.co.za>


New submission from paul rubin:

I don't see any way in the docs to get the status of an http request, in
particular I want to know whether it's a 404.  It does show up in the
guts of the library so maybe I can extract it somehow, but there should
be a simple documented way.

Also, the urllib doc says the info() method returns a mimetools.Message
instance, but what actually comes back is an httplib.HTTPMessage
instance.  I guess that's a subclass, but it's confusing.  The doc
should describe what actually comes back.

----------
components: Library (Lib)
messages: 62613
nosy: phr
severity: normal
status: open
title: no way to get http result status from urllib
type: feature request
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2151>
__________________________________

From report at bugs.python.org  Thu Feb 21 11:48:32 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 21 Feb 2008 10:48:32 -0000
Subject: [New-bugs-announce] [issue2152] make sqlite.Row hashable correctly
In-Reply-To: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za>
Message-ID: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za>


New submission from Thomas Heller:

The attached patch implements hash and cmp for sqlite3.Row objects.

----------
files: sqliterow.patch
keywords: patch
messages: 62615
nosy: theller
severity: normal
status: open
title: make sqlite.Row hashable correctly
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9475/sqliterow.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2152>
__________________________________

From report at bugs.python.org  Thu Feb 21 14:18:14 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 13:18:14 -0000
Subject: [New-bugs-announce] [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>


New submission from Virgil Dupras:

What prompted me to do these changes is that "Backward compatibility" 
section for 2.1 and earlier. How long are we going to keep this? According 
to svn, no commit has been made on the 2.1 branch since 2003. Is it safe 
to assume no unittest change is ever going to be backported to 2.1?

Then, while I was in it, I made other changes:

 - dict.has_key(key) --> key in dict
 - raise Exception, args --> raise Exception(args)
 - try..except KeyboardInterrupt: raise except: do_stuff() --> try..except 
Exception: do_stuff()
 - __metaclass__ = type --> all classes are now object subclasses

I'm not sure about the last one. Are those 2 equivalent? Is there a reason 
to keep is as "__metaclass__ = type"?

regrtest passed for me.

----------
components: Tests
files: unittest_modern.diff
messages: 62622
nosy: vdupras
severity: minor
status: open
title: unittest.py modernization
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9479/unittest_modern.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 15:26:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Feb 2008 14:26:45 -0000
Subject: [New-bugs-announce] [issue2154] doc: better detection of python
	snippets for highliting
In-Reply-To: <1203604005.4.0.314961213183.issue2154@psf.upfronthosting.co.za>
Message-ID: <1203604005.4.0.314961213183.issue2154@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

The new doc framework highlights python code, and looks very nice.
However, some snippets are not parseable by the compiler, and are thus
left unhighlighted. For example:
http://docs.python.org/dev/whatsnew/2.6.html#the-contextlib-module

The vast majority of misses is because of lines containing "...", which
is not a valid expression (except in slices).
The attached patch tries to recognize some common patterns, and replaces
"..." by some valid identifier; "... continue processing ..." is also
transformed. 

Note that the replacements are done only to get a better answer to "is
this block a python code"; pygment still works on the original string.

I checked that all new highlighted blocks are actually python snippets.
(actually, except one in configfile.rst; but others similar blocks on
the same page were already wrongly given to the python lexer)

The patch also corrects some easy syntax errors in samples.

----------
components: Documentation, Documentation tools (Sphinx)
files: doc_highlight.patch
keywords: patch
messages: 62623
nosy: amaury.forgeotdarc, georg.brandl
severity: normal
status: open
title: doc: better detection of python snippets for highliting
versions: Python 2.6
Added file: http://bugs.python.org/file9480/doc_highlight.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2154>
__________________________________

From report at bugs.python.org  Thu Feb 21 16:48:01 2008
From: report at bugs.python.org (Michael Hoffman)
Date: Thu, 21 Feb 2008 15:48:01 -0000
Subject: [New-bugs-announce] [issue2155] optparse.OptionGroup with_statement
	context handling
In-Reply-To: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za>
Message-ID: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za>


New submission from Michael Hoffman:

Adding these four lines to optparse.OptionGroup makes using option
groups vastly easier:

    def __enter__(self):
        return self

    def __exit__(self, *exc_info):
        self.parser.add_option_group(self)

You can then do things like:

    with OptionGroup(parser, "Group name") as group:
        group.add_option(...)

----------
components: Library (Lib)
messages: 62625
nosy: hoffman
severity: normal
status: open
title: optparse.OptionGroup with_statement context handling
type: feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2155>
__________________________________

From report at bugs.python.org  Thu Feb 21 17:11:36 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 16:11:36 -0000
Subject: [New-bugs-announce] [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>


New submission from Virgil Dupras:

I've been using unittest for quite a while. One thing I got tired with is 
the code duplication for file management and mocking. A few months ago I 
created this nifty little TestCase subclass and I've been using it ever 
since. It works quite well.

Am I the only one to extensively use temporary files and mocking in my 
tests? If not, I would suggest integrating my little subclass to 
unittest.Testcase, or if people think these functionalities out-scope 
unittest.TestCase, maybe we could put it in a separate unit.

Here's the unit I have here.

----------
components: Tests
files: testcase.py
messages: 62627
nosy: vdupras
severity: minor
status: open
title: TestCase.tmpdir(), TestCase.mock()
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9481/testcase.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 19:57:03 2008
From: report at bugs.python.org (wrobell)
Date: Thu, 21 Feb 2008 18:57:03 -0000
Subject: [New-bugs-announce] [issue2157] sqlite numeric type conversion
	problems
In-Reply-To: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>
Message-ID: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>


New submission from wrobell:

Numeric type conversion does not always work when using SQLite module.

Let's assume schema:

    create table test_num(no numeric);

Fetching a `test_num.no` table gives float by default.

Now, let's register some converter

    sqlite3.register_converter('numeric', lambda d: Decimal(d))

Fetching `test_num.no` gives Decimal.

But change `test_num.no` type to `numeric(10, 2)`. Float is returned.
This can be fixed by

    sqlite3.register_converter('numeric(10,', lambda d: Decimal(d))

But above will fail for `test_num.no: numeric(10,2)', which works in
case of

    sqlite3.register_converter('numeric(10,2)', lambda d: Decimal(d))

SQLite module's cursor object type cast mechanism breaks declared
type after first space {i.e. "numeric(10, 2)" -> "numeric(10,"} and
then looks up registered type converter using the first "word".

The simple fix for above could be to perform the break after space
or "(" character. Patch attached.

----------
components: Library (Lib)
files: python-sqlite-numeric.patch
messages: 62640
nosy: wrobell
severity: normal
status: open
title: sqlite numeric type conversion problems
versions: Python 2.5
Added file: http://bugs.python.org/file9484/python-sqlite-numeric.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2157>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:54:45 2008
From: report at bugs.python.org (Geoffrey Irving)
Date: Thu, 21 Feb 2008 19:54:45 -0000
Subject: [New-bugs-announce] [issue2158] confusing exception when opening a
	filename with nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>


New submission from Geoffrey Irving:

On Mac OS X with python 2.5.1, I get

>>> open(chr(212),'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: invalid mode: w

The error should be more like "filename contains nonprintable characters."

Thanks,
Geoffrey

----------
components: Macintosh
messages: 62644
nosy: irving
severity: normal
status: open
title: confusing exception when opening a filename with nonprintable characters
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Fri Feb 22 01:41:15 2008
From: report at bugs.python.org (johansen)
Date: Fri, 22 Feb 2008 00:41:15 -0000
Subject: [New-bugs-announce] [issue2159] dbmmodule inquiry function is
	performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>


New submission from johansen:

We've been using Python 2.4 to build the new package management software
for OpenSolaris.  We use a ndbm database to hold keywords about
packages, and found that each time we added a new OpenSolaris build to
our package repository, the time to import would increase by about 1/3
of the previous time.

It turns out that we were continually invoking a function in the
dbmmodule that walked the entire database every time the function was
called.

Looking at dbmmodule.c, the source for dbm.so, is instructive:

This is dbm_length, the function that we're _always_ calling.

static int
dbm_length(dbmobject *dp)
{
        if (dp->di_dbm == NULL) {
                 PyErr_SetString(DbmError, "DBM object has already been
closed"); 
                 return -1; 
        }
        if ( dp->di_size < 0 ) {
                datum key;
                int size;

                size = 0;
                for ( key=dbm_firstkey(dp->di_dbm); key.dptr;
                      key = dbm_nextkey(dp->di_dbm))
                        size++;
                dp->di_size = size;
        }
        return dp->di_size;
}

It's a knock-off of function shown in ndbm(3C) that traverses the
database.  It looks like this function walks every record in the
database, and then returns that as its size.

Further examination of dbmmodule shows that dbm_length has been assigned
as the function for the inquiry operator:

static PyMappingMethods dbm_as_mapping = {
        (inquiry)dbm_length,            /*mp_length*/
        (binaryfunc)dbm_subscript,      /*mp_subscript*/
        (objobjargproc)dbm_ass_sub,     /*mp_ass_subscript*/
};


It looks like dbm_length stashes the size of the database, so it doesn't
always have to traverse it.  However, further examination of the source
shows that an insertion doesn't update the di_size counter.  Worse yet,
an update or a delete will cause the counter to be set to -1.  This
means that the next call to dbm_length will have to walk the entire
database all over again.  Ick.

One of the problem parts of the code is this line in catalog.py:
update_searchdb():

                if fmri_list:
                        if not self.searchdb:
                                self.searchdb = \
                                    dbm.open(self.searchdb_file, "c")

This if not triggers the PyObject_IsTrue that invokes the inquiry operator
for the dbm module.  Every time we run this code, we're going to walk
the entire database.  By changing this to:

                if fmri_list:
                        if self.searchdb is None:
                                self.searchdb = \
                                    dbm.open(self.searchdb_file, "c")

We were able to work around the problem by using the is None check,
instead of if not self.searchdb; however, this seems like it is really a
problem with the dbmmodule and should ultimately be resolved there.

----------
components: Extension Modules
messages: 62668
nosy: johansen
severity: normal
status: open
title: dbmmodule inquiry function is performance prohibitive
type: resource usage
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2159>
__________________________________

From report at bugs.python.org  Fri Feb 22 06:34:57 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 05:34:57 -0000
Subject: [New-bugs-announce] [issue2160] Document PyImport_GetImporter
In-Reply-To: <1203658497.27.0.656206451092.issue2160@psf.upfronthosting.co.za>
Message-ID: <1203658497.27.0.656206451092.issue2160@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

See attached patch.

----------
components: Documentation
files: doc-import.diff
messages: 62678
nosy: belopolsky
severity: normal
status: open
title: Document PyImport_GetImporter
versions: Python 2.6
Added file: http://bugs.python.org/file9487/doc-import.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2160>
__________________________________

From report at bugs.python.org  Fri Feb 22 14:25:52 2008
From: report at bugs.python.org (=?utf-8?q?Peter_Tr=C3=B6ger?=)
Date: Fri, 22 Feb 2008 13:25:52 -0000
Subject: [New-bugs-announce] [issue2161] STORE_LOCAL byte code is not
	documented
In-Reply-To: <1203686752.82.0.84631726653.issue2161@psf.upfronthosting.co.za>
Message-ID: <1203686752.82.0.84631726653.issue2161@psf.upfronthosting.co.za>


New submission from Peter Tr?ger:

The byte code STORE_LOCAL is referenced in the description of
STORE_NAME, but has no own entry in the list. See here:

http://docs.python.org/lib/bytecodes.html

----------
components: Documentation
messages: 62685
nosy: troeger
severity: minor
status: open
title: STORE_LOCAL byte code is not documented
type: feature request
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2161>
__________________________________

From report at bugs.python.org  Fri Feb 22 15:33:28 2008
From: report at bugs.python.org (Paul Winkler)
Date: Fri, 22 Feb 2008 14:33:28 -0000
Subject: [New-bugs-announce] [issue2162] unittest.findTestCases undocumented
Message-ID: <1203690808.72.0.106902212452.issue2162@psf.upfronthosting.co.za>


Changes by Paul Winkler:


----------
components: Documentation
nosy: slinkp
severity: normal
status: open
title: unittest.findTestCases undocumented
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2162>
__________________________________

From report at bugs.python.org  Fri Feb 22 18:03:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 17:03:02 -0000
Subject: [New-bugs-announce] [issue2163] test_socket is flakey
In-Reply-To: <1203699782.31.0.112043665965.issue2163@psf.upfronthosting.co.za>
Message-ID: <1203699782.31.0.112043665965.issue2163@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I find that test_socket fails regularly (but not always) when run via
"regrtest.py -uall". The message is always "socket is not connected" but
it's unclear from which test it comes -- all I know is that it comes
from tearDown() on line 123.

(This may be a problem with 2.6 as well -- or not.)

----------
components: Tests
keywords: easy
messages: 62693
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: test_socket is flakey
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2163>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:27:46 2008
From: report at bugs.python.org (Bill Nottingham)
Date: Fri, 22 Feb 2008 20:27:46 -0000
Subject: [New-bugs-announce] [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>


New submission from Bill Nottingham:

SystemError: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

That's just unspeakably lame. I realize this is longstanding, and it's
even documented, but just... FAIL.

----------
components: Library (Lib)
messages: 62695
nosy: notting
severity: normal
status: open
title: dl broken on non-ILP32 platforms
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Sat Feb 23 14:47:51 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sat, 23 Feb 2008 13:47:51 -0000
Subject: [New-bugs-announce] [issue2165] Fix for test_logging
In-Reply-To: <1203774471.36.0.964101326063.issue2165@psf.upfronthosting.co.za>
Message-ID: <1203774471.36.0.964101326063.issue2165@psf.upfronthosting.co.za>


New submission from Thomas Herve:

The attached patch fixes the test_logging failure on my machine. Please
review.

----------
components: Tests
files: test_logging.diff
messages: 62727
nosy: therve
severity: normal
status: open
title: Fix for test_logging
versions: Python 2.6
Added file: http://bugs.python.org/file9493/test_logging.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2165>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:17:05 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 14:17:05 -0000
Subject: [New-bugs-announce] [issue2166] pydistutils.cfg won't be found on
	Windows
In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>
Message-ID: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>


New submission from Tarek Ziad?:

Related to #1741: dist.py looks for the HOME environment variable
to try to find the user's pydistutils.cfg. 

user_file = os.path.join(os.environ.get('HOME'), user_filename)

It should look form HOMEDRIVE+HOMEPATH as well.

----------
messages: 62731
nosy: tarek
severity: normal
status: open
title: pydistutils.cfg won't be found on Windows
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2166>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:22:18 2008
From: report at bugs.python.org (Wummel)
Date: Sat, 23 Feb 2008 15:22:18 -0000
Subject: [New-bugs-announce] [issue2167] Remove unused imports
In-Reply-To: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>
Message-ID: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>


New submission from Wummel:

I ran the pyflakes checker over the Python source repository and removed
some unused imports. Only obvious (from what I can see) unused imports
were removed, with most offenders being "import os, sys, string".
The diff is against current SVN (I am using git-svn, hence the --git diff).

----------
files: python-remove-unused-imports.diff
messages: 62746
nosy: calvin
severity: normal
status: open
title: Remove unused imports
Added file: http://bugs.python.org/file9498/python-remove-unused-imports.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2167>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:26:07 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sat, 23 Feb 2008 15:26:07 -0000
Subject: [New-bugs-announce] [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>


New submission from Thomas Herve:

A recent change in shelve (r60927) raises the need for gdbm objects to
be iterable. We can see it by running test_shelve on a machine with
gdbm. I'll try to fix this.

The same thing should be done with the dbm module I think.

----------
components: Library (Lib)
messages: 62749
nosy: therve
severity: normal
status: open
title: gdbm needs to be iterable
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:28:05 2008
From: report at bugs.python.org (ajaksu)
Date: Sat, 23 Feb 2008 17:28:05 -0000
Subject: [New-bugs-announce] [issue2169] Adding DOCTYPE and "html",
	"body" tags to SimpleHTTPServer
In-Reply-To: <1203787685.42.0.819164609071.issue2169@psf.upfronthosting.co.za>
Message-ID: <1203787685.42.0.819164609071.issue2169@psf.upfronthosting.co.za>


New submission from ajaksu:

This small patch adds a HTML 3.2 doctype, a <html> and a <body> tags.
Should work on py3k.

This patch only accomplishes a "Tentatively Valid HTML 3.2" result.
Adding information on  encoding would make that more conclusive, but
IMHO wrong too.

----------
components: Library (Lib)
files: SimpleHTTP_doctype_tags.diff
messages: 62780
nosy: ajaksu2
severity: minor
status: open
title: Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9508/SimpleHTTP_doctype_tags.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2169>
__________________________________

From report at bugs.python.org  Sat Feb 23 20:01:07 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 19:01:07 -0000
Subject: [New-bugs-announce] [issue2170] rewrite of minidom.Node.normalize
In-Reply-To: <1203793267.02.0.633185244836.issue2170@psf.upfronthosting.co.za>
Message-ID: <1203793267.02.0.633185244836.issue2170@psf.upfronthosting.co.za>


New submission from Malte Helmert:

In the discussion of #1433694 on the #python-dev channel, it was
observed that the normalize method of minidom.Node could take some
refactoring. A patch is attached.

----------
components: XML
files: minidom.diff
messages: 62794
nosy: maltehelmert
severity: normal
status: open
title: rewrite of minidom.Node.normalize
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9513/minidom.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2170>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:28:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:28:34 -0000
Subject: [New-bugs-announce] [issue2171] Add map, filter,
	zip to future_builtins
In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za>
Message-ID: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za>


New submission from Georg Brandl:

And make 2to3 recognize that, not putting a list() around them then.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool), Extension Modules
messages: 62855
nosy: collinwinter, georg.brandl
severity: normal
status: open
title: Add map, filter, zip to future_builtins
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2171>
__________________________________

From report at bugs.python.org  Sun Feb 24 06:09:32 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 05:09:32 -0000
Subject: [New-bugs-announce] [issue2172] Add doc-string to UserDict and
	DictMixin
In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>
Message-ID: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Attached patch improves pydoc UserDict presentation.

One of the problems with the current documentation in comments is that 
order of methods is not preserved and thus the method level comments in 
DictMixin implementation are meaningless in pydoc. (In any case the 
comments are not accurate even in the source file.)

If this patch is accepted in principle, the original level comments 
should be removed.  I am leaving them intact to simplify the review.

----------
files: UserDict-doc.diff
keywords: patch
messages: 62876
nosy: belopolsky
severity: normal
status: open
title: Add doc-string to UserDict and DictMixin
Added file: http://bugs.python.org/file9529/UserDict-doc.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2172>
__________________________________

From report at bugs.python.org  Sun Feb 24 11:26:30 2008
From: report at bugs.python.org (Michael Otteneder)
Date: Sun, 24 Feb 2008 10:26:30 -0000
Subject: [New-bugs-announce] [issue2173] Pyton fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>


New submission from Michael Otteneder:

Python seems to fail silently when LANG enviroment variable is set to a
bad value. In Mac OS X Leopard it is set too UTF-8 for instance which
does not seem to be valid. Python fails building the modules during make
and the generated python.exe is unable to output anything. Setting the
LANG variable to C or some other valid value fixes the problem. But I
suppose python should fail more verbose in case of a bad locale,or maybe
it should fallback to a standard locale.

----------
components: Interpreter Core
messages: 62892
nosy: motteneder
severity: normal
status: open
title: Pyton fails silently on bad locale
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:52:32 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 13:52:32 -0000
Subject: [New-bugs-announce] [issue2174] xml.sax.xmlreader does not support
	the InputSource protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>


New submission from Yitz Gale:

In the documentation for xml.sax.xmlreader.InputSource objects
(section 8.12.4 of the Library Reference) we find that
users of InputSource objects should use the following
sequence to get their input data:

1. If the InputSource has a character stream, use that.
2. Otherwise, if the InputSource has a byte stream, use that.
3. Otherwise, open a URI connection to the system ID.

The parse() method of IncrementalParser skips step 1.

In addition, we need to add a method
getSourceEncoding() to the XMLReader interface;
if non-null, it will indicate to the parser that
the input is a byte stream in the given encoding.

The documentation should indicate what the parser
should do if the XML itself announces that its
encoding is something else. I propose that the parser should
be required to raise an error in that case.

See also #1483.

----------
components: Documentation, Library (Lib), XML
messages: 62900
nosy: ygale
severity: normal
status: open
title: xml.sax.xmlreader does not support the InputSource protocol
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:03:03 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:03:03 -0000
Subject: [New-bugs-announce] [issue2175] Expat sax parser silently ignores
	the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>


New submission from Yitz Gale:

The expat sax parser in xml.sax.expatreader
does not fully support the InputSource protocol
in xml.sax.xmlreader. It only accepts
byte streams. It ignores the encoding
indicated in the InputStream object and
only uses the encoding read from
the XML or defaults to UTF-8.

Rather than silently doing the wrong thing,
it should raise an error when fed a character stream,
or when given an encoding, via the InputSource
interface.

And most importantly, these limitations should be mentioned
in the documentation.

----------
components: Documentation, Extension Modules, Library (Lib), Unicode, XML
messages: 62901
nosy: ygale
severity: normal
status: open
title: Expat sax parser silently ignores the InputSource protocol
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:04:32 2008
From: report at bugs.python.org (Jakub Fedyczak)
Date: Sun, 24 Feb 2008 14:04:32 -0000
Subject: [New-bugs-announce] [issue2176] Undocumented lastrowid attribute i
	sqlite3 cursor class
Message-ID: <1203861872.93.0.0923841494352.issue2176@psf.upfronthosting.co.za>


Changes by Jakub Fedyczak:


----------
components: Documentation
nosy: bukaj
severity: normal
status: open
title: Undocumented lastrowid attribute i sqlite3 cursor class
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2176>
__________________________________

From report at bugs.python.org  Sun Feb 24 17:23:39 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sun, 24 Feb 2008 16:23:39 -0000
Subject: [New-bugs-announce] [issue2177] Update compiler module to handle
	class decorators
In-Reply-To: <1203870219.45.0.496617339478.issue2177@psf.upfronthosting.co.za>
Message-ID: <1203870219.45.0.496617339478.issue2177@psf.upfronthosting.co.za>


New submission from Thomas Herve:

The attached patch (tries to?) updates compiler to handle class
decorators, and also to handle the new way decorated function are
handled. I had a weird bug because it seems that ast.py was modified at
hand last time (r51330).

This fixes the recent failures in the buildbot slaves.

Please review!

----------
components: Library (Lib)
files: compiler.diff
keywords: patch
messages: 62915
nosy: therve
severity: normal
status: open
title: Update compiler module to handle class decorators
versions: Python 2.6
Added file: http://bugs.python.org/file9538/compiler.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2177>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:12:45 2008
From: report at bugs.python.org (Ihar Hrachyshka)
Date: Sun, 24 Feb 2008 21:12:45 -0000
Subject: [New-bugs-announce] [issue2178] Problems with Belarusian Latin
	locale
In-Reply-To: <1203887565.7.0.326406718733.issue2178@psf.upfronthosting.co.za>
Message-ID: <1203887565.7.0.326406718733.issue2178@psf.upfronthosting.co.za>


New submission from Ihar Hrachyshka:

There is a glibc locale: be_BY.UTF-8 at latin. If my locale environment is
set to this locale then all i18n-ed programs are shown with proper
translation, except Python-based ones where I see POSIX (?) locale
translation (all in English). Though if I set locale as be_BY at latin then
all goes well. Please fix the behavior of Python programs in my locale.
Affected programs: Sonata MPD client, GnoCHM, Gajim and possibly other.

----------
components: None
messages: 62939
nosy: booxter
severity: normal
status: open
title: Problems with Belarusian Latin locale
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2178>
__________________________________

From report at bugs.python.org  Mon Feb 25 00:10:41 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 24 Feb 2008 23:10:41 -0000
Subject: [New-bugs-announce] [issue2179] with should be as fast as
	try/finally
In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za>
Message-ID: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

Currently, 'with' costs about .2us over try/finally:

$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally:
lock.release()'
1000000 loops, best of 3: 0.617 usec per loop
$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'with lock: pass'
1000000 loops, best of 3: 0.774 usec per loop

Since it's doing the same thing (and calling the same C functions to do
the lock manipulation), it shouldn't take more time. The bytecodes
associated with the two options look like:

2)    with lock:
3)      pass

 2           0 LOAD_GLOBAL              0 (lock)
              3 DUP_TOP             
              4 LOAD_ATTR                1 (__exit__)
              7 STORE_FAST               0 (_[1])
             10 LOAD_ATTR                2 (__enter__)
             13 CALL_FUNCTION            0
             16 POP_TOP             
             17 SETUP_FINALLY            4 (to 24)

  3          20 POP_BLOCK           
             21 LOAD_CONST               0 (None)
        >>   24 LOAD_FAST                0 (_[1])
             27 DELETE_FAST              0 (_[1])
             30 WITH_CLEANUP        
             31 END_FINALLY         
             32 LOAD_CONST               0 (None)
             35 RETURN_VALUE        


6)    lock.acquire()
7)    try:
8)      pass
9)    finally:
10)     lock.release()

  6           0 LOAD_GLOBAL              0 (lock)
              3 LOAD_ATTR                1 (acquire)
              6 CALL_FUNCTION            0
              9 POP_TOP             

  7          10 SETUP_FINALLY            4 (to 17)

  8          13 POP_BLOCK           
             14 LOAD_CONST               0 (None)

 10     >>   17 LOAD_GLOBAL              0 (lock)
             20 LOAD_ATTR                2 (release)
             23 CALL_FUNCTION            0
             26 POP_TOP             
             27 END_FINALLY         
             28 LOAD_CONST               0 (None)
             31 RETURN_VALUE


The major difference I see is the extra local variable (_[1]) used by
with. It looks like the compiler ought to be able to save that on the
stack instead, and save 3 opcodes. Neal Norwitz suggested that, if that
optimization is impossible, WITH_CLEANUP could be modified to take the
variable as a parameter, which would let it absorb the LOAD_FAST and
DELETE_FAST instructions.

I've added everyone on the previous bug to the nosy list. Sorry if you
don't care. :)

----------
components: Interpreter Core
messages: 62951
nosy: amaury.forgeotdarc, benjamin.peterson, jyasskin, nnorwitz, rhettinger, tiran
severity: normal
status: open
title: with should be as fast as try/finally
type: feature request
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2179>
__________________________________

From report at bugs.python.org  Mon Feb 25 02:55:51 2008
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 25 Feb 2008 01:55:51 -0000
Subject: [New-bugs-announce] [issue2180] tokenize: mishandles line joining
Message-ID: <1203904551.76.0.51250156022.issue2180@psf.upfronthosting.co.za>


Changes by Jared Grubb:


----------
components: Extension Modules
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: mishandles line joining
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2180>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:00:14 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:00:14 -0000
Subject: [New-bugs-announce] [issue2181] optimize out local variables at end
	of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

This patch optimizes code like:

   x = any_expression
   return x

to:
   return any_expression

Currently it only optimizes out the local variable if there is a return
because it can't determine if this is the last use of the variable or not.

This shouldn't change behaviour under normal circumstances, but would
change behaviour with a debugger.  Perhaps this optimization should only
be performed if -O is passed on the command line?

This optimization saves two trips around the eval loop (STORE_FAST and
LOAD_FAST) and 6 bytes in the byte code.

----------
components: Interpreter Core
files: opt-out-local-var.patch
keywords: patch, patch
messages: 62957
nosy: nnorwitz
severity: normal
status: open
title: optimize out local variables at end of function
type: resource usage
Added file: http://bugs.python.org/file9544/opt-out-local-var.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:06:47 2008
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 25 Feb 2008 02:06:47 -0000
Subject: [New-bugs-announce] [issue2182] tokenize: does not allow CR for a
	newline
In-Reply-To: <1203905207.87.0.633637741257.issue2182@psf.upfronthosting.co.za>
Message-ID: <1203905207.87.0.633637741257.issue2182@psf.upfronthosting.co.za>


New submission from Jared Grubb:

tokenize recognizes '\n' and '\r\n' as newlines, but does not tolerate '\r':

>>> s = "print 1\nprint 2\r\nprint 3\r"
>>> open('temp.py','w').write(s)
>>> exec(open('temp.py','r'))
1
2
3
>>> tokenize.tokenize(open('temp.py','r').readline)
1,0-1,5:	NAME	'print'
1,6-1,7:	NUMBER	'1'
1,7-1,8:	NEWLINE	'\n'
2,0-2,5:	NAME	'print'
2,6-2,7:	NUMBER	'2'
2,7-2,9:	NEWLINE	'\r\n'
3,0-3,5:	NAME	'print'
3,6-3,7:	NUMBER	'3'
3,7-3,8:	ERRORTOKEN	'\r'
4,0-4,0:	ENDMARKER	''

----------
components: Extension Modules
messages: 62959
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: does not allow CR for a newline
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2182>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:22:32 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:22:32 -0000
Subject: [New-bugs-announce] [issue2183] optimize list comprehensions
In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za>
Message-ID: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

Optimize list comprehensions by using the list on the stack, rather than
storing in a (local/global) variable.  This reduces the size of the
stack by one pointer, reduces the bytecode size by 8, and reduces the
iterations in the eval loop by 2 + # of iterations to create the new
list.  It also eliminates internal variables in varnames.

List comps in module/class scope execute faster by avoiding more costly
dict lookups in globals.

For this source code:
    def f(): return [x for x in s]

Byte code before change:
  1           0 BUILD_LIST               0
              3 DUP_TOP             
              4 STORE_FAST               0 (_[1])
              7 LOAD_GLOBAL              1 (s)
             10 GET_ITER            
        >>   11 FOR_ITER                13 (to 27)
             14 STORE_FAST               1 (x)
             17 LOAD_FAST                0 (_[1])
             20 LOAD_FAST                1 (x)
             23 LIST_APPEND         
             24 JUMP_ABSOLUTE           11
        >>   27 DELETE_FAST              0 (_[1])
             30 RETURN_VALUE        

New byte code:
  1           0 BUILD_LIST               0
              3 LOAD_GLOBAL              0 (s)
              6 GET_ITER            
        >>    7 FOR_ITER                12 (to 22)
             10 STORE_FAST               0 (x)
             13 LOAD_FAST                0 (x)
             16 LIST_APPEND              2
             19 JUMP_ABSOLUTE            7
        >>   22 RETURN_VALUE        

DUP_TOP/STORE_FAST are eliminated before the loop.  One LOAD_FAST is
eliminated inside the loop.  LIST_APPEND is changed to reference the
value on the stack.  Is it a problem to change the opcode of LIST_APPEND?

This might make debugging harder.  I'm not sure how debuggers work with
list comps.

A similar optimization could probably be done to eliminate all uses of
the temporary variables (WITH_CLEANUP at least).

This patch still needs to update docs and the compiler package
implemented in Python.

----------
components: Interpreter Core
files: list-comp-opt2.patch
keywords: patch, patch
messages: 62961
nosy: nnorwitz
severity: normal
status: open
title: optimize list comprehensions
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9545/list-comp-opt2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2183>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:30:23 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 25 Feb 2008 02:30:23 -0000
Subject: [New-bugs-announce] [issue2184] Speed up Thread.start()
In-Reply-To: <1203906623.93.0.917189380676.issue2184@psf.upfronthosting.co.za>
Message-ID: <1203906623.93.0.917189380676.issue2184@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

Thread.start() used sleep(0.000001) to make sure it didn't return before
the new thread had started. At least on my MacBook Pro, that wound up
sleeping for a full 10ms (probably 1 jiffy). By using an Event instead,
we can be absolutely certain that the thread has started, and return
more quickly (217us).

Before:
$  ./python.exe -m timeit -s 'from threading import Thread'  't =
Thread(); t.start(); t.join()'
100 loops, best of 3: 10.3 msec per loop
$  ./python.exe -m timeit -s 'from threading import Thread; t =
Thread()'  't.isAlive()'
1000000 loops, best of 3: 0.47 usec per loop

After:
$  ./python.exe -m timeit -s 'from threading import Thread'  't =
Thread(); t.start(); t.join()'
1000 loops, best of 3: 217 usec per loop
$  ./python.exe -m timeit -s 'from threading import Thread; t =
Thread()'  't.isAlive()'
1000000 loops, best of 3: 0.86 usec per loop

To be fair, the 10ms isn't CPU time, and other threads including the
spawned one get to run during it. There are also some slightly more
complicated ways to get back the .4us in isAlive() if we want.

----------
components: Library (Lib)
files: faster_thread_startup.diff
keywords: patch, patch
messages: 62963
nosy: jyasskin
severity: normal
status: open
title: Speed up Thread.start()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9546/faster_thread_startup.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2184>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:41:40 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:41:40 -0000
Subject: [New-bugs-announce] [issue2185] code objects should conserve memory
In-Reply-To: <1203907300.87.0.511382024936.issue2185@psf.upfronthosting.co.za>
Message-ID: <1203907300.87.0.511382024936.issue2185@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

Various bits are often duplicated in code objects.  For example,
sometimes names and varnames are equal.  In this case, we don't need two
objects since they are both const.  This patch implements a trivial fix
for this case.  However, there are more cases.  We should profile where
the memory is being used and do simple/cheap consolidations where
possible.  Another example would be a 1-element tuple containing:
(None,) for consts.

Some (all?) of these sorts of optimizations should probably be done in
the code object itself.

----------
files: marshal-mem.patch
keywords: patch, patch
messages: 62965
nosy: nnorwitz
severity: normal
status: open
title: code objects should conserve memory
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9547/marshal-mem.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2185>
__________________________________

From report at bugs.python.org  Mon Feb 25 05:04:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 04:04:20 -0000
Subject: [New-bugs-announce] [issue2186] map and filter shouldn't support
	None as first argument (in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

There are other ways of getting the same effects now (list() or zip()
for map(None, ...)).

----------
keywords: easy
messages: 62967
nosy: gvanrossum
severity: normal
status: open
title: map and filter shouldn't support None as first argument (in Py3k only)
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 05:06:33 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 04:06:33 -0000
Subject: [New-bugs-announce] [issue2187] map and filter objects shouldn't
	call themselves itertools.imap and itertools.ifilter objects
In-Reply-To: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za>
Message-ID: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Probably ifilter and imap should go (moving the code over to bltinmodule.c).

----------
components: Interpreter Core
keywords: easy
messages: 62968
nosy: gvanrossum
severity: normal
status: open
title: map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2187>
__________________________________

From report at bugs.python.org  Mon Feb 25 12:08:49 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 25 Feb 2008 11:08:49 -0000
Subject: [New-bugs-announce] [issue2188] [patch] urllib2 hint - disabled
	ProxyHandler()
In-Reply-To: <1203937729.17.0.846967390302.issue2188@psf.upfronthosting.co.za>
Message-ID: <1203937729.17.0.846967390302.issue2188@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Patch documents that empty dictionary is used to make ProxyHandler()
with disabled proxy autodetection. Empty constructor doesn't give the
desired effect.

P.S. An ideal approach would be, of course, to change the API. Even
though it can be changed drastically the simple hack would look like:

class ProxyHandler([proxies][, autodetect=False])

Seems like it is better to leave API for Py3K refactoring issue, like #1333

----------
components: Documentation
files: urllib2.patch.txt
messages: 62976
nosy: techtonik
severity: normal
status: open
title: [patch] urllib2 hint - disabled ProxyHandler()
versions: Python 2.6
Added file: http://bugs.python.org/file9549/urllib2.patch.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2188>
__________________________________

From report at bugs.python.org  Mon Feb 25 13:09:49 2008
From: report at bugs.python.org (djc)
Date: Mon, 25 Feb 2008 12:09:49 -0000
Subject: [New-bugs-announce] [issue2189] urllib.quote() throws KeyError when
	passed an iterator
In-Reply-To: <1203941389.03.0.634927871204.issue2189@psf.upfronthosting.co.za>
Message-ID: <1203941389.03.0.634927871204.issue2189@psf.upfronthosting.co.za>


New submission from djc:

>>> urllib.quote(['', 'aa'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib.py", line 1205, in quote
    res = map(safe_map.__getitem__, s)
KeyError: ''

I think this is a weird error message to throw. quote() is obviously
assuming that the param passed is a one-character string iterator or
something. It should either accept just strings or come up with a better
error message when confronted with an iterator element that is not a
one-character string, IMO.

----------
components: Library (Lib)
messages: 62978
nosy: djc
severity: minor
status: open
title: urllib.quote() throws KeyError when passed an iterator
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2189>
__________________________________

From report at bugs.python.org  Mon Feb 25 17:39:06 2008
From: report at bugs.python.org (Dou Yuan)
Date: Mon, 25 Feb 2008 16:39:06 -0000
Subject: [New-bugs-announce] [issue2190] MozillaCookieJar ignore HttpOnly
	cookies
In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za>
Message-ID: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za>


New submission from Dou Yuan:

HttpOnly cookie in Firefox's cookies.txt begins with "#HttpOnly_" now,
just like a comment, e.g.:

#HttpOnly_.rad.live.com    TRUE    /    FALSE    1258200001    FC09    FB=
#HttpOnly_service.ilib.cn    FALSE    /    FALSE    1209905939   
.ASPXANONYMOUS   
JMeD5-atyAEkAAAAYjZlNDUyNDAtOGQ4ZC00NTEyLTljN2EtMzNkODM3M2JjMjFivtX6ikB7Iv0jRJBJs9ftggv_a2k

Since no obvious need, there are no patches for save method and
cookielib.Cookie class.

----------
components: Library (Lib)
files: _MozillaCookieJar.diff
keywords: patch
messages: 62985
nosy: douyuan
severity: minor
status: open
title: MozillaCookieJar ignore HttpOnly cookies
versions: Python 2.6
Added file: http://bugs.python.org/file9552/_MozillaCookieJar.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2190>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:07:33 2008
From: report at bugs.python.org (Madhusudan SK)
Date: Mon, 25 Feb 2008 20:07:33 -0000
Subject: [New-bugs-announce] [issue2191] SubProcess Startup error
In-Reply-To: <1203970053.49.0.924039219535.issue2191@psf.upfronthosting.co.za>
Message-ID: <1203970053.49.0.924039219535.issue2191@psf.upfronthosting.co.za>


New submission from Madhusudan SK:

After installing the Python.msi x86 installer on an Intel P4 machine 
running Windows XP SP2, I am getting the error "Subprocess startup 
error" and when i click OK on the dialog box the Python IDLE closes. I 
do not have Microsoft Visual Studio installed on my system but do have 
the .NET framework 1.1 installed. The reason code in the pop up says 
either the IDLE cannot start a subprocess or a firewall is blocking the 
connection. Is it necessary that the anitvirus/firewall software needs 
to be disabled before installing Python 3.0 or is it the case as 
mentioned in the http://www.python.org/download/releases/3.0/ "Read 
this first" section i.e. python30.dll cannot be installed in system32 
folder?

----------
components: IDLE
files: Python3.0a IDLE startup error.htm
messages: 62996
nosy: madhusudan.sk
severity: major
status: open
title: SubProcess Startup error
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file9554/Python3.0a IDLE startup error.htm

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2191>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:18:26 2008
From: report at bugs.python.org (aka)
Date: Mon, 25 Feb 2008 20:18:26 -0000
Subject: [New-bugs-announce] [issue2192] error with backslash as last
	character in raw string
In-Reply-To: <1203970706.3.0.353851421096.issue2192@psf.upfronthosting.co.za>
Message-ID: <1203970706.3.0.353851421096.issue2192@psf.upfronthosting.co.za>


New submission from aka:

When creating a raw string ending with a backslash the systems answers
with an error:

>>> r'c:\'
SyntaxError: EOL while scanning single-quoted string

This happens on many systems with many versions, so it is propably a
problem of the interpreter itself.

----------
components: Interpreter Core
messages: 62997
nosy: aka
severity: normal
status: open
title: error with backslash as last character in raw string
type: compile error
versions: Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2192>
__________________________________

From report at bugs.python.org  Tue Feb 26 03:27:23 2008
From: report at bugs.python.org (BM)
Date: Tue, 26 Feb 2008 02:27:23 -0000
Subject: [New-bugs-announce] [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>


New submission from BM:

According to David M. Kristol, only comma, space and semi-colon are 
forbidden in the cookie Name. However, Python's Cookie.py rejects a 
colon too. At the same time, Java Cookie in the servlet implementation 
allows a colon and Perl too.

The fix would be to add a colon symbol into _LegalChars variable.

----------
components: Library (Lib)
messages: 63023
nosy: BM
severity: major
status: open
title: Cookie Colon Name Bug
versions: Python 2.4, Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Tue Feb 26 16:45:54 2008
From: report at bugs.python.org (Tim Golden)
Date: Tue, 26 Feb 2008 15:45:54 -0000
Subject: [New-bugs-announce] [issue2194] Tiny patch to docs
In-Reply-To: <1204040754.9.0.589972420385.issue2194@psf.upfronthosting.co.za>
Message-ID: <1204040754.9.0.589972420385.issue2194@psf.upfronthosting.co.za>


New submission from Tim Golden:

A patch against r61085 of /doc to correct some very minor typos in the docs

----------
components: Documentation
files: python-doc-r61085.patch
keywords: patch
messages: 63048
nosy: tim.golden
severity: minor
status: open
title: Tiny patch to docs
versions: Python 2.6
Added file: http://bugs.python.org/file9562/python-doc-r61085.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2194>
__________________________________

From report at bugs.python.org  Tue Feb 26 23:31:54 2008
From: report at bugs.python.org (Gawain Bolton)
Date: Tue, 26 Feb 2008 22:31:54 -0000
Subject: [New-bugs-announce] [issue2195] urlparse()
In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>
Message-ID: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>


New submission from Gawain Bolton:

The urlparse() function in urlparse module does not handle URLs without 
an explicit scheme and with port numbers.

The following works as expected:
>>> urlparse.urlparse('foo.bar.com','http').scheme
'http'

But if the URL has a port number then the scheme is wrong:
>>> urlparse.urlparse('foo.bar.com:8080','http').scheme
'foo.bar.com'

I have read RFC 1808 and its description of the parsing of the scheme 
also has this bug.  From what I can figure, the parsing algorithm needs 
to search for the scheme before the substring "://" and not just ":".

----------
components: Library (Lib)
messages: 63054
nosy: gawain
severity: normal
status: open
title: urlparse()
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
__________________________________

From report at bugs.python.org  Tue Feb 26 23:51:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Feb 2008 22:51:55 -0000
Subject: [New-bugs-announce] [issue2196] Fix hasattr's exception problems
In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>
Message-ID: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

hasattr currently returns False when any exception happens in getattr. I
see that this tracker I previous patches trying to fix this issue, but
they were rejected because they only tried to catch attribute errors. My
patch only propagates SystemExit and KeyboardInterrupt exceptions.

----------
components: Interpreter Core, Tests
files: hasattr_fixes.diff
keywords: patch
messages: 63055
nosy: benjamin.peterson
severity: normal
status: open
title: Fix hasattr's exception problems
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9563/hasattr_fixes.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2196>
__________________________________

From report at bugs.python.org  Wed Feb 27 05:42:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Feb 2008 04:42:38 -0000
Subject: [New-bugs-announce] [issue2197] Further simplify dict literal
	bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

I am attaching a proof-of-concept patch that changes the bytecode 
generated from {1:1,2:2,3:3,4:4} from 

BUILD_MAP                4  
LOAD_CONST               2 (1)  
LOAD_CONST               2 (1)  
STORE_MAP             
LOAD_CONST               1 (2)  
LOAD_CONST               1 (2)  
STORE_MAP             
LOAD_CONST               4 (3)  
LOAD_CONST               4 (3)  
STORE_MAP             
LOAD_CONST               3 (4)  
LOAD_CONST               3 (4)  
STORE_MAP             

to

LOAD_CONST               1 (4)  
LOAD_CONST               1 (4)  
LOAD_CONST               2 (3)   
LOAD_CONST               2 (3)                                                    
LOAD_CONST               3 (2)                                        
LOAD_CONST               3 (2)                                         
LOAD_CONST               4 (1)  
LOAD_CONST               4 (1)  
BUILD_MAP                4  
 
and changes BUILD_MAP to behave similarly to BUILD_(SET|LIST|TUPLE) and 
consume 2*n items from the stack.

The advantage is more compact and faster bytecode and uniform treatment 
of BUILD_* instructions.

----------
components: Interpreter Core
files: dict-literal.diff
keywords: patch
messages: 63063
nosy: belopolsky
severity: normal
status: open
title: Further simplify dict literal bytecode
versions: Python 3.0
Added file: http://bugs.python.org/file9564/dict-literal.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2197>
__________________________________

From report at bugs.python.org  Wed Feb 27 22:47:40 2008
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Wed, 27 Feb 2008 21:47:40 -0000
Subject: [New-bugs-announce] [issue2198] code_hash() can be the same for
	different code objects
In-Reply-To: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za>
Message-ID: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za>


New submission from Stephan R.A. Deibel:

The algorithm in code_hash() in codeobject.c can return the same hash
value for different code objects.  

Presumably distinct code objects should be very unlikely to have the
same hash value.  This bug affected our debugger before we worked around
it, and it could affect other things like profilers.

Adding the co_filename to the hash would be one way to fix this but I'm
not sure if that was purposely avoided in this code?

----------
components: Interpreter Core
files: code_hash_bug.tgz
messages: 63083
nosy: sdeibel
severity: normal
status: open
title: code_hash() can be the same for different code objects
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9565/code_hash_bug.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2198>
__________________________________

From report at bugs.python.org  Thu Feb 28 14:46:24 2008
From: report at bugs.python.org (PyScripter)
Date: Thu, 28 Feb 2008 13:46:24 -0000
Subject: [New-bugs-announce] [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>


New submission from PyScripter:

cPickle has problems loading instances of gtk gobject.GEnum classes. 
gobject.GEnum is a subclass of int.  On the other hand pickle handles
those classes correctly.  Since cPickle is meant to be a faster version
of pickle this needs to be consider a bug.  

To test run the following script:

import gtk
##import pickle
import cPickle as pickle

simple_types = (
    bool,
    int,
    long,
    float,
    complex,
    basestring,
    type(None),
)


d = vars(gtk)
for (i,j) in d.iteritems():
    if isinstance(j, simple_types):
        try:
            s = pickle.dumps(j, pickle.HIGHEST_PROTOCOL)
            obj = pickle.loads(s)
        except (ValueError, TypeError):
            print j, type(j)

If you replace cPickle with pickle then the script runs fine.

----------
components: Library (Lib)
messages: 63091
nosy: pyscripter
severity: normal
status: open
title: cPickle error with gtk GEnum classes
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Thu Feb 28 14:52:13 2008
From: report at bugs.python.org (Lev Shamardin)
Date: Thu, 28 Feb 2008 13:52:13 -0000
Subject: [New-bugs-announce] [issue2200] find_executable fails to find .bat
	files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>


New submission from Lev Shamardin:

distutils.spawn.find_executable appends '.exe' suffix on win32 and os2
platforms. This is incorrect behavior, since it prevents finding .bat,
.cmd and other similar files. Ether all extensions from the %PATHEXT%
must be checked or filenames both with appended suffix and without
appending suffix must be checked.

----------
components: Distutils
messages: 63092
nosy: abbot
severity: major
status: open
title: find_executable fails to find .bat files on win32
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
__________________________________

From report at bugs.python.org  Thu Feb 28 17:42:54 2008
From: report at bugs.python.org (Jarod)
Date: Thu, 28 Feb 2008 16:42:54 -0000
Subject: [New-bugs-announce] [issue2201] Documentation Section 4.4
In-Reply-To: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>
Message-ID: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>


New submission from Jarod:

Section 4.4 of the tutorial gives example code: 

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break
...     else:
...         # loop fell through without finding a factor
...         print n, 'is a prime number'
... 
2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

When one is to enter the code (print n, 'equals' x, '*' n/x) you are
given syntax error:   File "<stdin>", line 4
    print n, 'equals' x, '*' n/x
                      ^
SyntaxError: invalid syntax

----------
components: Documentation
messages: 63096
nosy: str8lazy
severity: normal
status: open
title: Documentation Section 4.4
type: compile error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2201>
__________________________________

From report at bugs.python.org  Thu Feb 28 19:26:34 2008
From: report at bugs.python.org (Brendan W. McAdams)
Date: Thu, 28 Feb 2008 18:26:34 -0000
Subject: [New-bugs-announce] [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: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>


New submission from Brendan W. McAdams:

URLLIB2 seems to have issues attempting to digest authenticate against a
Windows-based IIS 6.x server.  The IIS server requests MD5-sess support,
and URLLIB2 throws an exception that ... far from explains this:

Traceback (most recent call last):
  File "/usr/lib64/python2.5/runpy.py", line 95, in run_module
    filename, loader, alter_sys)
  File "/usr/lib64/python2.5/runpy.py", line 52, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "/usr/lib64/python2.5/runpy.py", line 32, in _run_code
    exec code in run_globals
  File "/srv/pubPal/test/test_auth.py", line 16, in <module>
    print opener.open(uri)
  File "/usr/lib64/python2.5/urllib2.py", line 380, in open
    response = meth(req, response)
  File "/usr/lib64/python2.5/urllib2.py", line 491, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib64/python2.5/urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "/usr/lib64/python2.5/urllib2.py", line 353, in _call_chain
    result = func(*args)
  File "/usr/lib64/python2.5/urllib2.py", line 992, in http_error_401
    host, req, headers)
  File "/usr/lib64/python2.5/urllib2.py", line 884, in http_error_auth_reqed
    return self.retry_http_digest_auth(req, authreq)
  File "/usr/lib64/python2.5/urllib2.py", line 889, in
retry_http_digest_auth
    auth = self.get_authorization(req, chal)
  File "/usr/lib64/python2.5/urllib2.py", line 920, in get_authorization
    H, KD = self.get_algorithm_impls(algorithm)
  File "/usr/lib64/python2.5/urllib2.py", line 972, in get_algorithm_impls
    return H, KD
UnboundLocalError: local variable 'H' referenced before assignment


The offending code is urllib2.py line 972:

    def get_algorithm_impls(self, algorithm):
        # lambdas assume digest modules are imported at the top level
        if algorithm == 'MD5':
            H = lambda x: hashlib.md5(x).hexdigest()
        elif algorithm == 'SHA':
            H = lambda x: hashlib.sha1(x).hexdigest()
        # XXX MD5-sess
        KD = lambda s, d: H("%s:%s" % (s, d))
        return H, KD

I'm not sure what's meant by the # XXX MD5-sess comment there... But
what ends up happening is that MD5-sess matches neither the if or the
elif, and when return attempts to return, H is undefined.

This could be easily patched, but support for MD5-sess would be great as
well.  

In my estimation, at the least, urllib2 shouldn't crap out in such an
obscure way when encountering an unsupported algorithm.

I'd suggest changing line 970 (The # XXX MD5-sess line) to:

 raise Exception, "Unsupported Digest Authentication Algorithm '%s'" %
(algorithm)

----------
components: Library (Lib)
messages: 63101
nosy: bwmcadams
severity: normal
status: open
title: urllib2 fails against IIS 6.0 (No support for MD5-sess auth)
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
__________________________________

From report at bugs.python.org  Thu Feb 28 21:00:37 2008
From: report at bugs.python.org (Mathew Ryden)
Date: Thu, 28 Feb 2008 20:00:37 -0000
Subject: [New-bugs-announce] [issue2203] ssl module getpeercert returns
	empty dict when cert_reqs=ssl.CERT_NONE
Message-ID: <1204228837.87.0.412368387154.issue2203@psf.upfronthosting.co.za>


Changes by Mathew Ryden:


----------
components: Library (Lib)
nosy: mryden
severity: normal
status: open
title: ssl module getpeercert returns empty dict when cert_reqs=ssl.CERT_NONE
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2203>
__________________________________

From report at bugs.python.org  Thu Feb 28 23:12:00 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 28 Feb 2008 22:12:00 -0000
Subject: [New-bugs-announce] [issue2204] document ConfigParser behaviour
	when a file has same section multiple times
In-Reply-To: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>
Message-ID: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>


New submission from Raghuram Devarakonda:

ConfigParser.add_section() raises DuplicateSectionError if add_section()
is called with the name of a section that is already present. How ever,
if a section is present multiple times in a file, readfp() does not
raise any exception. Instead, the sections are "combined" with values in
latter sections overwriting previous values (if any). This should be
documented in readfp(). I tried few alternatives but the sentences don't
look right. I am creating the issue in the hope that some one else may
give it a try while I continue to come up with a doc patch.

----------
assignee: georg.brandl
components: Documentation
messages: 63109
nosy: draghuram, georg.brandl
severity: normal
status: open
title: document ConfigParser behaviour when a file has same section multiple times
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2204>
__________________________________

From report at bugs.python.org  Fri Feb 29 02:59:20 2008
From: report at bugs.python.org (makoto kuwata)
Date: Fri, 29 Feb 2008 01:59:20 -0000
Subject: [New-bugs-announce] [issue2205] os.times() returns uncorrect value
Message-ID: <1204250360.44.0.399055363738.issue2205@psf.upfronthosting.co.za>


Changes by makoto kuwata:


----------
components: Library (Lib)
nosy: kwatch
severity: normal
status: open
title: os.times() returns uncorrect value
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2205>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:39:58 2008
From: report at bugs.python.org (Xie Bengui)
Date: Fri, 29 Feb 2008 02:39:58 -0000
Subject: [New-bugs-announce] [issue2206] critical memory leak in hashlib.md5
Message-ID: <1204252798.22.0.882467230291.issue2206@psf.upfronthosting.co.za>


Changes by Xie Bengui:


----------
files: md5.txt
nosy: agateriver
severity: normal
status: open
title: critical memory leak in hashlib.md5
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9569/md5.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 11:47:43 2008
From: report at bugs.python.org (Tim Golden)
Date: Fri, 29 Feb 2008 10:47:43 -0000
Subject: [New-bugs-announce] [issue2207] Bug in Sphinx highlighting when
	pygments not available
In-Reply-To: <1204282063.81.0.343709498913.issue2207@psf.upfronthosting.co.za>
Message-ID: <1204282063.81.0.343709498913.issue2207@psf.upfronthosting.co.za>


New submission from Tim Golden:

When pygments is not available to the sphinx build environment, the
PygmentsBridge in the highlighting.py module raises an exception in the
unhighlighted function. This function attempts to use the .dest
attribute which isn't set in the __init__ if the pygments import has failed.

The attached patch moves the .dest setting up so it is always set
regardless of the presence of pygments. I don't know if it's a complete
solution, but the help, htmlhelp and web all build.

----------
components: Documentation tools (Sphinx)
files: sphinx-highlighting-r61125.patch
keywords: patch
messages: 63130
nosy: tim.golden
severity: normal
status: open
title: Bug in Sphinx highlighting when pygments not available
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9571/sphinx-highlighting-r61125.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2207>
__________________________________

From report at bugs.python.org  Fri Feb 29 12:00:41 2008
From: report at bugs.python.org (Tim Golden)
Date: Fri, 29 Feb 2008 11:00:41 -0000
Subject: [New-bugs-announce] [issue2208] Patch to doc/make.bat to allow
	non-standard HTML Help location
In-Reply-To: <1204282841.46.0.816451204729.issue2208@psf.upfronthosting.co.za>
Message-ID: <1204282841.46.0.816451204729.issue2208@psf.upfronthosting.co.za>


New submission from Tim Golden:

The doc/make.bat file for building the docs under Windows assumes the
standard location for the HTML Help Workshop. The attached patch looks
for  an env var called HTMLHELP and uses that if it's set, falling back
to the standard location.

----------
components: Documentation tools (Sphinx)
files: doc-make-r61125.patch
keywords: patch
messages: 63131
nosy: tim.golden
severity: normal
status: open
title: Patch to doc/make.bat to allow non-standard HTML Help location
versions: Python 2.6
Added file: http://bugs.python.org/file9572/doc-make-r61125.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2208>
__________________________________

From report at bugs.python.org  Fri Feb 29 12:14:46 2008
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_A._Erhard?=)
Date: Fri, 29 Feb 2008 11:14:46 -0000
Subject: [New-bugs-announce] [issue2209] mailbox module doesn't support
	compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>


New submission from J?rgen A. Erhard:

(Not sure if this goes here)
The mbox class (actually, the _singlefileMailbox class) takes a path,
and not, as the old mailbox module did, an opened file object.  This
makes it hard(er) to access gzipped mbox files (mailbox.open = gzip.open
works, but is ugly).

----------
components: Library (Lib)
messages: 63132
nosy: jae
severity: normal
status: open
title: mailbox module doesn't support compressed mbox
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
__________________________________

From report at bugs.python.org  Fri Feb 29 13:03:59 2008
From: report at bugs.python.org (=?utf-8?q?R=C3=BCdiger_Kupper?=)
Date: Fri, 29 Feb 2008 12:03:59 -0000
Subject: [New-bugs-announce] [issue2210] Nested module import clutters
	package namespace
In-Reply-To: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za>
Message-ID: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za>


New submission from R?diger Kupper:

When one module of a package imports another module of the same package,
the second module will not only be introduced in the namespace of the
importing module, but also in the namespace of the enclosing package.
I.e., the module will be introduced as variable
<packagename>.<secondmodulename>. If the package namespace contained a
variable of this name before the import, it will be overwritten by the
new value.

For the user, import statements should act like assignments to the local
 namespace. They should never add names to an enclosing namespace. (At
least this is what all documentation and tutorials tell the user.)

Below follows a detailed example for the problem.


Say I have a package named 'pack'. Apart from the '__init__.py' file the 
directory contains two modules 'x.py' and 'y.py':

pack/
      __init__.py
      x.py
      y.py

The files have the following contents:

==== __init__.py ====
import x
=====================

==== x.py ===========
import y
=====================

==== y.py ===========
pass
=====================

I then do
 >>> import pack

This
(1) introduces variable 'x' bound to <module 'pack.x'>
     in pack's namespace (expected)
(2) introduces variable 'q' bound to <module 'pack.y'>
     in x's namespace (expected)
but also
(3) introduces variable 'y' bound to <module 'pack.y'>
     in pack's namespace (*totally unexpected*)

The problem is so bad as to even overwrite any variable 'y' that 
might have existed in pack's namespace before the import.

I created verbose versions of the three files above to illustrate 
what happens (see below.) They do exactly the same as above, but 
print out what they do. This is the output:

---------snip-----------
 >>> import pack
pack: Here is pack.
pack: I now assign y='hello'.
pack: My y is now: 'hello'
pack: I now 'import x' which in turn does 'import y as q'.
   x: Here is x.
   x: I now 'import y as q'.
     y: Here is y.
pack: My y is now: <module 'pack.y' from 'pack/y.pyc'>
pack: Why?
--------snip-------------

I know that any import creates an entry in sys.modules. So 'pack', 
'pack.x' and 'pack.y' get created in sys.modules. That's fine.

Apart from that, an import statement should act equivalent to an 
assignment: it should introduce entries to the local namespace of the
module it appears in. The 'import y as q' appears in x.py, so it 
should add entries to x's namespace *only*.

But why is variable 'y' in pack's namespace overwritten by the 
import in x?


P.S.: These are the files that produce the verbose output. They can be
found in the tgz file attached to this issue.

==== __init__.py ====
print "pack: Here is pack."
print "pack: I now assign y='hello'."
y="hello"
print "pack: My y is now:", repr(y)
print "pack: I now 'import x' which in turn does 'import y as q'."
import x
print "pack: My y is now:", repr(y)
print "pack: Why?"
=====================

==== x.py ===========
print '  x: Here is x.'
print "  x: I now 'import y as q'."
import y as q
=====================

==== y.py ===========
print '    y: Here is y.'
=====================

----------
files: pack.tgz
messages: 63135
nosy: ruediger.kupper
severity: normal
status: open
title: Nested module import clutters package namespace
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file9574/pack.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2210>
__________________________________

From report at bugs.python.org  Fri Feb 29 21:00:59 2008
From: report at bugs.python.org (Jamie Bliss)
Date: Fri, 29 Feb 2008 20:00:59 -0000
Subject: [New-bugs-announce] [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>


New submission from Jamie Bliss:

Cookie.Morsel lacks in properly overloading dict methods, amongst other
things:
* .__eq__() does not take .key and .value into account
* .copy() returns a dict, not a Morsel
* .update() allows invalid attributes in, eg
Morsel().update({'eggs':'spam'}) works but Morsel()['eggs'] = 'spam' fails
* .__len__() includes unset keys (why does it set them to an empty string?)
* .__repr__() doesn't print out attributes (path, comment, etc)
* Handling of unicode is fuzzy at best: try Morsel().set(u'eggs\u00bf',
u'\u00f1', u'\00f1'.encode('utf-8'))
* Specifying the idmap and translate function in .set() seems wrong
* Setting .key doesn't check against invalid keys (eg, reserved names)
* The entire Morsel class is undocumented
* There is no way to automatically sync .value and .coded_value

----------
components: Library (Lib)
messages: 63144
nosy: astronouth7303
severity: normal
status: open
title: Cookie.Morsel interface needs update
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
__________________________________

From report at bugs.python.org  Fri Feb 29 21:07:49 2008
From: report at bugs.python.org (Jamie Bliss)
Date: Fri, 29 Feb 2008 20:07:49 -0000
Subject: [New-bugs-announce] [issue2212] Cookie.BaseCookie has ambiguous
	unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>


New submission from Jamie Bliss:

The primary offender is in BaseCookie.load(), which uses the test:
    type(rawdata) == type("")
which should be:
    isinstance(rawdata, basestring)

----------
components: Library (Lib)
messages: 63145
nosy: astronouth7303
severity: normal
status: open
title: Cookie.BaseCookie has ambiguous unicode handling
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
__________________________________