From report at bugs.python.org  Tue Apr  1 05:54:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 01 Apr 2008 03:54:16 +0000
Subject: [New-bugs-announce] [issue2525] class USTimeZone in
	Doc/includes/tzinfo-examples.py is out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

The USTimeZone example class hasn't been updated for the new US DST
rules that went into effect in 2007.  For a description of the new
rules, see:

http://wwp.greenwichmeantime.com/daylight-saving-time/usa/dst-2007.htm

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 64800
nosy: georg.brandl, gvanrossum
priority: high
severity: normal
status: open
title: class USTimeZone in Doc/includes/tzinfo-examples.py is out of date
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Apr  1 13:35:26 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 01 Apr 2008 11:35:26 +0000
Subject: [New-bugs-announce] [issue2526] str.format() :n format does not
	appear to work
In-Reply-To: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>
Message-ID: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

>>> # Py30a3
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "en_US.UTF8")
'en_US.UTF8'
>>> locale.format("%d", 12345, True)
'12,345'
>>> "{0:n}".format(12345)
'12345'

According to the docs the 'n' format should use the locale-dependent
separator, so I expected both strings to be '12,345'.

Also, it is a pity that locale.format() uses the old deprecated % syntax
rather than the much nicer and better str.format() syntax.

----------
components: Interpreter Core
messages: 64804
nosy: mark
severity: normal
status: open
title: str.format() :n format does not appear to work
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  1 14:13:47 2008
From: report at bugs.python.org (Peter Otten)
Date: Tue, 01 Apr 2008 12:13:47 +0000
Subject: [New-bugs-announce] [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>


New submission from Peter Otten <__peter__ at web.de>:

I'd like to suggest a different approach than the one taken in rev. 
54348 to improve timeit's scripting interface: allow passing it a 
namespace. Reasons:

- It has smaller overhead for functions that take an argument:
>>> def f(a): pass
...
# trunk
>>> min(ht.Timer(lambda f=f: f(42)).repeat())
0.54068493843078613
# my patch
>>> min(mt.Timer("f(42)", ns=dict(f=f)).repeat())
0.29009604454040527

- it is more flexible. Example:
# working code, requires matplotlib
from timeit import Timer
from time import sleep

def linear(i):
    sleep(.05*i)
def quadratic(i):
    sleep(.01*i**2)

x = range(10)
y = []
for a in x:
    y.append([min(Timer("f(a)", ns=dict(f=f, a=a)).repeat(1, 1))
              for f in linear, quadratic])

from pylab import plot, show
plot(x, y)
show()

The above code works unaltered inside a function, unlike the hacks 
using "from __main__ import ...".

- the implementation is simpler and should be easy to maintain.

The provided patch is against 2.5.1. If it has a chance of being 
accepted I'm willing to jump through the necessary hoops: 
documentation, tests, etc.

----------
components: Library (Lib)
files: diff_against_2_5_1.txt
messages: 64805
nosy: potten
severity: normal
status: open
title: Pass a namespace to timeit
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9916/diff_against_2_5_1.txt

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

From report at bugs.python.org  Tue Apr  1 16:19:18 2008
From: report at bugs.python.org (Tim Golden)
Date: Tue, 01 Apr 2008 14:19:18 +0000
Subject: [New-bugs-announce] [issue2528] Change os.access to check ACLs
	under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

At present, os.access under Windows simply calls GetFileAttributes to
determine the readonly attribute (ignoring directories). The patch
attached combines this with the use of the AccessCheck API to compare
the user's permissions with those required for the path.

I'm assuming that ATTRIB and CACLS will be available for use in the unit
tests included.

I haven't altered the structure of the posix_access function at all
although I suspect that it could now be simplified now that we're not
supporting Win9x.

----------
components: Library (Lib)
files: os_access-r62091.patch
keywords: patch
messages: 64811
nosy: tim.golden
severity: normal
status: open
title: Change os.access to check ACLs under Windows
versions: Python 2.6
Added file: http://bugs.python.org/file9919/os_access-r62091.patch

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

From report at bugs.python.org  Tue Apr  1 21:19:09 2008
From: report at bugs.python.org (Nick Guenther)
Date: Tue, 01 Apr 2008 19:19:09 +0000
Subject: [New-bugs-announce] [issue2529] list/generator comprehension parser
	doesn't match spec
In-Reply-To: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>
Message-ID: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>


New submission from Nick Guenther <kousu at users.sourceforge.net>:

I think I've found a bug in python's list comprehension parser. Observe:

>>> [e for i in j in ['a','b','c']]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'j' is not defined

Now, according to the grammar at http://docs.python.org/ref/lists.html,
a list comprehension is (condensed for clarity):
list_comprehension 	::= 	expression list_for
list_for 	::= 	"for" target_list "in" old_expression_list [list_for]

So a list comprehension should always be 
[.... for ... in .... for ... in ... for ... in ...]
(that is, alternating 'for's and 'in's) but here I have a test case that
python happily tries to run that looks like
[... for ... in ... in ....]

----------
components: Interpreter Core
messages: 64818
nosy: kousu
severity: normal
status: open
title: list/generator comprehension parser doesn't match spec
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  1 22:41:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 20:41:47 +0000
Subject: [New-bugs-announce] [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

The IO module currently has some docs strings but no official RST docs.
I'm willing to work on this.

----------
assignee: benjamin.peterson
components: Documentation
messages: 64822
nosy: benjamin.peterson, georg.brandl
priority: critical
severity: normal
status: open
title: Document IO module
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Wed Apr  2 00:11:37 2008
From: report at bugs.python.org (Jeremy Dunck)
Date: Tue, 01 Apr 2008 22:11:37 +0000
Subject: [New-bugs-announce] [issue2531] float compared to decimal is
	silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>


New submission from Jeremy Dunck <jdunck at users.sourceforge.net>:

Within python 2.5.2:

>>> from decimal import Decimal
>>> x = 3.0
>>> y = Decimal('0.25')
>>> x > y
False (expected error, as in 2.4, or True)

----------
components: Library (Lib)
messages: 64827
nosy: jdunck
severity: normal
status: open
title: float compared to decimal is silently incorrect.
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr  2 02:10:15 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 02 Apr 2008 00:10:15 +0000
Subject: [New-bugs-announce] [issue2532] file that breaks 2to3 (despite
	being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>


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

Infinite recursion problem. I know this file is obscure, but it's still
pretty valid python.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: ssl.py
messages: 64829
nosy: collinwinter, fijal
severity: normal
status: open
title: file that breaks 2to3 (despite being correct python)
Added file: http://bugs.python.org/file9921/ssl.py

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

From report at bugs.python.org  Wed Apr  2 04:23:59 2008
From: report at bugs.python.org (Thomas Dimson)
Date: Wed, 02 Apr 2008 02:23:59 +0000
Subject: [New-bugs-announce] [issue2533] Invalid TypeError with class method
	decorator and class method parameter
In-Reply-To: <1207103039.83.0.312467912668.issue2533@psf.upfronthosting.co.za>
Message-ID: <1207103039.83.0.312467912668.issue2533@psf.upfronthosting.co.za>


New submission from Thomas Dimson <tdimson at gmail.com>:

Having a peculiar issue (exception raised despite being valid) when
defining a decorator that takes a class method as a callback. Here is a
cooked example:

def decorator( callback ):
    def inner(func):
        def application( *args, **kwargs ):
            callback(*args,**kwargs)
            func(*args,**kwargs)
        return application
    return inner

class DecorateMe:
    @decorator( callback=DecorateMe.callback )
    def youBet( self ):
        pass
    def callback( self ):
        print "Hello!"

>>> DecorateMe().youBet()
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    DecorateMe().youBet()
  File "C:\Python25\badpython.py", line 4, in application
    callback(*args,**kwargs)
TypeError: unbound method callback() must be called with DecorateMe
instance as first argument (got DecorateMe instance instead)

If you change the line "callback=DecorateMe.callback" to
"callback=lambda x: DecorateMe.callback(x)" python gives you:

>>> DecorateMe().youBet()
Hello!

Mysteriously, I did encounter this during my coding with a non-cooked
decorator.

----------
components: None
messages: 64830
nosy: tdimson
severity: normal
status: open
title: Invalid TypeError with class method decorator and class method parameter
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Apr  2 11:47:48 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 02 Apr 2008 09:47:48 +0000
Subject: [New-bugs-announce] [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements type.__instancecheck__ and type.__subclasscheck__,
which speeds up isinstance and issubclass calls quite a bit.

See also issue #2303.

Here are the performance figures for the current trunk version:

Current SNV trunk:

Using 2.6a1+ (trunk:62102, Apr  2 2008, 11:30:16) [MSC v.1500 32 bit
(Intel)]
isinstance(42, int)	   1000000 loops, best of 3: 0.28 usec per loop
isinstance(42, type)	   1000000 loops, best of 3: 0.974 usec per loop
issubclass(object, type)   1000000 loops, best of 3: 1.1 usec per loop
issubclass(object, int)    1000000 loops, best of 3: 1.1 usec per loop
issubclass(float, int)     1000000 loops, best of 3: 1.15 usec per loop

Current trunk, patch applied:

Using 2.6a1+ (trunk:62102M, Apr  2 2008, 11:21:32) [MSC v.1500 32 bit
(Intel)]
isinstance(42, int)	   1000000 loops, best of 3: 0.274 usec per loop
isinstance(42, type)	   1000000 loops, best of 3: 0.524 usec per loop
issubclass(object, type)   1000000 loops, best of 3: 0.661 usec per loop
issubclass(object, int)    1000000 loops, best of 3: 0.662 usec per loop
issubclass(float, int)     1000000 loops, best of 3: 0.731 usec per loop

Python 2.5.2, for comparison:

Using 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
isinstance(42, int)	   1000000 loops, best of 3: 0.292 usec per loop
isinstance(42, type)	   1000000 loops, best of 3: 0.417 usec per loop
issubclass(object, type)   1000000 loops, best of 3: 0.626 usec per loop
issubclass(object, int)    1000000 loops, best of 3: 0.648 usec per loop
issubclass(float, int)     1000000 loops, best of 3: 0.752 usec per loop

----------
files: type_instancecheck.diff
keywords: patch, patch
messages: 64842
nosy: theller
severity: normal
status: open
title: Speed up isinstance and issubclass
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file9924/type_instancecheck.diff

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

From report at bugs.python.org  Wed Apr  2 12:40:04 2008
From: report at bugs.python.org (Matthias Kievernagel)
Date: Wed, 02 Apr 2008 10:40:04 +0000
Subject: [New-bugs-announce] [issue2535] duplicate Misc.lower
In-Reply-To: <1207132804.52.0.0603076560404.issue2535@psf.upfronthosting.co.za>
Message-ID: <1207132804.52.0.0603076560404.issue2535@psf.upfronthosting.co.za>


New submission from Matthias Kievernagel <mkiever at web.de>:

ron longo posted this remark in the Tkinter list:
>Don't know if this is the place to report this.  Not really a 
bug, >however,
>method lower() is defined twice in class Misc in the module 
Tkinter.py. 
>Both definitions are identical.

So I created a patch (against rev62104 which removes the first
occurrence which seems a bit out of order
(second one is grouped with raise).

Matthias.

----------
components: Tkinter
files: duplicateLower.patch
keywords: patch
messages: 64845
nosy: mkiever
severity: normal
status: open
title: duplicate Misc.lower
versions: Python 2.6
Added file: http://bugs.python.org/file9925/duplicateLower.patch

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

From report at bugs.python.org  Wed Apr  2 12:48:04 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 10:48:04 +0000
Subject: [New-bugs-announce] [issue2536] itertools.permutations docstring is
	misleading
In-Reply-To: <1207133284.49.0.529226014419.issue2536@psf.upfronthosting.co.za>
Message-ID: <1207133284.49.0.529226014419.issue2536@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu2 at users.sourceforge.net>:

Currently, Modules/itertoolsmodule.c lines 2471-2475 are:

PyDoc_STRVAR(permutations_doc,
"permutations(iterables[, r]) --> permutations object\n\
\n\
Return successive r-length permutations of elements in the iterable.\n\n\
permutations(range(4), 3) --> (0,1,2), (0,1,3), (0,2,3), (1,2,3)");

but that describes  behavior of itertools.combinations. The correct
example is in a comment on line 2254 of the same file:

'permutations(range(3), 2) --> (0,1) (0,2) (1,0) (1,2) (2,0) (2,1)'


I used "misleading" instead of "wrong" because the current docstring
does show a subset of the real output and could be said to be
incomplete. If that is the case, I suggest being explicit:

'permutations(range(4), 3) --> (0, 1, 2), (0, 1, 3), (0, 2, 1), (0, 2,
3), (0, 3, 1), (0, 3, 2), (1, 0, 2), (1, 0, 3), (1, 2, 0), (1, 2, 3),
(1, 3, 0), (1, 3, 2), (2, 0, 1), (2, 0, 3), (2, 1, 0), (2, 1, 3), (2, 3,
0), (2, 3, 1), (3, 0, 1), (3, 0, 2), (3, 1, 0), (3, 1, 2), (3, 2, 0),
(3, 2, 1)'

----------
components: Library (Lib)
messages: 64846
nosy: ajaksu2, rhettinger
severity: normal
status: open
title: itertools.permutations docstring is misleading
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  2 19:36:06 2008
From: report at bugs.python.org (Jason Orendorff)
Date: Wed, 02 Apr 2008 17:36:06 +0000
Subject: [New-bugs-announce] [issue2537] re.compile(r'((x|y+)*)*') should
	fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>


New submission from Jason Orendorff <jason.orendorff at gmail.com>:

Below, the second regexp seems just as guilty as the first to me.

Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile(r'((x|y)*)*')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py",
line 180, in compile
    return _compile(pattern, flags)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py",
line 233, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat
>>> re.compile(r'((x|y+)*)*')
<_sre.SRE_Pattern object at 0x18548>

I don't know if that error is to protect the sre engine from bad
patterns or just a courtesy to users.  If the former, it could be a
serious bug.

----------
messages: 64865
nosy: jorendorff
severity: normal
status: open
title: re.compile(r'((x|y+)*)*') should fail
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr  3 02:26:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Apr 2008 00:26:22 +0000
Subject: [New-bugs-announce] [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Bytes should be immutable, but in test_socket.py:
    buf = b" "*1024
    nbytes = self.cli_conn.recv_into(buf)

This patch attempts to enforce readonly buffer on bytes

----------
components: Interpreter Core
files: buffer.patch
keywords: patch
messages: 64886
nosy: amaury.forgeotdarc
severity: normal
status: open
title: memoryview of bytes is not readonly
versions: Python 3.0
Added file: http://bugs.python.org/file9929/buffer.patch

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

From report at bugs.python.org  Thu Apr  3 04:16:26 2008
From: report at bugs.python.org (Jason)
Date: Thu, 03 Apr 2008 02:16:26 +0000
Subject: [New-bugs-announce] [issue2539] Windows Registry issue with 2.5.2
	AMD64 msi
In-Reply-To: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>
Message-ID: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>


New submission from Jason <iggyboo at bestmail.us>:

I have tried multiple times and even checking manually, but the
Python 2.5.2 AMD64 msi installer does not register Python correctly, or
it doesn't enter it into the registry correctly.  I'm not sure.  I
install it after uninstalling 2.5.1 and and when I try to install
wxPython2.8 and pygtk-2.10.6 both give me an error that they cannot find
Python or its path in the registry.  I reinstall 2.5.1 and it all works
perfectly.  I'm using all default selections and just clicking
"Next,Next,Next, etc."

----------
components: Installation
messages: 64887
nosy: iggyboo
severity: normal
status: open
title: Windows Registry issue with 2.5.2 AMD64 msi
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr  3 06:00:32 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 03 Apr 2008 04:00:32 +0000
Subject: [New-bugs-announce] [issue2540] If HAVE_LONG_LONG is not defined,
	longval will not be initialized (_sqlite)
In-Reply-To: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>
Message-ID: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

I noticed compiler warned "'longval' is not used anywhere."
And I found 'longval' was not initialized where HAVE_LONG_LONG
was not defined. Is attached patch intended behavior? Thanks.

----------
components: Extension Modules
files: fix.patch
keywords: easy, patch, patch
messages: 64888
nosy: ocean-city
severity: normal
status: open
title: If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9930/fix.patch

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

From report at bugs.python.org  Thu Apr  3 06:19:06 2008
From: report at bugs.python.org (John Millikin)
Date: Thu, 03 Apr 2008 04:19:06 +0000
Subject: [New-bugs-announce] [issue2541] Unicode escape sequences not parsed
	in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

According to
<http://docs.python.org/dev/3.0/reference/lexical_analysis.html#id9>,
raw strings with \u and \U escape sequences should have these sequences
parsed as usual. However, they are currently escaped.

>>> r'\u0020'
'\\u0020'

Expected:
>>> r'\u0020'
' '

----------
components: Unicode
messages: 64890
nosy: jmillikin
severity: normal
status: open
title: Unicode escape sequences not parsed in raw strings.
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Apr  3 10:59:00 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 08:59:00 +0000
Subject: [New-bugs-announce] [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

PyErr_ExceptionMatches must not fail, according to the docs.  So an
error code from PyObject_IsSubclass() cannot be returned.

The attached patch calls PyErr_WriteUnraisable in this case, and returns
an arbitrary value (0 was chosen in the patch).

See also issue #2534.

----------
components: Interpreter Core
files: errors.diff
keywords: patch, patch
messages: 64894
nosy: theller
severity: normal
status: open
title: PyErr_ExceptionMatches must not fail
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9931/errors.diff

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

From report at bugs.python.org  Thu Apr  3 22:10:36 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 20:10:36 +0000
Subject: [New-bugs-announce] [issue2543] Make ctypes compatible with Python
	2.3, 2.4, and 2.5, as per PEP291
In-Reply-To: <1207253436.39.0.0138012996371.issue2543@psf.upfronthosting.co.za>
Message-ID: <1207253436.39.0.0138012996371.issue2543@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

To be committed after the current release is out.

----------
assignee: theller
components: ctypes
files: ctypes-compat-py23.diff
keywords: patch, patch
messages: 64904
nosy: theller
severity: normal
status: open
title: Make ctypes compatible with Python 2.3, 2.4, and 2.5, as per PEP291
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file9934/ctypes-compat-py23.diff

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

From report at bugs.python.org  Thu Apr  3 23:08:06 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 21:08:06 +0000
Subject: [New-bugs-announce] [issue2544] link with "gcc -shared" on HP
	systems
In-Reply-To: <1207256886.04.0.563563345586.issue2544@psf.upfronthosting.co.za>
Message-ID: <1207256886.04.0.563563345586.issue2544@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

As discussed in issue #1582742, this patch uses 'gcc -shared' as linker
on HP systems when compiling with gcc.  It fixes a problem in the ctypes
test-suite, that _ctypes_test.so cannot be dynloaded because of missing
symbols.

To be committed after the current alpha-release is out.

----------
assignee: theller
components: Build
files: configure.diff
keywords: patch, patch
messages: 64906
nosy: theller
severity: normal
status: open
title: link with "gcc -shared" on HP systems
versions: Python 2.6
Added file: http://bugs.python.org/file9935/configure.diff

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

From report at bugs.python.org  Fri Apr  4 06:29:12 2008
From: report at bugs.python.org (John Millikin)
Date: Fri, 04 Apr 2008 04:29:12 +0000
Subject: [New-bugs-announce] [issue2545] sphinx.ext.autodoc fails to expand
	tabs in docstrings
In-Reply-To: <1207283352.64.0.672793099333.issue2545@psf.upfronthosting.co.za>
Message-ID: <1207283352.64.0.672793099333.issue2545@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

Sphinx seems to need tabs expanded in reST, but the autodoc extension
doesn't do so. The following patch is very small, and fixes the issue on
my system.

Oddly, I can reproduce this on a Linux system with doctools and docutils
trunk, but not on a Mac with doctools and docutils trunk vOv.

Index: ext/autodoc.py
===================================================================
--- ext/autodoc.py      (revision 62140)
+++ ext/autodoc.py      (working copy)
@@ -41,7 +41,8 @@
     """
     if not s or s.isspace():
         return ['']
-    nl = s.expandtabs().rstrip().find('\n')
+    s = s.expandtabs ()
+    nl = s.rstrip().find('\n')
     if nl == -1:
         # Only one line...
         return [s.strip(), '']

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 64912
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: sphinx.ext.autodoc fails to expand tabs in docstrings
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr  4 07:29:00 2008
From: report at bugs.python.org (George Verbitsky)
Date: Fri, 04 Apr 2008 05:29:00 +0000
Subject: [New-bugs-announce] [issue2546] Python-2.5.2: crash in visit_decref
	() at Modules/gcmodule.c:270
In-Reply-To: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>
Message-ID: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>


New submission from George Verbitsky <garikvm at yahoo.com>:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208408368 (LWP 2816)]
0x080edccd in visit_decref (op=0xbf9289ff, data=0x0) at
Modules/gcmodule.c:270
270             if (PyObject_IS_GC(op)) {
(gdb) bt
#0  0x080edccd in visit_decref (op=0xbf9289ff, data=0x0) at
Modules/gcmodule.c:270
#1  0x08099e19 in tupletraverse (o=0xb7f2380c, visit=0x80edcc0
<visit_decref>, arg=0x0)
    at Objects/tupleobject.c:443
#2  0x080ee63e in collect (generation=0) at Modules/gcmodule.c:295
#3  0x080ef159 in _PyObject_GC_NewVar (tp=0x8170700, nitems=14) at
Modules/gcmodule.c:897
#4  0x08111f10 in PyFrame_New (tstate=0x8bdd128, code=0xb7d04410,
globals=0xb7cd3934, locals=0x0)
    at Objects/frameobject.c:614
#5  0x080c521a in PyEval_EvalFrameEx (f=0x8cf0fb4, throwflag=0) at
Python/ceval.c:3639
#6  0x080c5265 in PyEval_EvalFrameEx (f=0x8ced7bc, throwflag=0) at
Python/ceval.c:3650
#7  0x080c5265 in PyEval_EvalFrameEx (f=0x8ced484, throwflag=0) at
Python/ceval.c:3650
#8  0x080c5265 in PyEval_EvalFrameEx (f=0x8ce7dbc, throwflag=0) at
Python/ceval.c:3650
#9  0x080c5265 in PyEval_EvalFrameEx (f=0x8ce7c5c, throwflag=0) at
Python/ceval.c:3650
#10 0x080c6075 in PyEval_EvalCodeEx (co=0xb7c2d608, globals=0xb7c18e84,
locals=0x0, args=0xb7f28378, 
    argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2831
#11 0x08112871 in function_call (func=0xb7c2af44, arg=0xb7f2836c,
kw=0x0) at Objects/funcobject.c:517
#12 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f2836c, kw=0x0) at
Objects/abstract.c:1860
#13 0x08067937 in instancemethod_call (func=0xb7f1302c, arg=0xb7f2836c,
kw=0x0) at Objects/classobject.c:2497
#14 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f5202c, kw=0x0) at
Objects/abstract.c:1860
#15 0x0809d7cb in slot_tp_init (self=0xb7c3442c, args=0xb7f5202c,
kwds=0x0) at Objects/typeobject.c:4862
#16 0x080a0393 in type_call (type=0x8c5d04c, args=0xb7f5202c, kwds=0x0)
at Objects/typeobject.c:436
#17 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f5202c, kw=0x0) at
Objects/abstract.c:1860
#18 0x080c1149 in PyEval_EvalFrameEx (f=0x8ce7afc, throwflag=0) at
Python/ceval.c:3775
#19 0x080c6075 in PyEval_EvalCodeEx (co=0xb7c2d4a0, globals=0xb7c83934,
locals=0x0, args=0xb7f23818, 
    argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2831
#20 0x08112871 in function_call (func=0xb7c2ae64, arg=0xb7f2380c,
kw=0x0) at Objects/funcobject.c:517
#21 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f2380c, kw=0x0) at
Objects/abstract.c:1860
#22 0x080be26c in PyEval_CallObjectWithKeywords (func=0xb7c2ae64,
arg=0xb7f2380c, kw=0x0)
    at Python/ceval.c:3433
#23 0x08061c30 in PyObject_CallObject (o=0xb7c2ae64, a=0xb7f2380c) at
Objects/abstract.c:1851
#24 0x08061879 in C2py (func=0x81380c5 "backend", nargs=1) at C2py.c:52
#25 0x0806191d in backend (output_filename=0xbf9289ff "cla") at backend.c:5
#26 0x08056fa5 in main (argc=3, argv=0xbf9271b4) at main.c:33
(gdb)

----------
components: Interpreter Core
messages: 64915
nosy: garikvm
severity: normal
status: open
title: Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr  4 08:29:48 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 04 Apr 2008 06:29:48 +0000
Subject: [New-bugs-announce] [issue2547] Py30a4 RELNOTES only cover 30a1 and
	30a2
In-Reply-To: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>
Message-ID: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

The 30a4 RELNOTES file doesn't cover 30a3 or 30a4.

----------
assignee: georg.brandl
components: Documentation
messages: 64918
nosy: georg.brandl, mark
severity: normal
status: open
title: Py30a4 RELNOTES only cover 30a1 and 30a2
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Fri Apr  4 10:16:42 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Apr 2008 08:16:42 +0000
Subject: [New-bugs-announce] [issue2548] Undetected error in exception
	handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

[Found by Daniel Diniz (ajaksu2), see issue #2542]

The following code triggers an undetected error with a debug build:

"""
import sys
def g():
  try:
    return g()
  except:
    return sys.exc_info()
g()
print 42
"""

Running the code prints this:

C:\svn\trunk\PCbuild>python_d test2.py
42
XXX undetected error
Traceback (most recent call last):
  File "test2.py", line 8, in <module>
    print 42
RuntimeError: maximum recursion depth exceeded
[8826 refs]

C:\svn\trunk\PCbuild>

----------
components: Interpreter Core
messages: 64920
nosy: theller
severity: normal
status: open
title: Undetected error in exception handling
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 16:44:18 2008
From: report at bugs.python.org (Chabod)
Date: Fri, 04 Apr 2008 14:44:18 +0000
Subject: [New-bugs-announce] [issue2549] shutil: NameError (WindowsWrror)
	when moving from ext3 to fat32 under linux
In-Reply-To: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>
Message-ID: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>


New submission from Chabod <jerome.chabod at ifrance.com>:

shutil generate a NameError (WindowsError) exception when moving a
directory from an ext3 to a fat32 under linux

To reproduce it: 
under linux, current path on an ext3 filesytem, try to enter following
commands: 
mkdir toto #on an ext3 partition
python
import shutil
shutil.move("toto", "/media/fat32/toto") # /media/fat32 is mounted on a
fat32 filesystem

You will produce following error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/shutil.py", line 196, in move
    copytree(src, dst, symlinks=True)
  File "/usr/lib/python2.5/shutil.py", line 132, in copytree
    except WindowsError:
NameError: global name 'WindowsError' is not defined

Tested on ubuntu Feisty and a newly installed Hardy-beta.

----------
components: Library (Lib)
messages: 64930
nosy: jerome.chabod
severity: normal
status: open
title: shutil: NameError (WindowsWrror) when moving from ext3 to fat32 under linux
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr  4 17:58:00 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 04 Apr 2008 15:58:00 +0000
Subject: [New-bugs-announce] [issue2550] SO_REUSEADDR doesn't have the same
	semantics on Windows as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>


New submission from Trent Nelson <tnelson at onresolve.com>:

Background: I came across this issue when trying to track down why 
test_asynchat would periodically wedge python processes on the Windows 
buildbots, to the point that they wouldn't even respond to SIGKILL (or 
ctrl-c on the console).

What I found after a bit of digging is that Windows doesn't raise 
EADDRINUSE socket.errors when you bind() two sockets to identical 
host/ports *IFF* SO_REUSEADDR has been set as a socket option.

Decided to brighten up my tube journey into work this morning by 
reading the Gospel's take on the situation.  As per the 'SO_REUSEADDR 
and SO_REUSEPORT Socket Options' section in chapter 7.5 of Stevens' 
UNIX Network Programming Volume 1 (2nd Ed):

"With TCP, we are never able to start multiple servers that bind
 the same IP address and same port: a completely duplicate binding.
 That is, we cannot start one server that binds 198.69.10.2 port 80
 and start another that also binds 198.69.10.2 port 80, even if we
 set the SO_REUSEADDR socket option for the second server."

So, it seems at least Windows isn't adhering to this, at least on XP 
and Server 2008 with 2.5-2.6.  I've patched test_socket.py to 
explicitly test for this situation -- as expected, it passes on Unix 
(tested on FreeBSD in particular), and fails on Windows.  I'd like to 
commit this to trunk to see if any of the buildbots for different 
platforms match the behaviour of Windows.

----------
assignee: Trent.Nelson
components: Library (Lib), Windows
files: test_socket.py.patch
keywords: 26backport, patch
messages: 64933
nosy: Trent.Nelson
priority: high
severity: normal
status: open
title: SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9939/test_socket.py.patch

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

From report at bugs.python.org  Fri Apr  4 20:55:04 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 18:55:04 +0000
Subject: [New-bugs-announce] [issue2551] Python 2.6a2 on Solaris 10 built
	with SUN C
In-Reply-To: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>
Message-ID: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

Below is the tail of the output of 'make test' for 32-bit Python 2.6a2 
on Solaris 10 (Opteron) built with the SUN C compiler.

310 tests OK.
1 test failed:
    test_ioctl
41 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_epoll test_gdbm test_gl test_imageop test_imgfile
    test_kqueue test_linuxaudiodev test_macostools test_normalization
    test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
    test_socket_ssl test_socketserver test_sqlite test_ssl
    test_startfile test_tcl test_timeout test_unicode_file
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_zipfile64
3 skips unexpected on sunos5:
    test_tcl test_ssl test_ctypes


The ctypes test failed since the _ctypes module did not compile.
...
cc -KPIC -xtarget=native -DNDEBUG -xO5 -I. -I/.../tools/Python-
2.6a2/./Include -Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include -
Ibuild/temp.solaris-2.10-i86pc-2.6/libffi -I/.../tools/Python-
2.6a2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -
I/.../tools/Python-2.6a2/Include -I/.../tools/Python-2.6a2 -c 
.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-
2.10-i86pc-2.6/.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.o
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 67: 
undefined symbol: FFI_DEFAULT_ABI
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 68: 
non-constant enumerator value
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
syntax error before or at: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: old-style declaration or incorrect type for: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: syntax error:  empty declaration
".../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c", line 155: cannot 
recover from previous errors
cc: acomp failed for /.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c
...


The test_ioctl failures seems test related.
...
test test_ioctl failed -- Traceback (most recent call last):
  File "/.../tools/Python-2.6a2/Lib/test/test_ioctl.py", line 56, in 
test_ioctl_signed_unsigned_code_param
    saved_winsz = fcntl.ioctl(mfd, termios.TIOCGWINSZ, "\0"*8)
IOError: [Errno 22] Invalid argument
...

There is no SSL support and Tcl is not installed on this machine.  

Finally, this failure does not show up in the summary:
...
test_parser
Expecting 's_push: parser stack overflow' in next line
s_push: parser stack overflow
...

----------
components: Tests
messages: 64937
nosy: MrJean1
severity: normal
status: open
title: Python 2.6a2 on Solaris 10 built with SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 22:01:51 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:01:51 +0000
Subject: [New-bugs-announce] [issue2552] test_ctypes failed Python 2.6a2
	Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The ctypes test failed since the _ctypes module did not compile for 32-
bit Python 2.6a2 on Solaris 10 (Opteron) built with the SUN C compiler.

...
cc -KPIC -xtarget=native -DNDEBUG -xO5 -I. -I/.../tools/Python-
2.6a2/./Include -Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include -
Ibuild/temp.solaris-2.10-i86pc-2.6/libffi -I/.../tools/Python-
2.6a2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -
I/.../tools/Python-2.6a2/Include -I/.../tools/Python-2.6a2 -c 
.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-
2.10-i86pc-2.6/.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.o
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 67: 
undefined symbol: FFI_DEFAULT_ABI
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 68: 
non-constant enumerator value
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
syntax error before or at: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: old-style declaration or incorrect type for: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: syntax error:  empty declaration
".../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c", line 155: cannot 
recover from previous errors
cc: acomp failed for /.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c
...

----------
components: Tests
messages: 64941
nosy: MrJean1
severity: normal
status: open
title: test_ctypes failed Python 2.6a2 Solaris 10 SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 22:03:40 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:03:40 +0000
Subject: [New-bugs-announce] [issue2553] test_ioctrl failed Python 2.6a2
	Solaris 10 SUN C
In-Reply-To: <1207339420.13.0.8802001202.issue2553@psf.upfronthosting.co.za>
Message-ID: <1207339420.13.0.8802001202.issue2553@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The test_ioctl failed in Python 2.6a2 built on Solaris 10 with the SUNC 
C compiler.

...
test test_ioctl failed -- Traceback (most recent call last):
  File "/.../tools/Python-2.6a2/Lib/test/test_ioctl.py", line 56, in 
test_ioctl_signed_unsigned_code_param
    saved_winsz = fcntl.ioctl(mfd, termios.TIOCGWINSZ, "\0"*8)
IOError: [Errno 22] Invalid argument
...

----------
messages: 64942
nosy: MrJean1
severity: normal
status: open
title: test_ioctrl failed Python 2.6a2 Solaris 10 SUN C

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

From report at bugs.python.org  Fri Apr  4 22:05:45 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:05:45 +0000
Subject: [New-bugs-announce] [issue2554] test_ioctl failed Python 2.6a2
	Solaris 10 SUN C
In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>
Message-ID: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The test_ioctl failed in 32-bit Python 2.6a2 built on Solaris 10 with 
the SUNC C compiler.

...
test test_ioctl failed -- Traceback (most recent call last):
  File "/.../tools/Python-2.6a2/Lib/test/test_ioctl.py", line 56, in 
test_ioctl_signed_unsigned_code_param
    saved_winsz = fcntl.ioctl(mfd, termios.TIOCGWINSZ, "\0"*8)
IOError: [Errno 22] Invalid argument
...

----------
components: Tests
messages: 64943
nosy: MrJean1
severity: normal
status: open
title: test_ioctl failed Python 2.6a2 Solaris 10 SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 22:08:05 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:08:05 +0000
Subject: [New-bugs-announce] [issue2555] test_parser failed Python 2.6a2
	Solaris 10 SUN C
In-Reply-To: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>
Message-ID: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

For 32-bit Python 2.6a2 on Solaris 10 (Opteron) built with the SUN C 
compiler this test_parser failure does not show up in the summary.

...
test_parser
Expecting 's_push: parser stack overflow' in next line
s_push: parser stack overflow
...

----------
components: Tests
messages: 64944
nosy: MrJean1
severity: normal
status: open
title: test_parser failed Python 2.6a2 Solaris 10 SUN C
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr  5 16:43:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:43:09 +0000
Subject: [New-bugs-announce] [issue2556] changing sys.dont_write_bytecode
	has not effect
In-Reply-To: <1207406589.36.0.590521129385.issue2556@psf.upfronthosting.co.za>
Message-ID: <1207406589.36.0.590521129385.issue2556@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

According to the 2.6 docs, says you can set it yourself to control
bytecode generation. That doesn't work because the dont_write_bytecode
flag is set from command option and never looked at again. Either we
should remove this misleading information or use PySys_GetObject in
pythonrun.c where the flag is used.

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 64976
nosy: benjamin.peterson, georg.brandl
priority: high
severity: normal
status: open
title: changing sys.dont_write_bytecode has not effect
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr  5 16:45:36 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Apr 2008 14:45:36 +0000
Subject: [New-bugs-announce] [issue2557] \u and \U in raw strings have
	reverted
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

In 2.x, \uDDDD and \UDDDDDDDD are interpreted as Unicode escapes in
raw Unicode strings. That was a mistake, but we can't fix it (except
when using "from __future__ import unicode_literals"). In 3.0, \u or
\U in a raw string should have no special meaning -- it's just a
backslash followed by 'u' or 'U'.

This was fixed in 3.0a3. It seems to have reverted to the old (2.x)
behavior in 3.0a4.

THIS MUST BE FIXED!

----------
messages: 64977
nosy: gvanrossum
priority: release blocker
severity: normal
status: open
title: \u and \U in raw strings have reverted
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sat Apr  5 19:42:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 17:42:32 +0000
Subject: [New-bugs-announce] [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>


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

A new pickle protocol was added to Py3k; it needs to be mentioned in the
docs.

----------
assignee: georg.brandl
components: Documentation
messages: 64993
nosy: georg.brandl
severity: normal
status: open
title: Document pickle protocol 3
versions: Python 3.0

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

From report at bugs.python.org  Sat Apr  5 21:27:08 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 05 Apr 2008 19:27:08 +0000
Subject: [New-bugs-announce] [issue2559] atom sorting error when buiding
	ctypes
In-Reply-To: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>
Message-ID: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I recently started getting the following error when building the
trunk on Mac OS X Leopard:

  ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o

I tried rm'ing my build directory then rerunning configure.  Same
result.  Here's the make output after simply removing all '*ctypes*'
files from the build directory:

% find build -name '*ctypes*' | xargs rm -r
% make
running build
running build_ext
building '_ctypes_test' extension
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include -I. -IInclude -I./Include
-I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.o
gcc -L/Users/skip/local/lib -L/opt/local/lib -bundle -undefined
dynamic_lookup
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.o
-L/Users/skip/local/lib -L/opt/local/lib -o
build/lib.macosx-10.3-i386-2.6/_ctypes_test.so
building '_ctypes' extension
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/callproc.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callproc.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/cfield.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/cfield.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/malloc_closure.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/malloc_closure.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/darwin/dlfcn_simple.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin/dlfcn_simple.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/ffi.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/ffi.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi64.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.o
-DMACOSX
gcc -L/Users/skip/local/lib -L/opt/local/lib -bundle -undefined
dynamic_lookup
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callproc.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/cfield.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/malloc_closure.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin/dlfcn_simple.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/ffi.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi64.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.o
-L/Users/skip/local/lib -L/opt/local/lib -o
build/lib.macosx-10.3-i386-2.6/_ctypes.so
ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o
ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o

----------
assignee: theller
components: ctypes
messages: 65001
nosy: skip.montanaro, theller
severity: normal
status: open
title: atom sorting error when buiding ctypes
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr  6 04:00:25 2008
From: report at bugs.python.org (Joseph Armbruster)
Date: Sun, 06 Apr 2008 02:00:25 +0000
Subject: [New-bugs-announce] [issue2560] removal of stale code from
	myreadline.c
In-Reply-To: <1207447225.31.0.495506522061.issue2560@psf.upfronthosting.co.za>
Message-ID: <1207447225.31.0.495506522061.issue2560@psf.upfronthosting.co.za>


New submission from Joseph Armbruster <JosephArmbruster at gmail.com>:

This patch removes a stale for loop from myreadline.c:

http://svn.python.org/projects/python/trunk @ 62180

----------
components: Interpreter Core
files: myreadline.patch
keywords: patch
messages: 65015
nosy: JosephArmbruster
severity: normal
status: open
title: removal of stale code from myreadline.c
versions: Python 2.6
Added file: http://bugs.python.org/file9956/myreadline.patch

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

From report at bugs.python.org  Sun Apr  6 09:31:59 2008
From: report at bugs.python.org (Werner Arnhold)
Date: Sun, 06 Apr 2008 07:31:59 +0000
Subject: [New-bugs-announce] [issue2561] Instance remembers old values from
	former life
In-Reply-To: <1207467119.29.0.203167301523.issue2561@psf.upfronthosting.co.za>
Message-ID: <1207467119.29.0.203167301523.issue2561@psf.upfronthosting.co.za>


New submission from Werner Arnhold <warnhold at zedat.fu-berlin.de>:

I don't know if it is a bug or a feature but the result seems to be
wrong for me: A constructor argument remembers its values from the last call

----------
files: class_with_listparamdefault.py
messages: 65024
nosy: warnhold
severity: normal
status: open
title: Instance remembers old values from former life
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9959/class_with_listparamdefault.py

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

From report at bugs.python.org  Sun Apr  6 11:47:19 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 09:47:19 +0000
Subject: [New-bugs-announce] [issue2562] Cannot use non-ascii letters in
	disutils if setuptools is used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>


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

If I try to put my name in the Author field as a string field, 
it will brake because distutils makes the assumption that 
the fields are string encoded in ascii, before it decodes
it into unicode, then encode it in utf8 to send the data.

See in distutils.command.register.post_to_server :

value = unicode(value).encode("utf-8")


One way to avoid this error is to provide unicode for all field,
but will fail farther if setuptools is used, because
this other package makes the assumption that the fields *are* strings::

self.run_command('egg_info')
...
distutils/dist.py", line 1047, in write_pkg_info
    pkg_info.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 18: ordinal not in range(128)

So I guess distutils shouldn't guess that it receives ascii strings
and do a raw unicode() call, and should make the assumption that 
it receives unicode fields only.


Since many packages out there use strings, I have left a unicode()
call in my patch, together with a warning. 

test provided.

----------
components: Distutils
files: unicode.patch
keywords: patch
messages: 65028
nosy: tarek
severity: normal
status: open
title: Cannot use non-ascii letters in disutils if setuptools is used.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9960/unicode.patch

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

From report at bugs.python.org  Sun Apr  6 15:52:29 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 06 Apr 2008 13:52:29 +0000
Subject: [New-bugs-announce] [issue2563] embed manifest in windows extensions
In-Reply-To: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>
Message-ID: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The move to vs2008 has caused .manifest files to be created next to
distutils created extensions modules, rather than being embedded as
recommended by Microsoft.

See http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx

The attached patch achieves this by telling the compiler to generate the
manifest in the temp dir, them embeds that manifest using mt.exe

Adding Christian for comment (hopefully the correct Christian this time
  - sorry about that :)

----------
assignee: mhammond
components: Distutils
files: embed_manifest.patch
keywords: patch, patch
messages: 65034
nosy: mhammond, tiran
severity: normal
status: open
title: embed manifest in windows extensions
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9962/embed_manifest.patch

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

From report at bugs.python.org  Sun Apr  6 18:05:14 2008
From: report at bugs.python.org (=?utf-8?q?Taavi_Rep=C3=A4n?=)
Date: Sun, 06 Apr 2008 16:05:14 +0000
Subject: [New-bugs-announce] [issue2564] Python hangs on FreeBSD7 in
	test_capi
Message-ID: <1207497914.96.0.303661363034.issue2564@psf.upfronthosting.co.za>


Changes by Taavi Rep?n <trepan at gmail.com>:


----------
components: None
nosy: trepan
severity: normal
status: open
title: Python hangs on FreeBSD7 in test_capi
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr  7 02:30:03 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Apr 2008 00:30:03 +0000
Subject: [New-bugs-announce] [issue2565] Change 'type' to 'class' in
	repr/str(builtin-class)
In-Reply-To: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>
Message-ID: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>


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

>From py3 devel list today:
------------------------------------------------------------------------
>  r23331 | gvanrossum | 2001-09-25 05:56:29 +0200 (Di, 25 Sep 2001) | 5
lines
>
>  Change repr() of a new-style class to say <class 'ClassName'> rather
>  than <type 'ClassName'>.  Exception: if it's a built-in type or an
>  extension type, continue to call it <type 'ClassName>.
------------------------------------------------------------------------
Well, if we're going to break user code, 3.0 is the time to do it. :-)

----------
components: Extension Modules, Interpreter Core
keywords: easy
messages: 65058
nosy: tjreedy
severity: normal
status: open
title: Change 'type' to 'class' in repr/str(builtin-class)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 05:29:55 2008
From: report at bugs.python.org (delimy)
Date: Mon, 07 Apr 2008 03:29:55 +0000
Subject: [New-bugs-announce] [issue2566] Py3.0a4 wsgiref simple_server
	failed to start
In-Reply-To: <1207538995.31.0.628770173127.issue2566@psf.upfronthosting.co.za>
Message-ID: <1207538995.31.0.628770173127.issue2566@psf.upfronthosting.co.za>


New submission from delimy <delimy at exoweb.net>:

Here's the most recent traceback:

  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
116, in finish_response
    self.write(data)
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
199, in write
    self.send_headers()
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
255, in send_headers
    self.send_preamble()
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
178, in send_preamble
    self._write('HTTP/%s %s\r\n' % (self.http_version,self.status))
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
385, in _write
    self.stdout.write(data)
  File "/home/delimy/temp/Python-3.0a4/Lib/socket.py", line 222, in write
    return self._sock.send(b)
TypeError: send() argument 1 must be bytes or read-only buffer, not str

It should convert str to bytes before write to stdout.

----------
components: Library (Lib)
messages: 65063
nosy: delimy
severity: normal
status: open
title: Py3.0a4 wsgiref simple_server failed to start
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 07:39:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 05:39:52 +0000
Subject: [New-bugs-announce] [issue2567] Section "New-style and classic
	classes" needs to be removed/rewritten
In-Reply-To: <1207546792.82.0.239101665386.issue2567@psf.upfronthosting.co.za>
Message-ID: <1207546792.82.0.239101665386.issue2567@psf.upfronthosting.co.za>


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

There are no classic classes anymore in Python.

----------
assignee: georg.brandl
components: Documentation
messages: 65065
nosy: georg.brandl, loewis
severity: normal
status: open
title: Section "New-style and classic classes" needs to be removed/rewritten
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 08:53:13 2008
From: report at bugs.python.org (Anton Fedorov)
Date: Mon, 07 Apr 2008 06:53:13 +0000
Subject: [New-bugs-announce] [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>


New submission from Anton Fedorov <datacompboy at call2ru.com>:

"%S	Second as a decimal number [00,61].	(2)
(2) The range really is 0 to 61; this accounts for leap seconds and the 
(very rare) double leap seconds."

That is wrong. There NEVER can be two leap seconds in one moment, since UTC 
time keep the difference between UTC and UT1 from exceeding ?0.9 s.

Leap seconds occur only at the end of a UTC month, and have only ever been 
inserted at the end of June 30 or December 31.

So, 61 is wrong, real seconds range from 0 to 60 inclusive.

----------
components: Library (Lib)
messages: 65067
nosy: datacompboy
severity: normal
status: open
title: Seconds range in time unit
type: behavior

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

From report at bugs.python.org  Mon Apr  7 10:37:56 2008
From: report at bugs.python.org (pk)
Date: Mon, 07 Apr 2008 08:37:56 +0000
Subject: [New-bugs-announce] [issue2569] default_scheme in
	urlparse.urlparse() useless
In-Reply-To: <1207557475.98.0.0117394691364.issue2569@psf.upfronthosting.co.za>
Message-ID: <1207557475.98.0.0117394691364.issue2569@psf.upfronthosting.co.za>


New submission from pk <pk at q-leap.com>:

Hello,

the urlparse() function accepts a parameter default_scheme, to be used
if the address given does not contain one, but I cannot make
use of it, because I would expect these two returning
identical values:

>>> from urlparse import urlparse
>>> urlparse("www","http")
('http', '', 'www', '', '', '')
>>> urlparse("http://www","http")
('http', 'www', '', '', '', '')

This has been reported about six years ago but apparently
the behaviour hasn't changed.  I cannot imagine that this
really is the intended behaviour.

Regards,

    pk

----------
components: Library (Lib)
messages: 65071
nosy: pk
severity: normal
status: open
title: default_scheme in urlparse.urlparse() useless
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr  7 20:29:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 18:29:02 +0000
Subject: [New-bugs-announce] [issue2570] backport 3.0-style \u/\U processing
	in raw strings when unicode_literals is imported from __future__
In-Reply-To: <1207592942.81.0.864010115323.issue2570@psf.upfronthosting.co.za>
Message-ID: <1207592942.81.0.864010115323.issue2570@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

In 3.0, r'\u1234' is a string of 6 characters (\, u, 1, 2, 3, 4).  In
2.6, after "from __future__ import unicode_literals" it is a string of
one character (code point 0x1234).  IMO the 3.0 behavior should be
imported from the future as well (using the same import).

----------
components: Interpreter Core
keywords: 26backport
messages: 65090
nosy: gvanrossum
severity: normal
status: open
title: backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr  7 20:58:22 2008
From: report at bugs.python.org (Richard King)
Date: Mon, 07 Apr 2008 18:58:22 +0000
Subject: [New-bugs-announce] [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>


New submission from Richard King <rickbking at users.sourceforge.net>:

The module global value use_rawinput is initialized to 1 but not reset
when stdin is replaced with a passed-in value.

----------
components: Extension Modules
messages: 65094
nosy: rickbking
severity: normal
status: open
title: cmd.py always uses raw_input, even when another stdin is specified
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Mon Apr  7 21:18:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Apr 2008 19:18:21 +0000
Subject: [New-bugs-announce] [issue2572] 3.0 pickle docs -- what about
	old-style classes?
In-Reply-To: <1207595901.24.0.991437670579.issue2572@psf.upfronthosting.co.za>
Message-ID: <1207595901.24.0.991437670579.issue2572@psf.upfronthosting.co.za>


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

Can 3.0 unpickle pickled old-style classes? Which pickling methods are
supported? Etc.

----------
assignee: alexandre.vassalotti
components: Documentation
messages: 65098
nosy: alexandre.vassalotti, georg.brandl
severity: normal
status: open
title: 3.0 pickle docs -- what about old-style classes?
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 21:47:25 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Mon, 07 Apr 2008 19:47:25 +0000
Subject: [New-bugs-announce] [issue2573] Can't change the framework name on
	OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>


New submission from Aaron Gallagher <habnabit at gmail.com>:

There is currently no way in the configure script to specify an 
alternate name for Python.framework. If I want to completely separate 
versions of Python (e.g. for 3.0 alphas and/or Stackless), I have to 
manually edit configure.in and configure to change the framework name. 
It would be much more convenient if --with-framework could take an 
optional parameter of the framework name to use.

----------
components: Build, Macintosh
messages: 65105
nosy: habnabit
severity: normal
status: open
title: Can't change the framework name on OS X builds
type: feature request
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Apr  7 22:12:22 2008
From: report at bugs.python.org (bms)
Date: Mon, 07 Apr 2008 20:12:22 +0000
Subject: [New-bugs-announce] [issue2574] Add RFC 3768 SSM Multicast support
	to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>


New submission from bms <bms at incunabulum.net>:

Hi,

Here is a patch to add RFC 3768 SSM Multicast support to low-level
Python socket module as of 2.5.1.

I have not tested the setsourcefilter()/getsourcefilter() socket member
functions other than compiling the patch on a Gentoo Linux 2008.0 box
w/2.6 Linux kernel.

These APIs should be fairly portable. Note that I haven't added any
other configure glue, like the rest of socket, support is very low level
and getting the arguments to struct.pack() right is the user's problem.

cheers
BMS

----------
components: Extension Modules
files: python-2.5.1-multicast-ssm.patch
keywords: patch
messages: 65115
nosy: bms
severity: normal
status: open
title: Add RFC 3768 SSM Multicast support to "socket"
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9971/python-2.5.1-multicast-ssm.patch

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

From report at bugs.python.org  Mon Apr  7 22:53:59 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Apr 2008 20:53:59 +0000
Subject: [New-bugs-announce] [issue2575] Reference manual: production for
	integer literals is missing "bininteger"
In-Reply-To: <1207601639.49.0.884754538811.issue2575@psf.upfronthosting.co.za>
Message-ID: <1207601639.49.0.884754538811.issue2575@psf.upfronthosting.co.za>


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

The production list for integer literals is missing the `bininteger`
term for binary integer literals.  Patch attached.

----------
assignee: georg.brandl
components: Documentation
files: bininteger.diff
keywords: patch, patch
messages: 65119
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Reference manual: production for integer literals is missing "bininteger"
versions: Python 3.0
Added file: http://bugs.python.org/file9972/bininteger.diff

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

From report at bugs.python.org  Mon Apr  7 22:55:11 2008
From: report at bugs.python.org (Aren Olson)
Date: Mon, 07 Apr 2008 20:55:11 +0000
Subject: [New-bugs-announce] [issue2576] httplib read() very slow due to
	lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>


New submission from Aren Olson <reacocard at gmail.com>:

This is a reposting of issue 508157, as requested by gvanrossum.

The socket file object in httplib is opened without any buffering
resulting in very slow performance of read().  The specific problem is
in the httplib.HTTPResponse constructor.  It calls sock.makefile() with
a 0 for the buffer size.  changing the buffer size to 4096 improved the
time needed to download 10MB from 15.5s to 1.78s, almost 9x faster.
Repeat downloads of the same file (meaning the server now has the file
cached in memory), yield times of 15.5s and 0.03s, a 500x improvement.
When fetching from a server on the local network, rather than from
localhost, these times become 15.5s and 0.9s in both cases, a 17x
speedup. Real-world situations will likely be a mix of these, however it
is safe to say the speed improvement will be substantial. Adding an
option to adjust the buffer size would be very welcome, though the
default value should still be zero, to avoid the issues already
mentioned in issue 508157.

These speed results were obtained with python2.5 and apache2 under
Ubuntu linux, using the code found here: http://pastebin.ca/973578

----------
components: Library (Lib)
messages: 65121
nosy: reacocard
severity: normal
status: open
title: httplib read() very slow due to lack of socket buffer
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr  8 01:13:42 2008
From: report at bugs.python.org (Richard King)
Date: Mon, 07 Apr 2008 23:13:42 +0000
Subject: [New-bugs-announce] [issue2577] cmd.py should track input file
	objects so macros with submacros can be easily written
In-Reply-To: <1207610022.93.0.150736529438.issue2577@psf.upfronthosting.co.za>
Message-ID: <1207610022.93.0.150736529438.issue2577@psf.upfronthosting.co.za>


New submission from Richard King <rickbking at users.sourceforge.net>:

Add an "input" method or property that saves the current input file
object and resets the input file object; when input results in an "EOF",
the input file object stack is popped and reading continues from there.
A modified cmd.py is attached.

----------
components: Extension Modules
files: cmd.py
messages: 65128
nosy: rickbking
severity: normal
status: open
title: cmd.py should track input file objects so macros with submacros can be easily written
type: feature request
versions: Python 2.4
Added file: http://bugs.python.org/file9974/cmd.py

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

From report at bugs.python.org  Tue Apr  8 03:01:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Apr 2008 01:01:26 +0000
Subject: [New-bugs-announce] [issue2578] Figure out what to do with
	unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

unittest has many redundant APIs (eg. failIf and assertFalse) which can
be phased out in 3.x. We may also want to change the actually methods so
they really do what they say:

if x == y:
   pass
 else:
   raise AssertionError(...)

rather than

 if x != y:
   raise AssertionError(...)

----------
components: Library (Lib)
messages: 65132
nosy: benjamin.peterson
severity: normal
status: open
title: Figure out what to do with unittest's redundant APIs
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 04:11:36 2008
From: report at bugs.python.org (Henry)
Date: Tue, 08 Apr 2008 02:11:36 +0000
Subject: [New-bugs-announce] [issue2579] Misleading 'toctree references
	unknown document' error
In-Reply-To: <1207620696.06.0.199132876602.issue2579@psf.upfronthosting.co.za>
Message-ID: <1207620696.06.0.199132876602.issue2579@psf.upfronthosting.co.za>


New submission from Henry <misc at hl.id.au>:

The 'toctree references unknown document' can be misleading when the
document name includes whitespace.

For example, I had mistakenly created an index file of the form

.. toctree::
   :maxdepth: 2

    overview

(note that overview has a leading space). In the error message is was
very difficult to see that this was a problem, as the error message was

WARNING: /home/henry/code/bdec.docs/doc/source/index.rst:8: (WARNING/2)
toctree references unknown document  overview

By putting the document name in quotes, it becomes clearer what the
problem was.

WARNING: /home/henry/code/bdec.docs/doc/source/index.rst:8: (WARNING/2)
toctree references unknown document ' overview'

A patch to include these quotes has been attached.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: unknown_reference.patch
keywords: patch
messages: 65134
nosy: georg.brandl, henryl
severity: normal
status: open
title: Misleading 'toctree references unknown document' error
Added file: http://bugs.python.org/file9976/unknown_reference.patch

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

From report at bugs.python.org  Tue Apr  8 04:26:15 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Apr 2008 02:26:15 +0000
Subject: [New-bugs-announce] [issue2580] Revise builtin class int library
	manual entry
In-Reply-To: <1207621575.04.0.143306946794.issue2580@psf.upfronthosting.co.za>
Message-ID: <1207621575.04.0.143306946794.issue2580@psf.upfronthosting.co.za>


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

Based on c.l.p discussion with Mark Dickinson, who supplied details and
corrections, we propose the following for the int() entry at
http://docs.python.org/dev/3.0/library/functions.html#int

int([number | string[, radix]])
Convert a number or string to an integer.  If no arguments are given,
return 0.  If a number is given, return number.__int__().  Conversion of
floating point numbers to integers truncates towards zero.  A string
must be a base-radix integer literal optionally preceded by '+' or '-'
(with no  space in between) and optionally surrounded by whitespace.  A
base-n literal consists of the digits 0 to n-1, with 'a' to 'z' (or 'A'
to 'Z')having values 10 to 35.  The default radix is 10. The allowed
values are 0 and 2-36.  Base-2, -8, and -16 literals can  be optionally
prefixed with 0b/0B, 0o/0O, or 0x/0X, as with integer literals in code.
 Radix 0 means to interpret exactly as a code literal, so that the
actual radix is 2, 8, 10, or 16, and so that int('010',0) is not legal,
while int('010') is.

The revised signature makes it clear from the start that *radix* can
only follow *string*, so no sentence to that effect is needed in the
text.  The other changes are to discuss the signature in order and to
add details.  We believe the above accurately reflects the
intended/actual behavior once the no-space-after-sign patch is applied.
 (I don't know if that made it into .0a4).

Some of this might apply to the 2.6 docs, except that the no-space patch
will apparently not be backported.  I believe the acceptable strings are
a bit different also, at least for octals, but I am not sure.

----------
assignee: georg.brandl
components: Documentation
messages: 65137
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Revise builtin class int library manual entry
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 04:43:07 2008
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 08 Apr 2008 02:43:07 +0000
Subject: [New-bugs-announce] [issue2581] Vista UAC/elevation support for
	bdist_wininst
In-Reply-To: <1207622587.48.0.467176827447.issue2581@psf.upfronthosting.co.za>
Message-ID: <1207622587.48.0.467176827447.issue2581@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The attached patch adds basic UAC support to bdist_wininst created
installers.  A new option '--user-access-control' has been added to
bdist_wininst, which is written to the INI file read by the installer. 
The installer reads this value: if it is 'force', elevation is always
requested, if it is 'auto', elevation is requested when Python is
installed in HKLM.  'none' (the default) means nothing UAC related
happens at all.

The elevation happens by having the installer re-execute itself using
ShellExecute.

I've also ensured the code builds for all versions of VS we support.  As
a result, it was necessary to change the old bdist_wininst project files
to point to the later zlib version Python itself uses.  All these
changes are in the patch.

----------
assignee: mhammond
components: Distutils
files: bdist_wininst_uac.patch
keywords: patch, patch
messages: 65139
nosy: mhammond, theller
severity: normal
status: open
title: Vista UAC/elevation support for bdist_wininst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9978/bdist_wininst_uac.patch

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

From report at bugs.python.org  Tue Apr  8 14:39:02 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Tue, 08 Apr 2008 12:39:02 +0000
Subject: [New-bugs-announce] [issue2582] Unpickling of range objects fail in
	Py3k
In-Reply-To: <1207658342.58.0.573226897239.issue2582@psf.upfronthosting.co.za>
Message-ID: <1207658342.58.0.573226897239.issue2582@psf.upfronthosting.co.za>


New submission from Anand B Pillai <abpillai at gmail.com>:

Unpickling of range objects is throwing an exception in Python 3.0

----------
components: Interpreter Core, Library (Lib)
files: bugdemo.py
messages: 65157
nosy: pythonhacker
severity: normal
status: open
title: Unpickling of range objects fail in Py3k
versions: Python 3.0
Added file: http://bugs.python.org/file9981/bugdemo.py

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

From report at bugs.python.org  Tue Apr  8 15:56:58 2008
From: report at bugs.python.org (monk.e.boy)
Date: Tue, 08 Apr 2008 13:56:58 +0000
Subject: [New-bugs-announce] [issue2583] urlparse normalize URL path
In-Reply-To: <1207663018.75.0.231530474022.issue2583@psf.upfronthosting.co.za>
Message-ID: <1207663018.75.0.231530474022.issue2583@psf.upfronthosting.co.za>


New submission from monk.e.boy <johng at neutralize.com>:

Hi,
  This is my first problem with anything Python :-) and my first issue.

  Doing in the following:

  urlparse.urljoin( 'http://site.com/', '../../../../path/' )
  'http://site.com/../../../../path/'

  urlparse.urljoin( 'http://site.com/', '/path/../path/.././path/./' )
  'http://site.com/path/../path/.././path/./'

These URLs are normalized to http://site.com/path/ in both Firefox and
Google (the google spider would follow these OK)

  I think the documentation could be improved to point at the
posixpath.py normpath function and how it solves the above. I blogged a
how to:

http://teethgrinder.co.uk/blog/Normalize-URL-path-python/

I hope my bug report is OK. Thanks for all the code :-)

johng at neutralize.com

----------
components: Library (Lib)
messages: 65162
nosy: monk.e.boy
severity: normal
status: open
title: urlparse normalize URL path
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 17:19:13 2008
From: report at bugs.python.org (Tim Wilcoxson)
Date: Tue, 08 Apr 2008 15:19:13 +0000
Subject: [New-bugs-announce] [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>


New submission from Tim Wilcoxson <qodosh at gmail.com>:

According to the documentation there is not suppose to be numeric
overflow in python 2.5. However....

If you run a for loop with the range(1, 300000000)a couple of times (for
me 2 or 3 times worked) in the IDLE (1.2.2)GUI . It will cause what
appears to be a memory leak, at least under vista home edition. Haven't
tested out other platforms yet. Vista's logon process will fail to start
security dialog as well if you try to ctrl-alt-del. Which effectively
cripples the system. I haven't tested to see if the condition will get
better over long period of time. I've waited a max of 10 minutes for the
system to respond. 

I tested running the script multiple times under cmd in windows, and it
spits out a memory error after a minute of not responding and then the
cmd prompts will close and the system will begin responding. So it
appears to be isolated to IDLE.

----------
components: IDLE
files: for_loop.py
messages: 65167
nosy: Qodosh
severity: normal
status: open
title: numeric overflow in IDLE
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9982/for_loop.py

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

From report at bugs.python.org  Tue Apr  8 17:19:25 2008
From: report at bugs.python.org (djc)
Date: Tue, 08 Apr 2008 15:19:25 +0000
Subject: [New-bugs-announce] [issue2585] urllib2.HTTPError broken due to
	urllib.addinfourl changes
In-Reply-To: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>
Message-ID: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>


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

djc at enrai tests $ python2.6
Python 2.6a2+ (trunk, Apr  4 2008, 20:21:45)
[GCC 4.1.2 20070214 (  (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2
p1.0.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> try:
...     urllib2.urlopen('http://example.com/weird')
... except urllib2.HTTPError, inst:
...     print inst.code
...
None
>>>

urllib.addinfourl.__init__() was changed in r60133 to set self.code.
Unfortunately, this overrides HTTPError.code, which is probably not good.

----------
components: Library (Lib)
messages: 65168
nosy: birkenfeld, djc
severity: normal
status: open
title: urllib2.HTTPError broken due to urllib.addinfourl changes
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr  8 17:41:40 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:41:40 +0000
Subject: [New-bugs-announce] [issue2586] Integer signedness bugs in zlib
	modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The zlib module in multiple places fails to adequately check the sanity
of its arguments resulting in memory corruption, please see two attached
PoCs.

----------
components: Extension Modules
files: python-2.5.2-zlib-unflush-misallocation.py
messages: 65171
nosy: jnferguson
severity: normal
status: open
title: Integer signedness bugs in zlib modules
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file9983/python-2.5.2-zlib-unflush-misallocation.py

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

From report at bugs.python.org  Tue Apr  8 17:49:07 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:49:07 +0000
Subject: [New-bugs-announce] [issue2587] PyString_FromStringAndSize() to be
	considered unsane
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The PyString_FromStringAndSize() function takes a pointer and signed
integer as input parameters however it fails to adequately check the
sanity of the integer argument. Because of the failure to check for
negative values and because it sums the integer with the size of the
PyStringObject structure it becomes possible for the allocator to take
either of the code paths in PyObject_MALLOC()-- both of which will
incorrectly allocate memory.

This may not seem like a big deal, but I'm posting this instead of
filing a bug for every place this screws you guys over.

if (0 > len || len > PYSSIZE_T_MAX/sizeof(PyStringObject)) 
        return NULL;

----------
components: Interpreter Core
messages: 65172
nosy: jnferguson
severity: normal
status: open
title: PyString_FromStringAndSize() to be considered unsane
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 17:55:10 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:55:10 +0000
Subject: [New-bugs-announce] [issue2588] PyOS_vsnprintf() underflow leads to
	memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The PyOS_vsnprintf() contains the caveat that the length parameter
cannot be zero, however this is only enforced via assert() which is
compiled out. As a result if the length parameter is zero then the
function will underflow and write a null byte to invalid memory.

 53 int
 54 PyOS_vsnprintf(char *str, size_t size, const char  *format, va_list va)
 55 {
 56         int len;  /* # bytes written, excluding \0 */
 57 #ifndef HAVE_SNPRINTF
 58         char *buffer;
 59 #endif
 60         assert(str != NULL);
 61         assert(size > 0);
 62         assert(format != NULL);
 [...]
 65         len = vsnprintf(str, size, format, va);
 [...]
 91         str[size-1] = '\0';
 92         return len;
 93 }

----------
components: Distutils
messages: 65174
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() underflow leads to memory corruption
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 17:59:49 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:59:49 +0000
Subject: [New-bugs-announce] [issue2589] PyOS_vsnprintf() potential integer
	overflow leads to memory corruption on esoteric architectures
In-Reply-To: <1207670389.49.0.356116216637.issue2589@psf.upfronthosting.co.za>
Message-ID: <1207670389.49.0.356116216637.issue2589@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

On architectures that do not have a vsnprintf() in their standard
library Python attempts to emulate it. When doing so, the implementation
ambitiously allocates more memory than requested without verifying the
sanity of the summed value. As a result it becomes possible (although
unlikely) for an integer overflow to occur misallocating memory and
causing a buffer overflow.

 53 int
 54 PyOS_vsnprintf(char *str, size_t size, const char  *format, va_list va)
 55 {
 56         int len;  /* # bytes written, excluding \0 */
[...]
 60         assert(str != NULL);
 61         assert(size > 0);
 62         assert(format != NULL);
 63 
[...]
 67         /* Emulate it. */
 68         buffer = PyMem_MALLOC(size + 512);
 69         if (buffer == NULL) {
 70                 len = -666;
 71                 goto Done;
 72         }
 73 
 74         len = vsprintf(buffer, format, va);
 75         if (len < 0)
 76                 /* ignore the error */;
 77 
 78         else if ((size_t)len >= size + 512)
 79                 Py_FatalError("Buffer overflow in
PyOS_snprintf/PyOS_vsnprintf");
 80 
 81         else {
 82                 const size_t to_copy = (size_t)len < size ?
 83                                         (size_t)len : size - 1;
 84                 assert(to_copy < size);
 85                 memcpy(str, buffer, to_copy);
 86                 str[to_copy] = '\0';
 87         }
 88         PyMem_FREE(buffer);
 89 Done:
[...]
 91         str[size-1] = '\0';
 92         return len;
 93 }

----------
components: Interpreter Core
messages: 65175
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() potential integer overflow leads to memory corruption on esoteric architectures
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:09:34 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:09:34 +0000
Subject: [New-bugs-announce] [issue2590] S_unpack_from() Read Access
	Violation
In-Reply-To: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>
Message-ID: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The S_unpack_from() function in Modules/_struct.c does not adequately
validate its arguments, potentially causing an out-of-bounds read
access. It should be noted that the check at line 1561 is inadequate for
obscene values of offset. Finally, because they're not really important
and I really don't want to type them all up-- you guys might want to go
through your code-- especially the modules and look for constructs where
an empty string will cause memory to be uninitialized-- look at the
audioop module for examples of what I mean-- the only thing that
actually saved you guys from overflows there was that the loops you
write with use the same variable. 

1533 static PyObject *
1534 s_unpack_from(PyObject *self, PyObject *args, PyObject *kwds)
1535 {
1536         static char *kwlist[] = {"buffer", "offset", 0};
1537 #if (PY_VERSION_HEX < 0x02050000)
1538         static char *fmt = "z#|i:unpack_from";
1539 #else
1540         static char *fmt = "z#|n:unpack_from";
1541 #endif
1542         Py_ssize_t buffer_len = 0, offset = 0;
[...]
1547 
1548         if (!PyArg_ParseTupleAndKeywords(args, kwds, fmt, kwlist,
1549                                          &buffer, &buffer_len,
&offset))
1550                 return NULL;
[...]
1558         if (offset < 0)
1559                 offset += buffer_len;
1560 
1561         if (offset < 0 || (buffer_len - offset) < soself->s_size) {
[...]
1566         }
1567         return s_unpack_internal(soself, buffer + offset);
1568 }

----------
components: Extension Modules
messages: 65178
nosy: jnferguson
severity: normal
status: open
title: S_unpack_from() Read Access Violation
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:13:33 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:13:33 +0000
Subject: [New-bugs-announce] [issue2591] ErrorHandler buffer overflow in
	?unused? SGI extension module almodule.c
In-Reply-To: <1207671213.37.0.514219749989.issue2591@psf.upfronthosting.co.za>
Message-ID: <1207671213.37.0.514219749989.issue2591@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

I don't think any of these SGI modules even get used, but they're really
buggy-- you guys might want to consider just dropping them all together.

When printing errors larger than 128 bytes a stack based overflow occurs.

  44 static void
  45 ErrorHandler(long code, const char *fmt, ...)
  46 {
  47         va_list args;
  48         char buf[128];
  49 
  50         va_start(args, fmt);
  51         vsprintf(buf, fmt, args);
  52         va_end(args);
  53         PyErr_SetString(ErrorObject, buf);
  54 }

----------
components: Extension Modules
messages: 65180
nosy: jnferguson
severity: normal
status: open
title: ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:17:43 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 16:17:43 +0000
Subject: [New-bugs-announce] [issue2592] weakref.proxy fails to delegate
	tp_index slot
In-Reply-To: <1207671463.8.0.448450429291.issue2592@psf.upfronthosting.co.za>
Message-ID: <1207671463.8.0.448450429291.issue2592@psf.upfronthosting.co.za>


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

>From the discussion of issue 643841:

>>> class Demo:
...   def __index__(self):
...     return 1
...
>>> a = Demo()
>>> b = weakref.proxy(a)
>>> operator.index(a)
1
>>> operator.index(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'weakproxy' object cannot be interpreted as an index

The weakref proxy types need to be updated to delegate 2.5's new
tp_index slot.

----------
components: Library (Lib)
messages: 65182
nosy: ncoghlan
severity: normal
status: open
title: weakref.proxy fails to delegate tp_index slot
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Apr  8 18:18:29 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:18:29 +0000
Subject: [New-bugs-announce] [issue2593] alp_ReadFrames() integer overflow
	leads to buffer overflow
In-Reply-To: <1207671509.18.0.228221414786.issue2593@psf.upfronthosting.co.za>
Message-ID: <1207671509.18.0.228221414786.issue2593@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

Please see bug 2591 for a suggestion on what to do with these SGI modules.
(sorry I don't have any pocs/repros I dont have an sgi box handy atm)

Integer overflow/invalid allocation at 768, write to memory at 773

 716 static PyObject *
 717 alp_ReadFrames(alpobject *self, PyObject *args)
 718 {
 719         int framecount;
 720         PyObject *v;
 721         int size;
 722         int ch;
 723         ALconfig c;
 724 
 725         if (!PyArg_ParseTuple(args, "i:ReadFrames", &framecount))
 726                 return NULL;
 727         if (framecount < 0) {
 728                 PyErr_SetString(ErrorObject, "negative framecount");
 729                 return NULL;
 730         }
[...] 732         switch (alGetSampFmt(c)) {
 733         case AL_SAMPFMT_TWOSCOMP:
 734                 switch (alGetWidth(c)) {
 735                 case AL_SAMPLE_8:
 736                         size = 1;
 737                         break;
 738                 case AL_SAMPLE_16:
 739                         size = 2;
 740                         break;
 741                 case AL_SAMPLE_24:
 742                         size = 4;
 743                         break;
 744                 default:
 745                         PyErr_SetString(ErrorObject, "can't
determine width");
 746                         alFreeConfig(c);
 747                         return NULL;
 748                 }
 749                 break;
 750         case AL_SAMPFMT_FLOAT:
 751                 size = 4;
 752                 break;
 753         case AL_SAMPFMT_DOUBLE:
 754                 size = 8;
 755                 break;
 756         default:
 757                 PyErr_SetString(ErrorObject, "can't determine format");
 758                 alFreeConfig(c);
 759                 return NULL;
 760         }
 761         ch = alGetChannels(c);
 762         alFreeConfig(c);
 763         if (ch < 0) {
 764                 PyErr_SetString(ErrorObject, "can't determine # of
channels");
 765                 return NULL;
 766         }
 767         size *= ch;
 768         v = PyString_FromStringAndSize((char *) NULL, size *
framecount);
 769         if (v == NULL)
 770                 return NULL;
 771 
[...] 
 773         alReadFrames(self->port, (void *) PyString_AS_STRING(v),
framecount);

----------
components: Extension Modules
messages: 65183
nosy: jnferguson
severity: normal
status: open
title: alp_ReadFrames() integer overflow leads to buffer overflow
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:31:43 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:31:43 +0000
Subject: [New-bugs-announce] [issue2594] alp_readsamps() overflow leads to
	memory corruption in ?unused? SGI extension module almodule.c
In-Reply-To: <1207672303.58.0.550731547679.issue2594@psf.upfronthosting.co.za>
Message-ID: <1207672303.58.0.550731547679.issue2594@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

You guys should probably just remove the SGI modules, the code looks
like it hasn't been touched in some time and hasn't gone through the
same security checks as other pieces of code. Sorry I have no
repro's/pocs, I don't have an irix box either though ;]

integer overflow/misallocation occurs at 1071, write to bad memory at 1076

1042 alp_readsamps(alpobject *self, PyObject *args)
1043 {
1044         long count;
1045         PyObject *v;
1046         ALconfig c;
1047         int width;
1048         int ret;
1049 
1050         if (!PyArg_ParseTuple(args, "l:readsamps", &count))
1051                 return NULL;
1052 
1053         if (count <= 0) {
1054                 PyErr_SetString(ErrorObject, "al.readsamps : arg <=
0");
1055                 return NULL;
1056         }
1057 
1058         c = ALgetconfig(self->port);
1059 #ifdef AL_405
1060         width = ALgetsampfmt(c);
1061         if (width == AL_SAMPFMT_FLOAT)
1062                 width = sizeof(float);
1063         else if (width == AL_SAMPFMT_DOUBLE)
1064                 width = sizeof(double);
1065         else
1066                 width = ALgetwidth(c);
1067 #else
1068         width = ALgetwidth(c);
1069 #endif /* AL_405 */
1070         ALfreeconfig(c);
1071         v = PyString_FromStringAndSize((char *)NULL, width * count);
1072         if (v == NULL)
1073                 return NULL;
1074 
1075         Py_BEGIN_ALLOW_THREADS
1076         ret = ALreadsamps(self->port, (void *)
PyString_AsString(v), count);
1077         Py_END_ALLOW_THREADS
1078         if (ret == -1) {
1079                 Py_DECREF(v);
1080                 return NULL;
1081         }
1082 
1083         return (v);
1084 }

----------
components: Extension Modules
messages: 65188
nosy: jnferguson
severity: normal
status: open
title: alp_readsamps() overflow leads to memory corruption in ?unused? SGI extension module almodule.c
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:56:39 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:56:39 +0000
Subject: [New-bugs-announce] [issue2595] Multiple integer overflows in
	imgfile extension module lead to buffer overflow
In-Reply-To: <1207673799.86.0.811482353328.issue2595@psf.upfronthosting.co.za>
Message-ID: <1207673799.86.0.811482353328.issue2595@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The imgfile module contains multiple integer overflows, this module is
only used on SGI boxes and is likely mostly unused and thus is fairly
low priority imho-- no repros, no poc, no sgi box :/

I'm only going to post one to give you the idea, there's no need for me
to (further) spam the bug database by filing a bug for each one of
these, they're all pretty much the same.

Here the variables xsize, ysize and zsize are all externally derived.
While xsize and zsize are sanity checked, ysize is not. This potentially
results in an integer overflow/misallocation at line 133 and writes to
invalid memory in the calls to getrow()

 85 static PyObject *
 86 imgfile_read(PyObject *self, PyObject *args)
 87 {
 88         char *fname;
 89         PyObject *rv;
 90         int xsize, ysize, zsize;
 91         char *cdatap;
 92         long *idatap;
 93         static short rs[8192], gs[8192], bs[8192];
 94         int x, y;
 95         IMAGE *image;
 96         int yfirst, ylast, ystep;
 97
 98         if ( !PyArg_ParseTuple(args, "s:read", &fname) )
 99                 return NULL;
100    
101         if ( (image = imgfile_open(fname)) == NULL )
102                 return NULL;
[...]
116         xsize = image->xsize;
117         ysize = image->ysize;
118         zsize = image->zsize;
119         if ( zsize != 1 && zsize != 3) {
120                 iclose(image);
121                 PyErr_SetString(ImgfileError,
122                                 "Can only handle 1 or 3 byte pixels");
123                 return NULL;
124         }
125         if ( xsize > 8192 ) {
126                 iclose(image);
127                 PyErr_SetString(ImgfileError,
128                                 "Can't handle image with > 8192
columns");
129                 return NULL;
130         }
131 
132         if ( zsize == 3 ) zsize = 4;
133         rv = PyString_FromStringAndSize((char *)NULL,
xsize*ysize*zsize);
134         if ( rv == NULL ) {
138         cdatap = PyString_AsString(rv);
139         idatap = (long *)cdatap;
[...]
150         for ( y=yfirst; y != ylast && !error_called; y += ystep ) {
151                 if ( zsize == 1 ) {
152                         getrow(image, rs, y, 0);
153                         for(x=0; x<xsize; x++ )
154                                 *cdatap++ = rs[x];
155                 } else {
156                         getrow(image, rs, y, 0);
157                         getrow(image, gs, y, 1);
158                         getrow(image, bs, y, 2);
159                         for(x=0; x<xsize; x++ )
160                                 *idatap++ = (rs[x] & 0xff)  |
161                                         ((gs[x] & 0xff)<<8) |
162                                         ((bs[x] & 0xff)<<16);
163                 }
164         }

----------
components: Extension Modules
messages: 65194
nosy: jnferguson
severity: normal
status: open
title: Multiple integer overflows in imgfile extension module lead to buffer overflow
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 21:12:48 2008
From: report at bugs.python.org (Collin Winter)
Date: Tue, 08 Apr 2008 19:12:48 +0000
Subject: [New-bugs-announce] [issue2596] 2to3's fix_range needs fix_dict's
	context information
In-Reply-To: <1207681968.61.0.683237075469.issue2596@psf.upfronthosting.co.za>
Message-ID: <1207681968.61.0.683237075469.issue2596@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

2to3 should be able to translate the code snippet below successfully.
First guess: generalizing fix_dict's notion of special contexts would do
the trick.

import random

numbers = range(1, 50)
chosen = []

while len(chosen) < 6:
    number = random.choice(numbers)
    numbers.remove(number)
    chosen.append(number)

chosen.sort()
print("This week's numbers are", chosen)
print("The bonus ball is", random.choice(numbers))

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 65204
nosy: collinwinter
priority: normal
severity: normal
status: open
title: 2to3's fix_range needs fix_dict's context information
type: behavior

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

From report at bugs.python.org  Tue Apr  8 21:24:16 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:24:16 +0000
Subject: [New-bugs-announce] [issue2597] "python2.6 -3" should report
	list.sort(cmp) as DeprecationWarning
In-Reply-To: <1207682656.33.0.410001743847.issue2597@psf.upfronthosting.co.za>
Message-ID: <1207682656.33.0.410001743847.issue2597@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

this is not reported in 2.6a1.

----------
components: Interpreter Core
messages: 65207
nosy: dangyogi
severity: normal
status: open
title: "python2.6 -3" should report list.sort(cmp) as DeprecationWarning
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr  8 21:38:44 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:38:44 +0000
Subject: [New-bugs-announce] [issue2598] "{ +(}".format(**{' +(': 44})
	should produce ValueError: invalid identifier, ' +(' in format
In-Reply-To: <1207683524.11.0.610086195192.issue2598@psf.upfronthosting.co.za>
Message-ID: <1207683524.11.0.610086195192.issue2598@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

Format strings are documented to only allow identifiers or integers as
the field_name, but allow almost anything.

Python 3.0a3

----------
components: Interpreter Core
messages: 65209
nosy: dangyogi
severity: normal
status: open
title: "{ +(}".format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 21:51:05 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:51:05 +0000
Subject: [New-bugs-announce] [issue2599] allow field_name in format strings
	to default to next positional argument (e.g., "{}")
In-Reply-To: <1207684265.4.0.956293084225.issue2599@psf.upfronthosting.co.za>
Message-ID: <1207684265.4.0.956293084225.issue2599@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

Being forced to number the arguments when using positional arguments in
a format string is difficult to maintain.  Adding an argument to the
format string either requires renumbering all subsequent arguments, or
using an out of sequence number such that the order of the format()
arguments no longer matches the order of the "{...}" arguments.  Making
the integer optional would solve this.  Thus, "{}" would be like the old
"%s" where it was far easier to add %s arguments in the middle of the
format string.

Python 3.0a3

----------
components: Interpreter Core
messages: 65210
nosy: dangyogi
severity: normal
status: open
title: allow field_name in format strings to default to next positional argument (e.g., "{}")
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 23:05:00 2008
From: report at bugs.python.org (Pau Aliagas)
Date: Tue, 08 Apr 2008 21:05:00 +0000
Subject: [New-bugs-announce] [issue2600] BindingHTTPConnectionWithTimeout
	and BindingHTTPHandlerWithTimeout
In-Reply-To: <1207688700.18.0.242817334294.issue2600@psf.upfronthosting.co.za>
Message-ID: <1207688700.18.0.242817334294.issue2600@psf.upfronthosting.co.za>


New submission from Pau Aliagas <linuxnow at newtral.org>:

I wanted to use urllib2 with something as usual as binding to a given
network interface and it was incredibly complex. I also did not like the
usual propodes solution to timeout the connections: set the global
socket timeour. I needed a different timeout for each connection.

So I took my time, I learnt about httplib and urllib2 and made a patch
to enhance both libraries.

BindingHTTPConnectionWithTimeout extends HTTPConection with supports
timeouts and a binding address.

BindingHTTPHandlerWithTimeout extends HTTPHandler and basically uses the
new http class provided.

The patch is really simple and would make a great addition to the
standard library. I've tried to follow the style amd copied similar
methods, giving the due credits.

I hope you find it useful and consider it for inclusion.

----------
components: Library (Lib)
files: urllib2_util.py
messages: 65215
nosy: pau
severity: normal
status: open
title: BindingHTTPConnectionWithTimeout and BindingHTTPHandlerWithTimeout
type: feature request
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9988/urllib2_util.py

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

From report at bugs.python.org  Tue Apr  8 23:15:30 2008
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 08 Apr 2008 21:15:30 +0000
Subject: [New-bugs-announce] [issue2601] [regression] reading from a urllib2
	file descriptor happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>


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

r61009 on the 2.5 branch

  - Bug #1389051, 1092502: fix excessively large memory allocations when
    calling .read() on a socket object wrapped with makefile(). 

causes a regression compared to 2.4.5 and 2.5.2:

When reading from urllib2 file descriptor, python will read the data a
byte at a time regardless of how much you ask for. python versions up to
2.5.2 will read the data in 8K chunks.

This has enough of a performance impact that it increases download time
for a large file over a gigabit LAN from 10 seconds to 34 minutes. (!)

Trivial/obvious example code:

  f =
urllib2.urlopen("http://launchpadlibrarian.net/13214672/nexuiz-data_2.4.orig.tar.gz")
  while 1:
    chunk = f.read()

... and then strace it to see the recv()'s chugging along, one byte at a
time.

----------
assignee: akuchling
components: Library (Lib)
messages: 65219
nosy: akuchling, doko
priority: high
severity: normal
status: open
title: [regression] reading from a urllib2 file descriptor happens byte-at-a-time
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr  9 10:34:53 2008
From: report at bugs.python.org (=?utf-8?q?Taavi_Rep=C3=A4n?=)
Date: Wed, 09 Apr 2008 08:34:53 +0000
Subject: [New-bugs-announce] [issue2602] importing gtk hangs (freebsd 7.0)
In-Reply-To: <1207730093.3.0.550456039036.issue2602@psf.upfronthosting.co.za>
Message-ID: <1207730093.3.0.550456039036.issue2602@psf.upfronthosting.co.za>


New submission from Taavi Rep?n <trepan at gmail.com>:

Python 2.5.3a0 (release25-maint:62241, Apr  9 2008, 11:26:27) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygtk
>>> import gtk
[hangs here]

----------
files: backtrace
messages: 65233
nosy: trepan
severity: normal
status: open
title: importing gtk hangs (freebsd 7.0)
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9991/backtrace

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

From report at bugs.python.org  Wed Apr  9 23:28:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Apr 2008 21:28:08 +0000
Subject: [New-bugs-announce] [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch makes this work:
>>> range(4) == range(4)
True

This is in similar fashion to dict.keys
>>> {1:2}.keys() == {1:2}.keys()
True

Tests included.

----------
components: Interpreter Core
files: range_eq.patch
keywords: patch
messages: 65266
nosy: benjamin.peterson
severity: normal
status: open
title: Make range __eq__ work
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file9993/range_eq.patch

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

From report at bugs.python.org  Thu Apr 10 05:40:47 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 10 Apr 2008 03:40:47 +0000
Subject: [New-bugs-announce] [issue2604] doctest.DocTestCase fails when run
	repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>


New submission from Piet Delport <pjdelport at gmail.com>:

DocTestCase.tearDown destructively clears its DocTest instance's globs,
preventing the test from being run repeatedly (such as with trial
--until-failure).

There's a fix for this in zope.testing's version of doctest, which
resets the globs instead:

http://svn.zope.org/?view=rev&rev=39023

----------
components: Library (Lib)
messages: 65285
nosy: pjd
severity: normal
status: open
title: doctest.DocTestCase fails when run repeatedly
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Apr 10 12:15:09 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 10 Apr 2008 10:15:09 +0000
Subject: [New-bugs-announce] [issue2605] Descriptor instance attributes not
	interpreted consistently
In-Reply-To: <1207822509.14.0.860100540347.issue2605@psf.upfronthosting.co.za>
Message-ID: <1207822509.14.0.860100540347.issue2605@psf.upfronthosting.co.za>


New submission from Piet Delport <pjdelport at gmail.com>:

Short version:  __get__/__set__/__delete__ attributes on descriptor objects
(as opposed to their types) are treated inconsistently as part of the
descriptor
protocol:  the documentation and support code includes them;  the core
implementation doesn't.

Example:

    class D(object):
        __get__ = lambda self, i, o: 'D'

    class C(object):
        d = D()
        d.__get__ = lambda i, o: 'd'
        d.__set__ = lambda i, v: 1/0

    c = C()

According to pydoc and inspect, and the description in the reference manual
(section 3.4.2.3), d's __get__ and __set__ override D's:

    >>> inspect.isdatadescriptor(C.__dict__['d'])
    True
    >>> help(C)
    class C(__builtin__.object)
    |  Data descriptors defined here:
    ...
    |  d

    >>> type(c).__dict__['d'].__get__(c, type(c))
    'd'
    >>> type(c).__dict__['d'].__set__(c, 5)
    ZeroDivisionError: integer division or modulo by zero

According to CPython, they have no effect:

    >>> c.d
    'D'
    >>> c.d = 5; c.d
    5

PEP 252 notes: "For speed, the get and set methods are type slots", which
points to the CPython behavior being an intentional concession for
performance.

Should CPython respect descriptor object attributes, if reasonable
performance
can be maintained?  Otherwise, should the documentation and support code be
changed to ignore them?

----------
components: Interpreter Core, Library (Lib)
messages: 65289
nosy: pjd
severity: normal
status: open
title: Descriptor instance attributes not interpreted consistently
type: behavior
versions: Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Apr 10 14:19:18 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 10 Apr 2008 12:19:18 +0000
Subject: [New-bugs-announce] [issue2606] trace module crashes due to using
	wrong sort idiom
In-Reply-To: <1207829958.28.0.410413314443.issue2606@psf.upfronthosting.co.za>
Message-ID: <1207829958.28.0.410413314443.issue2606@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

In Py30a4's trace.py there is this:

    calls = self.calledfuncs.keys()
    calls.sort()

which causes:
    AttributeError: 'dict_keys' object has no attribute 'sort'

There are two other occurrences of this idiom in trace.py (just search
for ".sort"). I guess they should be easy to fix.

----------
components: Library (Lib)
messages: 65290
nosy: mark
severity: normal
status: open
title: trace module crashes due to using wrong sort idiom
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Apr 10 18:21:41 2008
From: report at bugs.python.org (Andreas Eisele)
Date: Thu, 10 Apr 2008 16:21:41 +0000
Subject: [New-bugs-announce] [issue2607] why is (default)dict so slow on
	tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>


New submission from Andreas Eisele <eisele at dfki.de>:

I need to count pairs of strings, and I use 
a defaultdict in a construct like

count[a,b] += 1

I am able to count 50K items per second on a very fast machine,
which is way too slow for my application.

If I count complete strings like

count[ab] += 1

it can count 500K items/second, which is more reasonable.

I don't see why there is a performance penalty of a factor
of 10 for such a simple construct.

Do I have to switch to Perl or C to get this done???

Thanks a lot for any insight on this.

Best regards,
Andreas

PS.: The problem seems to exist for ordinary
dicts as well, it is not related to the fact that
I use a defaultdict

PPS: I also tried nested defaultdicts
count[a][b] += 1
and get the same slow speed (and 50% more memory consumption)

----------
messages: 65293
nosy: eisele
severity: normal
status: open
title: why is (default)dict so slow on tuples???
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 10 18:59:52 2008
From: report at bugs.python.org (Mikhail Gusarov)
Date: Thu, 10 Apr 2008 16:59:52 +0000
Subject: [New-bugs-announce] [issue2608] manpages for sphinx-build &
	sphinx-quickstart
In-Reply-To: <1207846792.27.0.634883270902.issue2608@psf.upfronthosting.co.za>
Message-ID: <1207846792.27.0.634883270902.issue2608@psf.upfronthosting.co.za>


New submission from Mikhail Gusarov <dottedmag at dottedmag.net>:

I just created manpages for sphinx-build and sphinx-quickstart as a 
part of Sphinx debianization.

Feel free to use/change/improve - I'm releasing them under BSD license, 
matching rest of Sphinx.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-build.1
messages: 65300
nosy: dottedmag, georg.brandl
severity: normal
status: open
title: manpages for sphinx-build & sphinx-quickstart
type: feature request
Added file: http://bugs.python.org/file9997/sphinx-build.1

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

From report at bugs.python.org  Thu Apr 10 19:01:10 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 17:01:10 +0000
Subject: [New-bugs-announce] [issue2609] Tests fail if ./@test is not
	writeable
In-Reply-To: <1207846870.93.0.178479630911.issue2609@psf.upfronthosting.co.za>
Message-ID: <1207846870.93.0.178479630911.issue2609@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

If @test file is not writable in the current directory,
test_support.TESTFN is changed to '/tmp/@test', but several tests fail
if TESTFN is an absolute path:

$ mkdir @test
$ make test
..
4 tests failed:
    test_import test_site test_urllib test_zipfile
..

For example,

$ ./python -E -tt ./Lib/test/regrtest.py -l test_urllib
test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "Lib/test/test_urllib.py", line 84, in test_geturl
    self.assertEqual(self.returned_obj.geturl(), self.pathname)
AssertionError: 'file:///tmp/@test' != '/tmp/@test'

Note that I discovered this problem after (probably killed) test_os left
 @test/ directory behind. It took me a while to realize what happened.

I think the simplest fix is to os.chdir to '/tmp' if @test is not
writable instead of changing TESTFN. Other solutions may include
deleting or renaming @test with a warning when it exists, using
tempnam() instead of @test and bailing out if cwd is not writeable etc.

----------
components: Tests
messages: 65301
nosy: belopolsky
severity: normal
status: open
title: Tests fail if ./@test is not writeable
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 10 22:18:29 2008
From: report at bugs.python.org (Brad Miller)
Date: Thu, 10 Apr 2008 20:18:29 +0000
Subject: [New-bugs-announce] [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>


New submission from Brad Miller <bonelake at gmail.com>:

I use Python in my CS1 and CS2 curriculum and I have a question.
As I've been using the Python 3.0 alphas one of the things that I am
bothered by is that I cannot see the sequence produced by range
without introducing students to the list() function.

I typically introduce range on day 1 of class and show students what
it produces without making a big deal out of the fact that it creates
a list.  They all accept this and things work out nicely when I
introduce lists for real in a week or two.

My question is why couldn't the __str__ method for the range object be
more friendly and show a representation of the sequence?  I understand
why __repr__ should return range(0,10) for an object created using
range(10) but couldn't print(range(10)) produce [0, 1, 2, ... 9]
The ... could even be used if the sequence were excessively long.

I have attached a patch, which follows the suggestion from Guido on how 
to format the string so it is not confused with a list.

This is my first attempt at patching any part of the C code for Python.  
Please let me know what should be changed and If I've missed something.

In particular I wonder whether I should be nesting any calls to PyNumber 
functions or whether temporary variables should be used to avoid leaking 
memory?

In addition I get the following warning on the line where I install the 
range_str function in the PyRange_Type array.

Objects/rangeobject.c:357: warning: initialization from incompatible 
pointer type


Brad

----------
components: Interpreter Core
files: range_str.patch
keywords: patch
messages: 65316
nosy: bmiller
severity: normal
status: open
title: string representation of range
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10000/range_str.patch

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

From report at bugs.python.org  Fri Apr 11 00:55:26 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 10 Apr 2008 22:55:26 +0000
Subject: [New-bugs-announce] [issue2611] Extend buildbot web interface to
	allow for forced tests to be run on a slave in verbose mode.
In-Reply-To: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>
Message-ID: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>


New submission from Trent Nelson <tnelson at onresolve.com>:

It'd be nice if there was a facility to force a particular test to be 
re-run in verbose mode with the most recent build via the buildbot web 
interface.  It would allow us to get a bit more information about 
what's going on when the buildbots report stuff like this:

test_property
test_cprofile
test_signal

command timed out: 1800 seconds without output, killing pid 214235
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1

Neal or Martin, if neither of you have the desire/bandwidth to look 
into this, I'm more than happy to take it on.  Suspect it'd involve a 
buildbot change on dinsdale right?

----------
components: Build
messages: 65328
nosy: Trent.Nelson, loewis, nnorwitz
severity: normal
status: open
title: Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.
type: feature request

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

From report at bugs.python.org  Fri Apr 11 04:45:15 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Fri, 11 Apr 2008 02:45:15 +0000
Subject: [New-bugs-announce] [issue2612] file.tell() returns Long usually,
	Int if subclassed
In-Reply-To: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>
Message-ID: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>


New submission from Darryl Dixon <esrever_otua at winterhouseconsulting.com>:

Compare:


>>> class y(file):
...     def __init__(self, name):
...         file.__init__(self, name)
...     def __len__(self):
...         self.seek(0, 2)
...         return self.tell()
... 
>>> n = y('/tmp/longfile')
>>> len(n)
364773376


Versus:


>>> class z:
...     def __init__(self, name):
...         self.f = file(name, 'r')
...     def __len__(self):
...         self.f.seek(0, 2)
...         return self.f.tell()
... 
>>> x = z('/tmp/longfile')
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: __len__() should return an int


Because:



>>> x = file('/tmp/longfile')
>>> type(x.tell())
<type 'long'>

----------
components: Library (Lib)
messages: 65331
nosy: esrever_otua
severity: normal
status: open
title: file.tell() returns Long usually, Int if subclassed
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Fri Apr 11 10:42:50 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 11 Apr 2008 08:42:50 +0000
Subject: [New-bugs-announce] [issue2613] inconsistency with bare * in
	parameter list
In-Reply-To: <1207903370.95.0.0868464301565.issue2613@psf.upfronthosting.co.za>
Message-ID: <1207903370.95.0.0868464301565.issue2613@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

A bare * in a parameter list behaves differently depending on what
follows it:

Py30a4:

>>> def f(*, a=1, b=2): return 1

>>> def g(*, **kwargs): return 1
SyntaxError: named arguments must follow bare * (<pyshell#10>, line 1)

I don't know if this is a bug or not but thought it worth querying. This
case does not seem to be mentioned in PEP 3102.

----------
components: Interpreter Core
messages: 65340
nosy: mark
severity: normal
status: open
title: inconsistency with bare * in parameter list
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Apr 11 10:47:39 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Apr 2008 08:47:39 +0000
Subject: [New-bugs-announce] [issue2614] Console UnicodeDecodeError s once
	more
In-Reply-To: <1207903659.28.0.871159161104.issue2614@psf.upfronthosting.co.za>
Message-ID: <1207903659.28.0.871159161104.issue2614@psf.upfronthosting.co.za>


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

Python debugging under console is a PITA, because it has a bad habit to
fail with UnicodeEncodeError in case of unknown encoding in output. It
quickly turns into a headache when inspecting methods like in the
following example running under windows:

>>> import active_directory
>>> users = active_directory.search ("objectCategory='Person'",
"objectClass='User'")
>>> u = users.next()
>>> u = users.next()
>>> u = users.next()
>>> u.dump()
LDAP://CN=L????????,CN=Users,DC=dom,DC=com
{
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build\bdist.win32\egg\active_directory.py", line 495, in dump
  File "C:\Python25\lib\codecs.py", line 303, in write
    data, consumed = self.encode(object, self.errors)
  File "C:\Python25\lib\encodings\cp1251.py", line 12, in en
code
    return codecs.charmap_encode(input,errors,encoding_table)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 8:
ordinal
not in range(128)

Will this be fixed in Py3k to allow range(255) in case of unknown
encoding? Or will there be a new wrapper function - some
rawhexprint(...) that will temporary change sys.output encoding for the
time arguments are executed and process out of range symbols in output
stream according to its embedded rules (i.e. converting to hex
representaton). Another function can be supplied to write raw bytes to
console as-is. Raw write is preferable as it gives the possibility to
redirect output to a file and inspect it later.

These encoding issues in my POV is the stumbling block that makes
scripting in Python 2.x harder for non-english users and hampers overall
Python adoption. Is this going change in Py3k?

----------
components: Unicode, Windows
messages: 65342
nosy: techtonik
severity: normal
status: open
title: Console UnicodeDecodeError s once more
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Fri Apr 11 13:19:49 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 11 Apr 2008 11:19:49 +0000
Subject: [New-bugs-announce] [issue2615] xml.dom.minidom documentation
	consistency and update
In-Reply-To: <1207912789.81.0.894453276302.issue2615@psf.upfronthosting.co.za>
Message-ID: <1207912789.81.0.894453276302.issue2615@psf.upfronthosting.co.za>


New submission from Jeroen Ruigrok van der Werven <asmodai at in-nomine.org>:

xml.dom.minidom details three methods: writexml(), toxml(),
toprettyxml(). Only one, toxml(), showed the optional encoding argument.
In the documentation for writexml() the encoding argument is explained,
but toprettyxml() refers to toxml() for the details, which are not
present there.

----------
assignee: georg.brandl
components: Documentation
files: minidom.diff
keywords: patch
messages: 65347
nosy: asmodai, georg.brandl
severity: normal
status: open
title: xml.dom.minidom documentation consistency and update
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10004/minidom.diff

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

From report at bugs.python.org  Fri Apr 11 16:52:14 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Apr 2008 14:52:14 +0000
Subject: [New-bugs-announce] [issue2616] ctypes.pointer(),
	ctypes.POINTER() speedup
In-Reply-To: <1207925534.93.0.923711950169.issue2616@psf.upfronthosting.co.za>
Message-ID: <1207925534.93.0.923711950169.issue2616@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements the POINTER() and the pointer() function in C;
giving a speedup of roughly a factor of 2.

----------
assignee: theller
components: ctypes
files: ctypes-pointer.diff
keywords: patch, patch
messages: 65356
nosy: theller
severity: normal
status: open
title: ctypes.pointer(), ctypes.POINTER() speedup
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10007/ctypes-pointer.diff

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

From report at bugs.python.org  Fri Apr 11 20:48:30 2008
From: report at bugs.python.org (Frank Wierzbicki)
Date: Fri, 11 Apr 2008 18:48:30 +0000
Subject: [New-bugs-announce] [issue2617] Patch to emit "-J is reserved for
	Jython" on -J arg
In-Reply-To: <1207939710.11.0.248757051095.issue2617@psf.upfronthosting.co.za>
Message-ID: <1207939710.11.0.248757051095.issue2617@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

This patch adds the message "-J is reserved for Jython" if that arg is
attempted.  See
http://mail.python.org/pipermail/python-dev/2008-April/078564.html

For support from BDFL.

----------
components: Interpreter Core
files: argdashjay.diff
keywords: patch
messages: 65365
nosy: fwierzbicki
severity: normal
status: open
title: Patch to emit "-J is reserved for Jython" on -J arg
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10009/argdashjay.diff

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

From report at bugs.python.org  Fri Apr 11 21:44:00 2008
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 11 Apr 2008 19:44:00 +0000
Subject: [New-bugs-announce] [issue2618] Tile module: Add support for themed
	widgets
In-Reply-To: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>
Message-ID: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>


New submission from Kevin Walzer <wordtech at users.sourceforge.net>:

The Tile module adds support for the platform-native themed widgets now 
available in Tk 8.5's core (ttk:: namespace in Tk terms). The module 
also supports the ttk:: namespace for Tk 8.4 if a separate Tk extension 
is installed. Adding this module to the core lib-tk library will make it 
simple for Tkinter developers to access the improved, modern widget set 
now available.

The module was originally developed by Martin Franklin. I have updated 
and maintained it for the past two years. Martin Franklin has granted me 
permission to submit it for inclusion in the lib-tk core; documentation 
available on request.

----------
components: Tkinter
files: Tile.py
messages: 65367
nosy: wordtech
severity: normal
status: open
title: Tile module: Add support for themed widgets
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10010/Tile.py

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

From report at bugs.python.org  Fri Apr 11 22:46:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Apr 2008 20:46:58 +0000
Subject: [New-bugs-announce] [issue2619] Document memoryview
In-Reply-To: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>
Message-ID: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

memoryview documentation is currently nonexistent.

----------
assignee: georg.brandl
components: Documentation
messages: 65370
nosy: benjamin.peterson, georg.brandl
priority: critical
severity: normal
status: open
title: Document memoryview
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Sat Apr 12 00:35:38 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Fri, 11 Apr 2008 22:35:38 +0000
Subject: [New-bugs-announce] [issue2620] Multiple buffer overflows in
	unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

174 static
 175 int unicode_resize(register PyUnicodeObject *unicode,
 176                       Py_ssize_t length)
 177 {
 [...]
 201 
 202     oldstr = unicode->str;
 203     PyMem_RESIZE(unicode->str, Py_UNICODE, length + 1);
[...]
 209     unicode->str[length] = 0;
 210     unicode->length = length;
 211  

 95 #define PyMem_RESIZE(p, type, n) \
 96   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 97         ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )

The unicode_resize() function acts essentially as a wrapper to
realloc(), it accomplishes this via the PyMem_RESIZE() macro which
factors the size with the size of the type, in this case it multiplies
by two as Py_UNICODE is typedef'd to a wchar_t. When resizing large
strings, this results in an incorrect allocation that in turn leads to
buffer overflow.

This is specific to the Unicode objects, however I would not be
surprised to see that other types have this complication as well. Please
see attached proof of concepts.

----------
components: Interpreter Core
files: python-2.5.2-unicode_resize-utf7.py
messages: 65379
nosy: jnferguson
severity: normal
status: open
title: Multiple buffer overflows in unicode processing
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file10011/python-2.5.2-unicode_resize-utf7.py

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

From report at bugs.python.org  Sat Apr 12 02:32:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 00:32:26 +0000
Subject: [New-bugs-announce] [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I used some brute force search and replace for this and it worked quite
well. If this patch is accepted, I'll fix the docs.

----------
components: Tests
files: rename_test_support.patch
keywords: easy, patch
messages: 65385
nosy: benjamin.peterson, brett.cannon, georg.brandl
severity: normal
status: open
title: rename test_support to support
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10014/rename_test_support.patch

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

From report at bugs.python.org  Sat Apr 12 07:37:53 2008
From: report at bugs.python.org (John Jackson)
Date: Sat, 12 Apr 2008 05:37:53 +0000
Subject: [New-bugs-announce] [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>


New submission from John Jackson <johnjackson at pobox.com>:

In email.message.py there are two import errors:
line 128 from email.Generator import Generator
should be 
  from email.generator import Generator
line 784 from email.Iterators import walk
should be 
  from email.iterators import walk

----------
components: Library (Lib)
messages: 65391
nosy: JohnJackson
severity: normal
status: open
title: Import errors in email.message.py
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 12 08:11:49 2008
From: report at bugs.python.org (Leonard Clark)
Date: Sat, 12 Apr 2008 06:11:49 +0000
Subject: [New-bugs-announce] [issue2623] Patch: xmlrpclib client ignores
	datetime tzinfo when creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>


New submission from Leonard Clark <lclark at 2bdx.net>:

xmlrpclib ignores datetime parameter timezone information.  Two spots
were identified to apply a new formatting function, _iso8601format, to
ensure that the timezone is passed to the server.

I would like this fix to be included in future releases. (Thank you!)

----------
components: XML
files: xmlrpclib-timezone.patch
keywords: patch
messages: 65394
nosy: lclark
severity: normal
status: open
title: Patch: xmlrpclib client ignores datetime tzinfo when creating iso8601 dates
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10016/xmlrpclib-timezone.patch

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

From report at bugs.python.org  Sat Apr 12 14:53:25 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sat, 12 Apr 2008 12:53:25 +0000
Subject: [New-bugs-announce] [issue2624] swig support in distutils should
	use the build and temp dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>


New submission from Kjell Braden <fnord at pentabarf.de>:

Distutils should tell swig to create it's C wrapper file into the
temporary directory (eg. build/temp.linux-i686-2.5) and to write the
language specific files to the library directory (eg.
build/lib.linux-i686-2.5).

Rationale:
Without the language specific files, python swig extensions won't be
able to run, so they should definetly be distributed by distutils.
The wrapper files are build by-products and should therefore be in the
temporary directory, so they get cleaned up on "setup.py clean".

----------
components: Demos and Tools
messages: 65399
nosy: afflux
severity: normal
status: open
title: swig support in distutils should use the build and temp dirs
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 12 19:58:51 2008
From: report at bugs.python.org (=?utf-8?q?Christer_Sj=C3=B6holm?=)
Date: Sat, 12 Apr 2008 17:58:51 +0000
Subject: [New-bugs-announce] [issue2625] mailbox.MH.get_message() treats
	result of get_sequences() as list of tuples
In-Reply-To: <1208023131.05.0.0270197595247.issue2625@psf.upfronthosting.co.za>
Message-ID: <1208023131.05.0.0270197595247.issue2625@psf.upfronthosting.co.za>


New submission from Christer Sj?holm <hcs at furuvik.net>:

in mailbox.MH.get_message() there is a loop over the mailbox sequences
on row 894 in Python 2.5.2
  for name, key_list in self.get_sequences():
but mailbox.MH.get_sequences() returns a dict so it should be
  for name, key_list in self.get_sequences().iteritems():

----------
components: Library (Lib)
messages: 65408
nosy: hcs
severity: normal
status: open
title: mailbox.MH.get_message() treats result of get_sequences() as list of tuples
type: behavior
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Sun Apr 13 01:30:02 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Sat, 12 Apr 2008 23:30:02 +0000
Subject: [New-bugs-announce] [issue2626] If compile with gcc 4.3.0 python
	interpreter itself eats all memory
In-Reply-To: <1208043002.25.0.498433851642.issue2626@psf.upfronthosting.co.za>
Message-ID: <1208043002.25.0.498433851642.issue2626@psf.upfronthosting.co.za>


New submission from Georgij Kondratjev <smpuj at bk.ru>:

First time I noticed it during compilation of python3 r62301, then 
3.0a4, then 3.0a3, with and without CFLAGS set. 
Step "./python -E ./setup.py -q build" called by make never ends (and 
there is no output). Just "/python" behaves the same: it eats memory 
and prints nothing. Gcc 3.4.6 works fine. Previous versions of gcc 4 
were working too, but I didn`t tested them now.
My system: gcc 4.3.0, kernel 2.6.24.zen5.20080410 (with zen patchset, 
can test again with vanilla 2.6.24, or if you say it is too old I will 
compile 2.6.24.4), glibc 2.7, Arch GNU/Linux.

----------
components: Interpreter Core
messages: 65426
nosy: orivej
severity: normal
status: open
title: If compile with gcc 4.3.0 python interpreter itself eats all memory
versions: Python 3.0

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

From report at bugs.python.org  Sun Apr 13 18:45:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Apr 2008 16:45:40 +0000
Subject: [New-bugs-announce] [issue2627] mark pgen generated files
In-Reply-To: <1208105140.17.0.711771131434.issue2627@psf.upfronthosting.co.za>
Message-ID: <1208105140.17.0.711771131434.issue2627@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch makes pgen note that it generated the file at the top.

----------
assignee: georg.brandl
components: Interpreter Core
files: pgen_generated.patch
keywords: easy, patch
messages: 65447
nosy: benjamin.peterson, georg.brandl
priority: low
severity: normal
status: open
title: mark pgen generated files
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10021/pgen_generated.patch

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

From report at bugs.python.org  Mon Apr 14 01:50:11 2008
From: report at bugs.python.org (Jonathan)
Date: Sun, 13 Apr 2008 23:50:11 +0000
Subject: [New-bugs-announce] [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>


New submission from Jonathan <jbell at scrippsweb.com>:

About a year ago I found myself fighting a broken FTP server that
couldn't handle multiple passive data transfers through a firewall or
NATed connection. Thankfully, this same problem server supports block
transmission mode, which allows a client to create a single data
connection for transferring multiple files.

I've attached a patch (and sample debug output) for the latest trunk.

Might this be useful to anyone else in any way? I realize any MODE
option rather than S is widely unsupported and possibly an edge case,
but getting this into trunk would be preferable. We've been running this
code under Python2.3 for nearly a year -- the jobs run several times per
hour -- and are extremely happy with the results.

----------
components: Library (Lib)
files: ftplib.py.blockmode.patch
keywords: patch
messages: 65454
nosy: jbell
severity: normal
status: open
title: ftplib Persistent data connection
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10025/ftplib.py.blockmode.patch

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

From report at bugs.python.org  Mon Apr 14 04:56:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Apr 2008 02:56:09 +0000
Subject: [New-bugs-announce] [issue2629] _Py_ForgetReference crash when
	called from _PyUnicode_New on MemoryError
In-Reply-To: <1208141769.9.0.601794636636.issue2629@psf.upfronthosting.co.za>
Message-ID: <1208141769.9.0.601794636636.issue2629@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

In _PyUnicode_New() a unicode object is taken from the freelist but if
the unicode_resize() call fails and returns -1, the goto onerror calls
_Py_ForgetReference on the unicode object... But it has NULL _ob_prev
and _ob_next values causing a crash when they're used.

How to reproduce:

* Make a 32-bit --with-pydebug build of Python trunk.
* Run it on a machine with lots of ram (at least 3gigs recommended, or
lots of swap and a heap of patience):

./python
Python 2.6a2+ (trunk:62336M, Apr 13 2008, 18:51:30)
>>> msg = 'A'*2000111222
>>> x = msg.decode('utf8')

It segmentation faults in _Py_ForgetReference.

----------
messages: 65456
nosy: gregory.p.smith
severity: normal
status: open
title: _Py_ForgetReference crash when called from _PyUnicode_New on MemoryError
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 14 11:54:24 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Mon, 14 Apr 2008 09:54:24 +0000
Subject: [New-bugs-announce] [issue2630] repr() should not escape non-ASCII
	characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>


New submission from atsuo ishimoto <ishimoto at users.sourceforge.net>:

In py3k, repr() escapes non-ASCII characters in Unicode to \uXXXX as
Python 2. This is unpleasant feature if you are working with non-latin
characters. This issue was once discussed by Hye-Shik Chang[1], but was
rejected. Here's a new challenge for Python 3 to fix issue.

In this patch, repr() converts special ascii characters such as "\t", 
"\r", "\n", but doesn't convert non-ASCII characters to \uXXXX form. 
Non-ASCII characters are converted by TextIOWrapper on printing. I set 
'errors' attribute of sys.stdout and sys.stderr to 'backslashreplace', so
un-printable characters are converted to '\uXXXX' if your console
cannot print such characters.

This patch breaks five regr tests on my environment. 
I'll fix these tests if this patch is acceptable.

[1] http://mail.python.org/pipermail/python-dev/2002-October/029443.html
http://bugs.python.org/issue479898

----------
components: None
files: diff.txt
messages: 65461
nosy: ishimoto
severity: normal
status: open
title: repr() should not escape non-ASCII characters
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10028/diff.txt

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

From report at bugs.python.org  Mon Apr 14 20:22:11 2008
From: report at bugs.python.org (Paul Bonser)
Date: Mon, 14 Apr 2008 18:22:11 +0000
Subject: [New-bugs-announce] [issue2631] IMPORT_NAME Documentation is
	incomplete
In-Reply-To: <1208197331.08.0.00587234594445.issue2631@psf.upfronthosting.co.za>
Message-ID: <1208197331.08.0.00587234594445.issue2631@psf.upfronthosting.co.za>


New submission from Paul Bonser <paul at paulbonser.com>:

The documentation for IMPORT_NAME at
http://docs.python.org/lib/bytecodes.html doesn't mention the fact that
the instruction requires two parameters to be on the stack.

TOS and TOS1 should map to the fromlist and level parameters to the
builtin function __import__, respectively.

----------
assignee: georg.brandl
components: Documentation
messages: 65471
nosy: georg.brandl, pib
severity: normal
status: open
title: IMPORT_NAME Documentation is incomplete
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr 14 20:30:16 2008
From: report at bugs.python.org (Curt Hagenlocher)
Date: Mon, 14 Apr 2008 18:30:16 +0000
Subject: [New-bugs-announce] [issue2632] socket._fileobject.read(n) should
	ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>


New submission from Curt Hagenlocher <curt at hagenlocher.org>:

First reported by Ralf Schmitt.
I haven't checked 2.6 or 3.0.

----------
components: Library (Lib)
files: socket.py.diff
keywords: patch
messages: 65472
nosy: CurtHagenlocher
severity: normal
status: open
title: socket._fileobject.read(n) should ignore _rbufsize when 1
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10029/socket.py.diff

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

From report at bugs.python.org  Mon Apr 14 22:44:37 2008
From: report at bugs.python.org (Roy Smith)
Date: Mon, 14 Apr 2008 20:44:37 +0000
Subject: [New-bugs-announce] [issue2633] Improve subprocess.Popen()
	documentation ("env" parameter)
In-Reply-To: <1208205877.08.0.141694096579.issue2633@psf.upfronthosting.co.za>
Message-ID: <1208205877.08.0.141694096579.issue2633@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

http://docs.python.org/lib/node528.html (17.1.1 Using the subprocess 
Module) describes the "env" parameter thusly:

If env is not None, it defines the environment variables for the new 
process.

This is too vague to be useful.  If it's not None, what should it be?  A 
dictionary in the style of os.environ?  A sequence of name/value pairs?  A 
string with some sort of delimiter between each entry?

----------
assignee: georg.brandl
components: Documentation
messages: 65480
nosy: georg.brandl, roysmith
severity: normal
status: open
title: Improve subprocess.Popen() documentation ("env" parameter)
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 15 06:31:46 2008
From: report at bugs.python.org (Roy Smith)
Date: Tue, 15 Apr 2008 04:31:46 +0000
Subject: [New-bugs-announce] [issue2634] os.execvpe() docs need to be more
	specific
In-Reply-To: <1208233905.92.0.0192378489654.issue2634@psf.upfronthosting.co.za>
Message-ID: <1208233905.92.0.0192378489654.issue2634@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

Note: this is (sort of) related to Issue2633.

http://docs.python.org/lib/os-process.html (14.1.5 Process Management).

The docs for os.execvpe() say, "the env parameter must be a mapping which 
is used to define the environment variables for the new process".  It's 
not clear if this mapping replaces the existing environment, or defines 
additional entries which are added to the existing environment.  This 
should be clarified.

This applies to the spawn*() methods too.

----------
assignee: georg.brandl
components: Documentation
messages: 65496
nosy: georg.brandl, roysmith
severity: normal
status: open
title: os.execvpe() docs need to be more specific
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 15 07:54:45 2008
From: report at bugs.python.org (Giuseppe Scelsi)
Date: Tue, 15 Apr 2008 05:54:45 +0000
Subject: [New-bugs-announce] [issue2635] textwrap: bug in
	'fix_sentence_endings' option
In-Reply-To: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>
Message-ID: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>


New submission from Giuseppe Scelsi <giuseppe.scelsi at analog.com>:

>>> textwrap.fill('File stdio.h is nice.',
...     fix_sentence_endings=True)
'File stdio.h  is nice.'
              ^-- wrong double space!

The problem is with the compiled regexp 'sentence_end_re' in
'textwrap.py'.  A possible fix would be to add the following line after
line 90 in textwrap.py:

    r'$'  # end of chunk

Giuseppe

----------
components: Library (Lib)
messages: 65501
nosy: gscelsi
severity: normal
status: open
title: textwrap: bug in 'fix_sentence_endings' option
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Tue Apr 15 13:57:52 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Tue, 15 Apr 2008 11:57:52 +0000
Subject: [New-bugs-announce] [issue2636] Regexp 2.6 (modifications to
	current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>


New submission from Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:

I am working on adding features to the current Regexp implementation,
which is now set to 2.2.2.  These features are to bring the Regexp code
closer in line with Perl 5.10 as well as add a few python-specific
niceties and potential speed-ups and clean-ups.

I will be posting regular patch updates to this thread when major
milestones have been reach with a description of the feature(s) added. 
Currently, the list of proposed changes are (in no particular order):

1) Fix <a href="http://bugs.python.org/issue433030">issue 433030</a> by
adding support for Atomic Grouping and Possessive Qualifiers

2) Make named matches direct attributes of the match object; i.e.
instead of m.group('foo'), one will be able to write simply m.foo.

3) (maybe) make Match objects subscriptable, such that m[n] is
equivalent to m.group(n) and allow slicing.

4) Implement Perl-style back-references including relative back-references.

5) Add a well-formed, python-specific comment modifier, e.g. (?P#...);
the difference between (?P#...) and Perl/Python's (?#...) is that the
former will allow nested parentheses as well as parenthetical escaping,
so that patterns of the form '(?P# Evaluate (the following) expression,
3\) using some other technique)'.  The (?P#...) will interpret this
entire expression as a comment, where as with (?#...) only, everything
following ' expression...' would be considered part of the match. 
(?P#...) will necessarily be slower than (?#...) and so only should be
used if richer commenting style is required but the verbose mode is not
desired.

6) Add official support for fast, non-repeating capture groups with the
Template option.  Template is unofficially supported and disables all
repeat operators (*, + and ?).  This would mainly consist of documenting
its behavior.

7) Modify the re compiled expression cache to better handle the
thrashing condition.  Currently, when regular expressions are compiled,
the result is cached so that if the same expression is compiled again,
it is retrieved from the cache and no extra work has to be done.  This
cache supports up to 100 entries.  Once the 100th entry is reached, the
cache is cleared and a new compile must occur.  The danger, all be it
rare, is that one may compile the 100th expression only to find that one
recompiles it and has to do the same work all over again when it may
have been done 3 expressions ago.  By modifying this logic slightly, it
is possible to establish an arbitrary counter that gives a time stamp to
each compiled entry and instead of clearing the entire cache when it
reaches capacity, only eliminate the oldest half of the cache, keeping
the half that is more recent.  This should limit the possibility of
thrashing to cases where a very large number of Regular Expressions are
continually recompiled.  In addition to this, I will update the limit to
256 entries, meaning that the 128 most recent are kept.

8) Emacs/Perl style character classes, e.g. [:alphanum:].  For instance,
:alphanum: would not include the '_' in the character class.

9) C-Engine speed-ups.  I commenting and cleaning up the _sre.c Regexp
engine to make it flow more linearly, rather than with all the current
gotos and replace the switch-case statements with lookup tables, which
in tests have shown to be faster.  This will also include adding many
more comments to the C code in order to make it easier for future
developers to follow.  These changes are subject to testing and some
modifications may not be included in the final release if they are shown
to be slower than the existing code.  Also, a number of Macros are being
eliminated where appropriate.

10) Export any (not already) shared value between the Python Code and
the C code, e.g. the default Maximum Repeat count (65536); this will
allow those constants to be changed in 1 central place.

11) Various other Perl 5.10 conformance modifications, TBD.


More items may come and suggestions are welcome.

-----

Currently, I have code which implements 5) and 7), have done some work
on 10) and am almost 9).  When 9) is complete, I will work on 1), some
of which, such as parsing, is already done, then probably 8) and 4)
because they should not require too much work -- 4) is parser-only
AFAICT.  Then, I will attempt 2) and 3), though those will require
changes at the C-Code level.  Then I will investigate what additional
elements of 11) I can easily implement.  Finally, I will write
documentation for all of these features, including 6).

In a few days, I will provide a patch with my interim results and will
update the patches with regular updates when Milestones are reached.

----------
components: Library (Lib)
messages: 65513
nosy: timehorse
severity: normal
status: open
title: Regexp 2.6 (modifications to current re 2.2.2)
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 15 17:09:11 2008
From: report at bugs.python.org (Tim Lesher)
Date: Tue, 15 Apr 2008 15:09:11 +0000
Subject: [New-bugs-announce] [issue2637] urllib.quote() escapes characters
	unnecessarily and contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>


New submission from Tim Lesher <tlesher at gmail.com>:

The urllib.quote docstring implies that it quotes only characters in RFC
2396's "reserved" set.

However, urllib.quote currently escapes all characters except those in
an "always_safe" list, which consists of alphanumerics and three
punctuation characters, "_.-".

This behavior is contrary to the RFC, which defines "unreserved"
characters as alphanumerics plus "mark" characters, or "-_.!~*'()".  

The RFC also says:

  Unreserved characters can be escaped without changing the semantics
  of the URI, but this should not be done unless the URI is being used
  in a context that does not allow the unescaped character to appear.

This seems to imply that "always_safe" should correspond to the RFC's
"unreserved" set of "alphanum" | "mark".

----------
components: Library (Lib)
messages: 65518
nosy: tlesher
severity: normal
status: open
title: urllib.quote() escapes characters unnecessarily and contrary to docs
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 15 17:44:13 2008
From: report at bugs.python.org (Ron Longo Work)
Date: Tue, 15 Apr 2008 15:44:13 +0000
Subject: [New-bugs-announce] [issue2638] tkSimpleDialog Window Flashing
In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>
Message-ID: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>


New submission from Ron Longo Work <longorh at npt.nuwc.navy.mil>:

When a Tkinter window comes up that uses tkSimpleDialog to construct a 
dialog box, the window first flashes on the screen as an unpopulated 
top-level window, before being drawn in its completed state.

This problem is easily corrected by adding two lines of code to the 
constructor for class Dialog in tkSimpleDialog.py.  The first line of 
the constructor reads Toplevel.__init__( self, parent ).  After this 
line insert self.overrideredirect( True ).  The second line from the 
last in this constructor reads self.initial_focus.focus_set(), just 
before this line insert self.overrideredirect( False).  That's it.  
I've attached the revised version of this file.

----------
components: Tkinter
files: tkSimpleDialog.py
messages: 65519
nosy: Longorh
severity: normal
status: open
title: tkSimpleDialog Window Flashing
versions: Python 2.5
Added file: http://bugs.python.org/file10035/tkSimpleDialog.py

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

From report at bugs.python.org  Tue Apr 15 18:11:06 2008
From: report at bugs.python.org (Roy Smith)
Date: Tue, 15 Apr 2008 16:11:06 +0000
Subject: [New-bugs-announce] [issue2639] shutil.copyfile() documentation is
	vague
In-Reply-To: <1208275866.73.0.43584708825.issue2639@psf.upfronthosting.co.za>
Message-ID: <1208275866.73.0.43584708825.issue2639@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The current doc says, "Copy the contents of the file named src to a file 
named dst".  Anybody used to the unix shell "cp" command would assume that 
dst could be a directory, in which case the true destination is a file in 
that directory with the same basename as src.  Experimentation shows that 
this is not true.  A note something like the following would help:

Note: unlike the "cp" shell command, dst may not be a directory; it must 
be a path to a file in that directory.

True, there's no place in the docs which actually says a directory is 
valid for dst, but the name of the module is shutil, so it's reasonable 
for people to assume that these act the same way as the corresponding unix 
shell commands.  It should be stated up front that this is not true, to 
avoid confusion.

----------
assignee: georg.brandl
components: Documentation
messages: 65521
nosy: georg.brandl, roysmith
severity: normal
status: open
title: shutil.copyfile() documentation is vague
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 15 19:38:59 2008
From: report at bugs.python.org (Jeff Hall)
Date: Tue, 15 Apr 2008 17:38:59 +0000
Subject: [New-bugs-announce] [issue2640] "excel" csv option generates
	multiple lines
In-Reply-To: <1208281138.97.0.0353161636631.issue2640@psf.upfronthosting.co.za>
Message-ID: <1208281138.97.0.0353161636631.issue2640@psf.upfronthosting.co.za>


New submission from Jeff Hall <hall.jeff at gmail.com>:

Current: csv.py indicates lineterminator = '\r\n'
Issue: looks fine in notepad but when pulled into excel (office 2003)
extra lines are added
Resolution: should read lineterminator = '\r'

----------
components: Extension Modules
messages: 65523
nosy: laxrulz777
severity: normal
status: open
title: "excel" csv option generates multiple lines
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 15 22:34:36 2008
From: report at bugs.python.org (Jason Orendorff)
Date: Tue, 15 Apr 2008 20:34:36 +0000
Subject: [New-bugs-announce] [issue2641] setuptools gets site-packages wrong
	on Mac
In-Reply-To: <1208291676.15.0.165300999847.issue2641@psf.upfronthosting.co.za>
Message-ID: <1208291676.15.0.165300999847.issue2641@psf.upfronthosting.co.za>


New submission from Jason Orendorff <jason.orendorff at gmail.com>:

On my Mac, /usr/local/bin/python2.5 is a symlink to
"../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5".

When I install Mercurial from source, the "mercurial" package is
installed at "/usr/local/lib/python2.5/site-packages/mercurial", so the
installation is broken.  Since "site-packages" appears nowhere in the
Mercurial source tree, I think it's setuptools (not Mercurial) that is
getting this wrong.

Mercurial's setup.py can be seen here:

(as of this writing)
http://hg.intevation.org/mercurial/crew/file/628da4a91628/setup.py

(the latest)
http://hg.intevation.org/mercurial/crew/file/tip/setup.py

I'm not sure what the Right Thing would be, but if it's agreed that the
current behavior is a hack, then `(p for p in sys.path if
p.endswith('site-packages')).next()`, falling back to the current
behavior, seems like a better hack.

Happy to patch, if someone can advise me; MvL?

----------
components: Distutils
messages: 65527
nosy: jorendorff
severity: normal
status: open
title: setuptools gets site-packages wrong on Mac
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Apr 16 03:05:54 2008
From: report at bugs.python.org (Wesley Spikes)
Date: Wed, 16 Apr 2008 01:05:54 +0000
Subject: [New-bugs-announce] [issue2642] MSVCRT packing in Windows Installer
	(3.0a4)
In-Reply-To: <1208307954.26.0.976441320091.issue2642@psf.upfronthosting.co.za>
Message-ID: <1208307954.26.0.976441320091.issue2642@psf.upfronthosting.co.za>


New submission from Wesley Spikes <wesley.spikes at gmail.com>:

I've searched and did not find any open ticket to make suggestions on, 
so I'm posting it here.

You currently have posted "The MSI installers for Python 3.0a4 are 
compiled with the new Visual Studio 2008 Professional version. 
Therefore Python depends on the -Visual C++ runtime library 9.0. We 
currently don't package this library properly, which means that non-
Administrator installation is currently not supported. Contributions to 
fix this problem are welcome."

Two potential fixes, both of which should be very readily doable. First 
one is to set the Linking option in MSVC++ to a static link to the CRT. 
This in-builds the library with Python. (Options /MT and /MTd, for 
release and debug versions, respectively.)

The other potential resolution for Non-Admin installs, which may or may 
not be more stable, is to include the MSVCRT DLLs into the directory 
containing the Python installation. If needed, you may have to register 
these files manually into the HKCU hive.

Hope that helps with your described packaging issue with the installer.

(Classified under Build and Installation, since it deals with both 
halves -- feel free to reclassify as appropriate.)

----------
components: Build, Installation
messages: 65537
nosy: wesley.spikes
severity: normal
status: open
title: MSVCRT packing in Windows Installer (3.0a4)
versions: Python 3.0

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

From report at bugs.python.org  Wed Apr 16 18:29:01 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:29:01 +0000
Subject: [New-bugs-announce] [issue2643] mmap_object_dealloc does not call
	FlushViewOfFile on windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

on unix it does call msync however.


here is the relevant part from mmapmodule.c:

static void
mmap_object_dealloc(mmap_object *m_obj)
{
#ifdef MS_WINDOWS
	if (m_obj->data != NULL)
		UnmapViewOfFile (m_obj->data);
	if (m_obj->map_handle != INVALID_HANDLE_VALUE)
		CloseHandle (m_obj->map_handle);
	if (m_obj->file_handle != INVALID_HANDLE_VALUE)
		CloseHandle (m_obj->file_handle);
	if (m_obj->tagname)
		PyMem_Free(m_obj->tagname);
#endif /* MS_WINDOWS */

#ifdef UNIX
	if (m_obj->fd >= 0)
		(void) close(m_obj->fd);
	if (m_obj->data!=NULL) {
		msync(m_obj->data, m_obj->size, MS_SYNC);
		munmap(m_obj->data, m_obj->size);
	}
#endif /* UNIX */

	Py_TYPE(m_obj)->tp_free((PyObject*)m_obj);
}

----------
messages: 65552
nosy: schmir
severity: normal
status: open
title: mmap_object_dealloc does not call FlushViewOfFile on windows

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

From report at bugs.python.org  Wed Apr 16 18:30:26 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:30:26 +0000
Subject: [New-bugs-announce] [issue2644] errors from msync ignored in
	mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

mmapmodule.c's mmap_object_dealloc calls msync without checking for an
error.

----------
messages: 65553
nosy: schmir
severity: normal
status: open
title: errors from msync ignored in mmap_object_dealloc
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 16 20:16:00 2008
From: report at bugs.python.org (Niall O'Higgins)
Date: Wed, 16 Apr 2008 18:16:00 +0000
Subject: [New-bugs-announce] [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>


New submission from Niall O'Higgins <niallo at unworkable.org>:

I do a lot of urllib2 reads of HTTP URLs.  From time to time, I see the
following exception being thrown:

  File "/usr/local/lib/python2.5/socket.py", line 291, in read
    data = self._sock.recv(recv_size)
  File "/usr/local/lib/python2.5/httplib.py", line 509, in read
    return self._read_chunked(amt)
  File "/usr/local/lib/python2.5/httplib.py", line 548, in _read_chunked
    chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''

The chunked reading code does not expect an empty string.  I have
attached a patch which checks for ValueError in this case and sets
chunk_left to 0, which will break from the loop.  I am not entirely sure
if this is the correct fix, however, but it should illustrate the problem.

----------
components: Library (Lib)
files: httplib.py.diff
keywords: patch
messages: 65557
nosy: niallo
severity: normal
status: open
title: httplib throws ValueError
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10040/httplib.py.diff

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

From report at bugs.python.org  Wed Apr 16 23:40:06 2008
From: report at bugs.python.org (John (J5) Palmieri)
Date: Wed, 16 Apr 2008 21:40:06 +0000
Subject: [New-bugs-announce] [issue2646] Python does not accept unicode
	keywords
In-Reply-To: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>
Message-ID: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>


New submission from John (J5) Palmieri <johnp at redhat.com>:

# given this function

def a(**kwargs):
    pass

# this works
a(**{'b':'c'})

# this throws a format error
a(**{u'b':'c'})

I am using a web framework (TurboGears w/ genshi templating) which often
pass around dictionaries as keyword arguments in order to have 1 to 1
representation of json data and URL parameters.  This is usually fine
except when using libraries such as simplejson which encodes all of the
keywords as unicode.

Attached is a patch which is most likely just the tip of the iceberg but
hopefully it turns out to be this easy.

----------
components: Library (Lib)
files: allow_unicode_keywords.patch
keywords: patch
messages: 65567
nosy: j5
severity: normal
status: open
title: Python does not accept unicode keywords
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10043/allow_unicode_keywords.patch

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

From report at bugs.python.org  Thu Apr 17 05:02:00 2008
From: report at bugs.python.org (Richard Esplin)
Date: Thu, 17 Apr 2008 03:02:00 +0000
Subject: [New-bugs-announce] [issue2647] XML munges apos entity in tag
	content
In-Reply-To: <1208401320.5.0.728937941745.issue2647@psf.upfronthosting.co.za>
Message-ID: <1208401320.5.0.728937941745.issue2647@psf.upfronthosting.co.za>


New submission from Richard Esplin <richjunk1 at byu.net>:

I would like it to leave my &apos; alone, just like it does with my &lt;
and &gt;

Python 2.5.1 (r251:54863, Sep 21 2007, 22:46:31)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.dom import minidom
>>> doc = minidom.parseString("<tag>&lt;a&apos;b&gt;</tag>")
>>> doc.toxml()
u'<?xml version="1.0" ?><tag>&lt;a\'b&gt;</tag>'
>>>

----------
components: XML
messages: 65570
nosy: resplin
severity: normal
status: open
title: XML munges apos entity in tag content
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 17 11:47:55 2008
From: report at bugs.python.org (Carsten Grohmann)
Date: Thu, 17 Apr 2008 09:47:55 +0000
Subject: [New-bugs-announce] [issue2648] decimal receipe moneyfmt suppress
	leading 0
In-Reply-To: <1208425675.07.0.106835376727.issue2648@psf.upfronthosting.co.za>
Message-ID: <1208425675.07.0.106835376727.issue2648@psf.upfronthosting.co.za>


New submission from Carsten Grohmann <cgrohmann at users.sourceforge.net>:

The current version of the receipe moneyfmt doesn't have a leading "0" 
for 1 < value < -1.

The attached patch adds a new parameter "zero". The parameter is empty 
per default and can set to "0" print a leading "0". The examples are 
updated also.

Possibly the new option should be "0" per default.

Regards,
Carsten

----------
assignee: georg.brandl
components: Documentation
files: moneyfmt.diff
keywords: patch
messages: 65581
nosy: cgrohmann, georg.brandl
severity: normal
status: open
title: decimal receipe moneyfmt suppress leading 0
versions: Python 2.5
Added file: http://bugs.python.org/file10046/moneyfmt.diff

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

From report at bugs.python.org  Thu Apr 17 13:56:45 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 17 Apr 2008 11:56:45 +0000
Subject: [New-bugs-announce] [issue2649] poss. patch for fnmatch.py to add
	{.htm, html} style globbing
In-Reply-To: <1208433404.5.0.648159158993.issue2649@psf.upfronthosting.co.za>
Message-ID: <1208433404.5.0.648159158993.issue2649@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

At the moment fnmatch.py (and therefore glob.py) support:
* . [chars] [!chars]

The attached version of fnmatch.py extends this to:
* . [chars] [!chars] {one,two,...}

There are 2 changes from the original fnmatch.py file:
(1) The documentation for the fnmatch() function has been updated to
reflect the new functionality
(2) The translate() function has been completely replaced.
I ran test_fnmatch.py and test_glob.py and both ran without errors.

----------
components: Library (Lib)
files: fnmatch.py
messages: 65584
nosy: mark
severity: normal
status: open
title: poss. patch for fnmatch.py to add {.htm,html} style globbing
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10047/fnmatch.py

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

From report at bugs.python.org  Thu Apr 17 16:14:10 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 17 Apr 2008 14:14:10 +0000
Subject: [New-bugs-announce] [issue2650] re.escape should not escape
	underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>


New submission from Russ Cox <rsc at swtch.com>:

import re
print re.escape("_")

Prints \_ but should be _.

This behavior differs from Perl and other systems: _ is an identifier
character and as such does not need to be escaped.

----------
messages: 65585
nosy: rsc
severity: normal
status: open
title: re.escape should not escape underscore
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 17 19:24:41 2008
From: report at bugs.python.org (Rick Harris)
Date: Thu, 17 Apr 2008 17:24:41 +0000
Subject: [New-bugs-announce] [issue2651] Strings passed to KeyError do not
	round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>


New submission from Rick Harris <rconradharris at gmail.com>:

Here is a bug in Python 2.5 which would be nice to fix for Py3k (since
we are already breaking compatibility):

Take a string:
s = "Hello"

Create a KeyError exception with that string:
e = KeyError(s)

Counterintuitively, casting the exception to a string doesn't return the
same string:
str(e) != s

Instead, when KeyError is cast to a string it affixes single-quotes
around the string.

I have create a test which shows that the other built-in exceptions
(except for 3 Unicode Errors which seem to be unusual in that they don't
accept just a string), do indeed round-trip the string unaltered.

This actually caused a bug (in an old version of zope.DocumentTemplate).

I am including the test case I wrote for now; I will begin looking into
a solution shortly and hopefully whip up a patch.

----------
components: Interpreter Core
files: testExceptionStringRoundTrip.py
messages: 65586
nosy: rharris
severity: normal
status: open
title: Strings passed to KeyError do not round trip
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10048/testExceptionStringRoundTrip.py

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

From report at bugs.python.org  Fri Apr 18 00:26:08 2008
From: report at bugs.python.org (kevin)
Date: Thu, 17 Apr 2008 22:26:08 +0000
Subject: [New-bugs-announce] [issue2652] 64 bit python  memory leak usage
In-Reply-To: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>
Message-ID: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>


New submission from kevin <kevin3210 at gmail.com>:

For the code below.. memory usage keeps increasing continuously.. This
does not happen in a 32-bit machine python build. i think it might be
the datetime module where the problem might be..


linux kernel version (both on 32-bit and 64 bit machine)
linux - 2.6.24.4-64.fc8
python version (both on 32-bit and 64 bit machine)
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26)


now = datetime.datetime.now()
oneday = datetime.timedelta(days=1)

def birthdaycompare(a, b):
   if a is None and b:
       return 1
   if a and b is None:
       return -1
   if a is None and b is None:
       return 0
   if a<b:
       return -1
   elif a==b:
       return 0
   else:
       return 1

def compare_by(fieldname):
   def comparedict(a,b):
       return birthdaycompare(a[fieldname], b[fieldname])
   return comparedict

def getbirthdays(friend_details):
   new_f = []
   birthday = None
   birthday_dt = None
   for f in friend_details:
       if f.has_key('birthday'):
           birthday = f['birthday']
       if birthday and birthday !='':
           birthday_split = birthday.split(',')[0]
           if birthday_split == 'February 29':
               birthday = 'February 28'
           try:
               birthday_dt =
datetime.datetime.strptime(birthday_split + ', ' + str(now.year) , '%B
%d, %Y')
               if birthday_dt < (now - oneday):
                   birthday_dt =
datetime.datetime.strptime(birthday_split + ', ' + str(now.year+1) ,
'%B %d, %Y')
           except:
               birthday=None
               birthday_dt=None

       f['birthday'] = birthday
       f['birthday_dt'] = birthday_dt
       new_f.append(f)
   new_f.sort(compare_by('birthday_dt'))

----------
files: data.log
messages: 65596
nosy: kevin3210
severity: normal
status: open
title: 64 bit python  memory leak usage
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file10051/data.log

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

From report at bugs.python.org  Fri Apr 18 09:17:06 2008
From: report at bugs.python.org (wr)
Date: Fri, 18 Apr 2008 07:17:06 +0000
Subject: [New-bugs-announce] [issue2653] string to float to int
In-Reply-To: <1208503026.4.0.816414644082.issue2653@psf.upfronthosting.co.za>
Message-ID: <1208503026.4.0.816414644082.issue2653@psf.upfronthosting.co.za>


New submission from wr <woutruijter at gmail.com>:

IDLE 1.2.1      
>>> print int(float('1.005')*1000)
1004

----------
components: None
messages: 65602
nosy: wr
severity: normal
status: open
title: string to float to int
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr 18 15:03:22 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 18 Apr 2008 13:03:22 +0000
Subject: [New-bugs-announce] [issue2654] Typo at
	http://docs.python.org/dev/3.0/howto/doanddont.html
In-Reply-To: <1208523802.33.0.053016703897.issue2654@psf.upfronthosting.co.za>
Message-ID: <1208523802.33.0.053016703897.issue2654@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

At top it says "This document is placed in the public doman." should do
a s/doman/domain .

----------
assignee: georg.brandl
components: Documentation
messages: 65612
nosy: cartman, georg.brandl
severity: normal
status: open
title: Typo at http://docs.python.org/dev/3.0/howto/doanddont.html
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Apr 18 20:31:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Apr 2008 18:31:04 +0000
Subject: [New-bugs-announce] [issue2655] Create ctypes instances from buffer
	interface
In-Reply-To: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>
Message-ID: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements a .from_buffer(source, offset=0) class method from
ctypes types.  'source' must expose a writeable buffer interface; the
created ctypes instance will share the internal buffer of the source
object; also it holds a reference to the source object to keep it alive.

The usual problems with the buffer interface are not hidden.

Open question:
Should there be an additional 'copy_from_buffer' class method that
accepts read-only buffer interface (as an alternative, an optional
'copy=False' parameter could be introduced)?

----------
assignee: theller
components: ctypes
files: from_buffer.patch
keywords: patch, patch
messages: 65620
nosy: theller
severity: normal
status: open
title: Create ctypes instances from buffer interface
versions: Python 2.6
Added file: http://bugs.python.org/file10057/from_buffer.patch

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

From report at bugs.python.org  Fri Apr 18 23:02:44 2008
From: report at bugs.python.org (John Millikin)
Date: Fri, 18 Apr 2008 21:02:44 +0000
Subject: [New-bugs-announce] [issue2656] Autodoc should skip inherited
	methods
In-Reply-To: <1208552563.99.0.233047062632.issue2656@psf.upfronthosting.co.za>
Message-ID: <1208552563.99.0.233047062632.issue2656@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

Using the following class layout:

class A (object):
	def a (self):
		"A.a"
		pass
class B (A):
	def b (self):
		"B.b"
		pass

If sphinx.ext.autodoc is used to extract documentation, the entry for
class B will have subentries for both the a() and b() methods. This is
unnecessary clutter. It would be nice if the inherited method was
skipped when documenting B, or even better if it was inserted as a
"stub" linking to the documentation for A.a().

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 65624
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: Autodoc should skip inherited methods
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr 19 00:51:08 2008
From: report at bugs.python.org (=?utf-8?q?Fernando_P=C3=A9rez?=)
Date: Fri, 18 Apr 2008 22:51:08 +0000
Subject: [New-bugs-announce] [issue2657] curses
In-Reply-To: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>
Message-ID: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>


New submission from Fernando P?rez <fer_perez at users.sourceforge.net>:

Curses sometimes fails to correctly initialize the terminal. 
Unfortunately I don't know how to reproduce the problem, it was reported
multiple times by ipython users, but I have no idea what causes it.  I
finally found a workaround by making a termios call that at least
restores terminal state (see attachment), but it's just a workaround,
not a real fix.

The issue manifests itself as follows: at some point (I don't know why),
a call to curses.initscr() doesn't actually set the terminal in the
usual mode where input isn't accepted, but instead the terminal
continues accepting normal input, issuing newlines, etc.  The only sign
that curses is active is that in a modern terminal, the scrollbar
changes to fill the screen.  After this, calling curses.endwin(),
instead of restoring terminal state, leaves the terminal in the mode
that typically initscr() would put it in: no input is displayed,
printouts swallow end-of-line characters, etc.

When this happened in ipython sessions, we'd just suggest users call
!reset (the system command), which would restore terminal state.  But
the problem is obviously in curses itself, because once this problem
appeared, running the attached script would always print 'False' for the
state condition checked there.

For now in IPython we have a workaround, but perhaps with this little
description/example, someone who knows the curses code might be able to
actually fix the real problem.  If I find a reliable way to trigger the
bug, I'll add comments here indicating so.

----------
components: Extension Modules
files: cursesbug.py
messages: 65626
nosy: fer_perez
severity: normal
status: open
title: curses
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10059/cursesbug.py

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

From report at bugs.python.org  Sat Apr 19 14:41:34 2008
From: report at bugs.python.org (Christoph Schneeberger)
Date: Sat, 19 Apr 2008 12:41:34 +0000
Subject: [New-bugs-announce] [issue2658] decode_header() fails on multiline
	headers
In-Reply-To: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za>
Message-ID: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za>


New submission from Christoph Schneeberger <cschnee at telemedia.ch>:

email.Header.decode_header() does not correctly deal with multiline
Headerlines.
header.py in revision 54371 (1) changes the behaviour, whereas
previously multiline headers where parsed correctly, header.py 54371
introduced a new regex part, that renders such headers invalid and they
won't be parsed as expected.
Given the following header line (doesn't matter if its parsed from a
mail or read from a string) which represents IMHO a valid RFC2047 header
line:

from email.Header import decode_header
decode_header('=?windows-1252?Q?=22M=FCller_T=22?=\r\n <T.Mueller at xxx.com>')

this will result in:
header.py (54371):
[('=?windows-1252?Q?=22M=FCller_T=22?=\r\n <T.Mueller at xxx.com>', None)]

resp. with header.py (54370):
[('"M\xfcller T"', 'windows-1252'), (' <T.Mueller at xxx.com>', None)]

Actually both seem parsed wrong, but with 54370 the result looks more
sane (the space should be IMO removed). 
Once the CRLF sequence is removed from the header it works fine and all
looks as expected:
>>> decode_header('=?windows-1252?Q?=22M=FCller_T=22?= <T.Mueller at xxx.com>')
[('"M\xfcller T"', 'windows-1252'), ('<T.Mueller at xxx.com>', None)]

This problem might or might not be related to 
- issue 1372770 
- issue 1467619

(1) http://svn.python.org/view?rev=54371&view=rev

----------
components: Library (Lib)
messages: 65630
nosy: cschnee
severity: normal
status: open
title: decode_header() fails on multiline headers
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Sat Apr 19 22:00:59 2008
From: report at bugs.python.org (Sylvain Fourmanoit)
Date: Sat, 19 Apr 2008 20:00:59 +0000
Subject: [New-bugs-announce] [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>


New submission from Sylvain Fourmanoit <syfou at users.sourceforge.net>:

The textwrap module in standard library breaks hyphenated words given
the opportunity; I don't think that's absolutely obvious from the
current doc, and it's something worth mentioning. 

Here is a short addition to the library reference guide.

Initial discussion started here:
http://mail.python.org/pipermail/stdlib-sig/2008-April/000265.html

----------
components: Library (Lib)
files: textwrap_hyphens_doc.patch
keywords: patch
messages: 65635
nosy: fourmanoit
severity: normal
status: open
title: textwrap handling of hyphenation
versions: Python 2.6
Added file: http://bugs.python.org/file10061/textwrap_hyphens_doc.patch

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

From report at bugs.python.org  Sat Apr 19 23:05:02 2008
From: report at bugs.python.org (Brandon Ehle)
Date: Sat, 19 Apr 2008 21:05:02 +0000
Subject: [New-bugs-announce] [issue2660] 2to3 throws a utf8 decode error on
	a iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>


New submission from Brandon Ehle <azverkan at gmail.com>:

While running the 2to3 script on the scons codebase, I ran into an
UnicodeDecodeError.

Attached is just the portion of the script that causes the error.

2to3 throws an error on the string regardless of whether the unicode
string literal is prepended on the front.

RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "/usr/local/bin/2to3", line 5, in <module>
    sys.exit(refactor.main())
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 81, in main
    rt.refactor_args(args)
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 188, in
refactor_args
    self.refactor_file(arg)
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 217, in
refactor_file
    input = f.read() + "\n" # Silence certain parse errors
  File "/usr/local/lib/python3.0/io.py", line 1611, in read
    decoder.decode(self.buffer.read(), final=True))
  File "/usr/local/lib/python3.0/io.py", line 1199, in decode
    output = self.decoder.decode(input, final=final)
  File "/usr/local/lib/python3.0/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 59-60:
invalid data

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3bug.py
messages: 65637
nosy: azverkan, collinwinter
severity: normal
status: open
title: 2to3 throws a utf8 decode error on a iso-8859-1 string
versions: Python 3.0
Added file: http://bugs.python.org/file10063/2to3bug.py

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

From report at bugs.python.org  Sun Apr 20 00:09:33 2008
From: report at bugs.python.org (David Anderson)
Date: Sat, 19 Apr 2008 22:09:33 +0000
Subject: [New-bugs-announce] [issue2661] Mapping tests cannot be passed by
	user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>


New submission from David Anderson <dave at natulte.net>:

Some test cases in Lib/test/mapping_tests.py are problematic for users
wishing to test their own implementations of the mapping protocol: 

 - TestHashMappingProtocol.test_repr() requires the user implementations
to look like a dict when repr() is applied. It is unclear why this is
required of conforming mapping protocol implementations.
 - TestMappingProtocol.test_fromkeys() cannot pass for any
implementation that uses its constructor in fromkeys(), because baddict1
defines a constructor accepting no arguments. It should accept *args,
**kwargs to be sane for user implementations that handle passing data
sources to the constructor.
 - TestHashMappingProtocol.test_mutatingiteration(), for some faulty
implementations, makes the iteration degrade into an infinite loop.
Making the test more strict (eg. keeping an explicit iteration count and
failing if it goes >1) would be more helpful to buggy implementations.

These all seem like trivial issues. If it is agreed that the repr_test
should be removed from the ABC tests, I can provide a patch implementing
these three corrections.

----------
components: Library (Lib)
messages: 65639
nosy: danderson
severity: normal
status: open
title: Mapping tests cannot be passed by user implementations
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Apr 20 15:30:47 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 20 Apr 2008 13:30:47 +0000
Subject: [New-bugs-announce] [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

>/* On Windows HUGE_VAL is an extern variable and not a constant. Since the
>   special value arrays need a constant we have to roll our own infinity
>   and nan. */

This patch removes this limitation.

----------
components: Extension Modules
messages: 65646
nosy: ocean-city
severity: normal
status: open
title: Allows HUGE_VAL as extern variable
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr 20 23:28:23 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 20 Apr 2008 21:28:23 +0000
Subject: [New-bugs-announce] [issue2663] shutil.copytree glob-style
	filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>


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

Here's a first draft of a small addon to shutil.copytree.

This patch allows excluding some folders or files from the copy, given
glob-style patterns. A callable can also be provided instead of the
patterns, for a more complex filtering.

I didn't upgrade Doc/shutil.rst yet in this patch, as this can be done
when the change will be accepted and in its final shape I guess.

----------
components: Library (Lib)
files: shutil.copytree.filtering.patch
keywords: patch
messages: 65652
nosy: tarek
severity: normal
status: open
title: shutil.copytree glob-style filtering [patch]
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10066/shutil.copytree.filtering.patch

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

From report at bugs.python.org  Mon Apr 21 02:42:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 21 Apr 2008 00:42:42 +0000
Subject: [New-bugs-announce] [issue2664] The position of special value
	tables (cmathmodule.c)
In-Reply-To: <1208738562.06.0.91336742493.issue2664@psf.upfronthosting.co.za>
Message-ID: <1208738562.06.0.91336742493.issue2664@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

If putting special value tables near function is preferable,
(as before) probably this patch helps.

----------
components: Extension Modules
files: cmathmodule.patch
keywords: patch
messages: 65657
nosy: ocean-city
severity: normal
status: open
title: The position of special value tables (cmathmodule.c)
versions: Python 2.6
Added file: http://bugs.python.org/file10070/cmathmodule.patch

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

From report at bugs.python.org  Mon Apr 21 10:38:14 2008
From: report at bugs.python.org (Leo)
Date: Mon, 21 Apr 2008 08:38:14 +0000
Subject: [New-bugs-announce] [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>


New submission from Leo <elescargot at hotmail.com>:

I recently upgraded from python 2.3 to 2.5. But idle doesn't launch
anymore, either with right-clicking a .py program an doing "edit with
IDLE" or with launching the idle.py file itself. 
When I launch idle with the command line, it gives the following error
several times:

Warning : configHandler.py - IdleConf.GetThemeDict- 
problem retrieving theme element 'buitlin-foreground'
from theme 'vert theme'
returning default value: '#000000'

Warning : configHandler.py - IdleConf.GetThemeDict- 
problem retrieving theme element 'buitlin-background'
from theme 'vert theme'
returning default value: '#ffffff'

----------
components: IDLE
messages: 65658
nosy: Leo
severity: normal
status: open
title: unable to launch IDLE on windows XP
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr 21 22:16:10 2008
From: report at bugs.python.org (Oleg Broytmann)
Date: Mon, 21 Apr 2008 20:16:10 +0000
Subject: [New-bugs-announce] [issue2666] webbrowser.py doesn't properly
	handle BROWSER env var
In-Reply-To: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>
Message-ID: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>


New submission from Oleg Broytmann <phd at phd.pp.ru>:

webbrowser.py ignores browsers listed in the BROWSER environment
variables if it doesn't recognize the browser. For example, if I add
"links2" to the BROWSER env var, webbrowser.py ignores it.

It is because _synthesize() doesn't know how to handle an unknown
browser. The attached patch checks if _synthesize() doesn't register a
browser and registers a GenericBrowser.

Another approach would be to register GenericBrowser in _synthesize().

----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 65665
nosy: phd
severity: normal
status: open
title: webbrowser.py doesn't properly handle BROWSER env var
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10072/webbrowser.py.patch

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

From report at bugs.python.org  Tue Apr 22 11:52:16 2008
From: report at bugs.python.org (gmarketer)
Date: Tue, 22 Apr 2008 09:52:16 +0000
Subject: [New-bugs-announce] [issue2667] Remove multiple inheritance in
	Python 3000
In-Reply-To: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>
Message-ID: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>


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

Please remove ability to multiple inheritance in Python 3000.

Multiple inheritance is bad for design, rarely used and contains many 
problems for usual users.

Every program can be designed only with single inheritance.

----------
components: None
messages: 65671
nosy: gmarketer
severity: normal
status: open
title: Remove multiple inheritance in Python 3000
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr 22 18:49:05 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Apr 2008 16:49:05 +0000
Subject: [New-bugs-announce] [issue2668] apply() documentation is slightly
	incorrect
In-Reply-To: <1208882945.04.0.253062304574.issue2668@psf.upfronthosting.co.za>
Message-ID: <1208882945.04.0.253062304574.issue2668@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Current Doc/library/functions.rst says "The use of apply() is exactly
equivalent to function(*args, **keywords)." which is no longer correct
because f(*args, **keywords) notation allows use of an arbitrary mapping
as keywords in 2.6, but apply(f, args, keywords) does not.

I don't think changing the code to allow arbitrary mapping in apply is
worth the trouble and even mentioning this difference explicitly in the
apply() docs is probably not justified.

My recommendation is to just s/exactly equivalent/equivalent/ in the
sentence quote above.

----------
assignee: georg.brandl
components: Documentation
messages: 65675
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: apply() documentation is slightly incorrect
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 22 19:52:07 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 22 Apr 2008 17:52:07 +0000
Subject: [New-bugs-announce] [issue2669] bsddb iterkeys sliently fails when
	database modified during iteration
In-Reply-To: <1208886727.18.0.175464776053.issue2669@psf.upfronthosting.co.za>
Message-ID: <1208886727.18.0.175464776053.issue2669@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

>>> db = bsddb.btopen("/tmp/n")
>>> for i in range(5):
	db[str(i)] = None
>>> db
{'1': '', '0': '', '3': '', '2': '', '4': ''}
>>> for k in db.iterkeys():
	print k
	del db[k]
0
>>> 

The Python "dict" object raises a RuntimeError when modifying the
dictionary during iteration, the database should do the same.

----------
components: Library (Lib)
messages: 65676
nosy: tebeka
severity: normal
status: open
title: bsddb iterkeys sliently fails when database modified during iteration
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 22 22:17:56 2008
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 22 Apr 2008 20:17:56 +0000
Subject: [New-bugs-announce] [issue2670] urllib2 build_opener() fails if two
	handlers use the same default base class
In-Reply-To: <1208895476.65.0.692366839984.issue2670@psf.upfronthosting.co.za>
Message-ID: <1208895476.65.0.692366839984.issue2670@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

urllib2.py:424 (Py 2.4) or urllib2.py:443 (Py 2.5) in build_opener()::

        skip = []
        for klass in default_classes:
            for check in handlers:
                if inspect.isclass(check):
                    if issubclass(check, klass):
                        skip.append(klass)
                elif isinstance(check, klass):
                    skip.append(klass)
        for klass in skip:
           default_classes.remove(klass)

This can cause klass to be appended to skip multiple times,
which then causes an exception in the final line quoted above.

skip should be a set (and append changed to add), or "if klass
not in skip:" should be added before each "skip.append(klass)".

----------
components: Library (Lib)
messages: 65683
nosy: tlynn
severity: normal
status: open
title: urllib2 build_opener() fails if two handlers use the same default base class
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Apr 23 00:07:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Apr 2008 22:07:19 +0000
Subject: [New-bugs-announce] [issue2671] PyErr_WarnPy3k
In-Reply-To: <1208902039.11.0.586606723559.issue2671@psf.upfronthosting.co.za>
Message-ID: <1208902039.11.0.586606723559.issue2671@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

Attaching a patch that adds a PyErr_WarnPy3k function.

----------
components: Interpreter Core
files: py3kwarn_c.patch
keywords: patch
messages: 65687
nosy: benjamin.peterson, tiran
severity: normal
status: open
title: PyErr_WarnPy3k
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10076/py3kwarn_c.patch

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

From report at bugs.python.org  Wed Apr 23 04:44:44 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Wed, 23 Apr 2008 02:44:44 +0000
Subject: [New-bugs-announce] [issue2672] speed of set.update([])
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>


New submission from John Arbash Meinel <john at arbash-meinel.com>:

I was performance profiling some of my own code, and I ran into
something unexpected. Specifically,
set.update(empty_generator_expression) was significantly slower than
set.update(empty_list_expression).

I double checked my findings with timeit:

With python 2.4.3:

$ python -m timeit -s 'x = set(range(10000))' 'x.update([])'
1000000 loops, best of 3: 0.296 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update(y for y in [])'
1000000 loops, best of 3: 0.837 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update([y for y in []])'
1000000 loops, best of 3: 0.462 usec per loop

With 2.5.1 (on a different machine)
$ python -m timeit -s 'x = set(range(10000))' 'x.update([])'
1000000 loops, best of 3: 0.265 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update(y for y in [])'
1000000 loops, best of 3: 0.717 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update([y for y in []])'
1000000 loops, best of 3: 0.39 usec per loop

So generally, it is about 2x faster to create the empty list expression
and pass it in than to use an empty generator.

----------
components: Interpreter Core
messages: 65694
nosy: jameinel
severity: normal
status: open
title: speed of set.update([])
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Apr 23 07:08:34 2008
From: report at bugs.python.org (Beverley Eyre)
Date: Wed, 23 Apr 2008 05:08:34 +0000
Subject: [New-bugs-announce] [issue2673] error on optparse page
In-Reply-To: <1208927314.01.0.909798143433.issue2673@psf.upfronthosting.co.za>
Message-ID: <1208927314.01.0.909798143433.issue2673@psf.upfronthosting.co.za>


New submission from Beverley Eyre <fbe2 at comcast.net>:

There is an error (maybe a typo) on this page:
http://docs.python.org/lib/optparse-callback-example-6.html.

The last line of the example should have ->
callback=vararg_callback not callback=varargs

Not a big deal.

----------
assignee: georg.brandl
components: Documentation
messages: 65696
nosy: fbe2, georg.brandl
severity: normal
status: open
title: error on optparse page

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

From report at bugs.python.org  Wed Apr 23 15:59:47 2008
From: report at bugs.python.org (Johan Tufvesson)
Date: Wed, 23 Apr 2008 13:59:47 +0000
Subject: [New-bugs-announce] [issue2674] unittest.TestProgram uses sys.exit()
In-Reply-To: <1208959187.62.0.82904421242.issue2674@psf.upfronthosting.co.za>
Message-ID: <1208959187.62.0.82904421242.issue2674@psf.upfronthosting.co.za>


New submission from Johan Tufvesson <tuben at users.sourceforge.net>:

The class TestProgram (and its synonym "main") in module unittest is
(probably) meant to be an easy way to use the functionality of the
module unittest. It is very surprising (and error-prone) that it uses
sys.exit() with a status code instead of making a return with the same
status code.

Clean-up actions after the call to unittest.main() are not executed.

----------
components: Library (Lib)
messages: 65698
nosy: tuben
severity: normal
status: open
title: unittest.TestProgram uses sys.exit()
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr 23 17:41:40 2008
From: report at bugs.python.org (Pavel Bazant)
Date: Wed, 23 Apr 2008 15:41:40 +0000
Subject: [New-bugs-announce] [issue2675] Curses terminal resize problems
	when Python is in interactive mode
In-Reply-To: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za>
Message-ID: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za>


New submission from Pavel Bazant <maxplanck at seznam.cz>:

When python is in interactive mode, curses does not react to resize 
events properly.

test.py:

import curses

def run():
 stdscr=curses.initscr()
 key=0
 while(key!=ord('q')):
  key=stdscr.getch()
  stdscr.addstr(0,0,str(stdscr.getmaxyx())+' '+str(key))
  stdscr.refresh()
 curses.endwin()

run()

When this is run directly, everything is ok. When it is called via 
execfile() from the interactive prompt, it shows the right screen size 
after the first keypress, but behaves oddly after the resize.

IMHO, the following happens:
For some reason, env. variables LINES and COLUMNS are set but they are 
not reflected in the os.environ structure nor they respond to screen 
size changes. If these variables are set then the ncurses library (see 
man pages) uses their values instead of getting the term size via 
ioctl. 
The ncurses library receives a SIGWINCH and sees that LINES
and COLUMNS are set. However, their values are same as the
screen dimensions before the resize, so it is perplexed why there is
a SIGWINCH if the screen did not change and it just ungetchs an ERR
and ncurses internal structures are not changed appropriately.

>From the resizeterm man page:
"If the environment variables LINES or COLUMNS are set, this overrides 
the library's use of the window size obtained from the operating 
system. Thus, even if a SIGWINCH is received, no screen size change may 
be recorded. In that case, no KEY_RESIZE is queued for the next call to 
getch; an ERR will be returned instead."

Executing

import os
os.environ['LINES']="blah"
del os.environ['LINES']
os.environ['COLUMNS']="blah"
del os.environ['COLUMNS']

solves the problem for me.
Perhaps the problem has sth to do with python using readline
in interactive mode???
PB

----------
components: None
messages: 65700
nosy: pbazant
severity: normal
status: open
title: Curses terminal resize problems when Python is in interactive mode
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Wed Apr 23 19:00:17 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 23 Apr 2008 17:00:17 +0000
Subject: [New-bugs-announce] [issue2676] email/message.py
	[Message.get_content_type]: Trivial regex hangs on
	pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

[Reported by Alberto Casado Mart?n [1]]

Message.get_content_type() hangs when very large values are split by the
regex:
ctype = paramre.split(value)[0].lower().strip() #line 439

paramre comes from line 26:
paramre = re.compile(r'\s*;\s*')

Unless the full fledged parser cited in the comment before line 26 is in
the works, I suggest splitting the string by ";" to get exactly the same
behavior in a more reliable way.


[1] http://mail.python.org/pipermail/python-dev/2008-April/078840.html

----------
components: Library (Lib)
files: message.py.patch
keywords: patch
messages: 65702
nosy: ajaksu2, barry
severity: normal
status: open
title: email/message.py [Message.get_content_type]: Trivial regex hangs on pathological input
versions: Python 2.6
Added file: http://bugs.python.org/file10079/message.py.patch

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

From report at bugs.python.org  Thu Apr 24 12:01:26 2008
From: report at bugs.python.org (Ludovico Gardenghi)
Date: Thu, 24 Apr 2008 10:01:26 +0000
Subject: [New-bugs-announce] [issue2677] Argument rules in callables do not
	apply when function uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>


New submission from Ludovico Gardenghi <garden at acheronte.it>:

(It seems strange to me that this issue hasn't been raised in the past,
maybe I just failed to find it in the BTS. In that case please excuse me
and please point me to the original discussion.)

The Language Reference, section 5.3.4, states that, for every callable
object:

"[...] If keyword arguments are present, they are first converted to
positional arguments, as follows. First, a list of unfilled slots is
created for the formal parameters. [...] Next, for each keyword
argument, the identifier is used to determine the corresponding slot (if
the identifier is the same as the first formal parameter name, the first
slot is used, and so on). [...]"

This is not true if the function is defined using the C function
PyArg_ParseTuple, and this happens a lot in the standard library. I
discovered it trying to call os.open("filename", flag=os.O_RDONLY), just
to make an example. In this case it seems useless to specify the
keyword, but I have to write a generic "wrapping" function that takes a
function name and its arguments (as keyword arguments) and call the
original function after having changed the content of some of the arguments.

Apart from the reason, I believe that this behavior is inconsistent with
the language definition and should be fixed. I'm very new to Python, but
maybe the format string of ParseTuple should be extended in order to
accept also the name of the positional arguments? Or something like
ParseTupleAndKeywords should be used instead?

I tried only on Python 2.4 and 2.5 but I took a look at the source code
of 2.6 and 3.0 and I believe the issue is still there.

----------
components: Library (Lib)
messages: 65712
nosy: garden
severity: normal
status: open
title: Argument rules in callables do not apply when function uses PyArg_ParseTuple
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Apr 24 14:02:49 2008
From: report at bugs.python.org (Nikolay Kim)
Date: Thu, 24 Apr 2008 12:02:49 +0000
Subject: [New-bugs-announce] [issue2678] hmac performance optimization
In-Reply-To: <1209038569.77.0.0418872220243.issue2678@psf.upfronthosting.co.za>
Message-ID: <1209038569.77.0.0418872220243.issue2678@psf.upfronthosting.co.za>


New submission from Nikolay Kim <fafhrd91 at gmail.com>:

i removed lambda in _strxor function

----------
components: Library (Lib)
files: hmac.py.diff
keywords: patch
messages: 65720
nosy: fafhrd
severity: normal
status: open
title: hmac performance optimization
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10083/hmac.py.diff

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

From report at bugs.python.org  Thu Apr 24 15:52:20 2008
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 24 Apr 2008 13:52:20 +0000
Subject: [New-bugs-announce] [issue2679] email.feedparser regex duplicate
In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za>
Message-ID: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at users.sourceforge.net>:

feedparser defines four regexs for end-of-line, but two are redundant.

NLCRE checks for the three common line endings.
NLCRE_crack also captures the line ending.
NLCRE_eol also adds a $ to ensure it is at the end.
NLCRE_bol ... is identical to NLCRE_crack.

It should either use a ^ to insist on line-start, or be explicitly the 
same.  (e.g., NLCRE_bol=NLCRE_crack.)  (It gets away with not listing the ^ 
because the current code only uses NLCRE_bol.match.

(Actually, if the regexes are considered private, then the current code 
could just use the bound methods directly ... setting NLCRE_bol to the
 .match method, NLCRE_eol to the .search method, and NLCRE_crack to the
 .split method.)

----------
components: Library (Lib)
messages: 65723
nosy: jimjjewett
severity: normal
status: open
title: email.feedparser regex duplicate
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Apr 24 18:29:58 2008
From: report at bugs.python.org (Carlos Scheidegger)
Date: Thu, 24 Apr 2008 16:29:58 +0000
Subject: [New-bugs-announce] [issue2680] gotcha: _fields_ is final but
	accepts lists
In-Reply-To: <1209054598.56.0.869643516556.issue2680@psf.upfronthosting.co.za>
Message-ID: <1209054598.56.0.869643516556.issue2680@psf.upfronthosting.co.za>


New submission from Carlos Scheidegger <cscheid at sci.utah.edu>:

When creating ctypes.Structure classes dynamically, there's a gotcha.
_fields_ is final, but it takes a list that can be appended to. I'm not
sure this is a bug, but I would argue it is a lot more surprising than
it could be:

Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> class Foo(ctypes.Structure):
...  _fields_ = [('dim', ctypes.c_int)]
... 
>>> x = Foo()
>>> x.dim = 1
>>> x.dim = '123' # This is ok, and expected
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required
>>> 
>>> 
>>> class Bar(ctypes.Structure):
...  pass
... 
>>> x._fields_ = []
>>> x._fields_.append(('dim', ctypes.c_int))
>>> x = Bar()
>>> x.dim = '123' # This, however, is strange
>>>

This was somewhat foreseen, since _fields_ is final:

>>> class Baz(ctypes.Structure):
...  pass
... 
>>> Baz._fields_ = []
>>> Baz._fields_ = [('dim', ctypes.c_int)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: _fields_ is final

Would it not make sense for _fields_ to require a tuple, so that it
cannot be mutated? I realize this is a big change. Currently, ctypes
accepts tuples as the input to _fields_. Maybe a warning should be
issued when a list is assigned to _fields_?

----------
assignee: theller
components: ctypes
messages: 65728
nosy: cscheid, theller
severity: normal
status: open
title: gotcha: _fields_ is final but accepts lists
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 24 18:31:23 2008
From: report at bugs.python.org (Lukas Meuser)
Date: Thu, 24 Apr 2008 16:31:23 +0000
Subject: [New-bugs-announce] [issue2681] octal literals beginning with 8
	don't raise a SyntaxError
In-Reply-To: <1209054682.92.0.234885445722.issue2681@psf.upfronthosting.co.za>
Message-ID: <1209054682.92.0.234885445722.issue2681@psf.upfronthosting.co.za>


New submission from Lukas Meuser <lukas-pydev at quittenbrod.de>:

Octal literals containing an 8 or a 9 should raise a SyntaxError, but 8 ist 
accepted as the first character of such a literal (e.g., 0o8 or 0o876, but 
not 0o678). Those literals evaluate to 0.0.
The fix for this is trivial, a patch against current SVN (r62479) is 
attached.

----------
components: Interpreter Core
files: octal_literals.diff
keywords: patch
messages: 65729
nosy: lukas.meuser
severity: normal
status: open
title: octal literals beginning with 8 don't raise a SyntaxError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10085/octal_literals.diff

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

From report at bugs.python.org  Thu Apr 24 20:07:10 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 18:07:10 +0000
Subject: [New-bugs-announce] [issue2682] cyclic reference in ctypes
	CFunctionType objects
In-Reply-To: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>
Message-ID: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

Zachary Pincus posted a message about this cyclic reference in ctypes
CFunctionType objects.  The reference has the problem that these objects
are cleaned up later than expected.

The attached patch fixes this problem by removing the cyclic reference.

----------
assignee: theller
components: ctypes
files: cthunk.patch
keywords: patch
messages: 65733
nosy: theller
severity: normal
status: open
title: cyclic reference in ctypes CFunctionType objects
type: resource usage
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10086/cthunk.patch

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

From report at bugs.python.org  Thu Apr 24 20:57:20 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Thu, 24 Apr 2008 18:57:20 +0000
Subject: [New-bugs-announce] [issue2683] subprocess.Popen.communicate takes
	bytes, not str
In-Reply-To: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>
Message-ID: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

subprocess.Popen.communicate is documented as taking a string as the 
input argument. Instead is accepts only a binary stream (bytes).

Python 3.0a4 (r30a4:62126, Apr  3 2008, 15:34:18) [MSC v.1500 32 bit 
(Intel)] on
 win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> p = Popen('command.com', stdin=PIPE)
>>> p.communicate("dir\n")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python30\lib\subprocess.py", line 588, in communicate
    self.stdin.write(input)
  File "C:\Python30\lib\io.py", line 844, in write
    raise TypeError("can't write str to binary stream")
TypeError: can't write str to binary stream

----------
components: Extension Modules
messages: 65740
nosy: kermode
severity: normal
status: open
title: subprocess.Popen.communicate takes bytes, not str
versions: Python 3.0

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

From report at bugs.python.org  Thu Apr 24 21:51:29 2008
From: report at bugs.python.org (Charles Merriam)
Date: Thu, 24 Apr 2008 19:51:29 +0000
Subject: [New-bugs-announce] [issue2684] Logging Module still failing for
	%(filename)s, __init__
In-Reply-To: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>
Message-ID: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>


New submission from Charles Merriam <charles.merriam at gmail.com>:

About same as problem in 2.4 Issue1470422 closed without a test case on
MacOS X/Python 2.4.
Also same as
http://mail.python.org/pipermail/python-bugs-list/2004-July/024111.html
and so on back for years.

What happens:

chasm at chasm-laptop:~/py$ cat x.py
import logging
logging.basicConfig(level=logging.DEBUG,
                   
format="%(levelname)s:%(pathname)s:%(lineno)d:%(message)s")
from logging import debug

if __name__ == "__main__":
    debug("Hello")
chasm at chasm-laptop:~/py$ python x.py
DEBUG:logging/__init__.py:1327:Hello

What should happen:

It should print DEBUG: x.py:3:Hello

Why it fails:

Because logging guesses that the right sys._getframe(level) should be
level 3 in __init__.py:71, in currentFrame
if hasattr(sys, '_getframe'): currentframe = lambda: sys._getframe(3)

What should happen:

It shouldn't guess.  In Python 2.5, the lambda might count.  In any
case, the level is off by one (4).  I suggest that it get set by walking
up the stack from until it exits the stack frame.

----------
components: Library (Lib)
messages: 65743
nosy: CharlesMerriam
severity: normal
status: open
title: Logging Module still failing for %(filename)s, __init__
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 24 23:11:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Apr 2008 21:11:52 +0000
Subject: [New-bugs-announce] [issue2685] Add -mieee to compile flags,
	when available
In-Reply-To: <1209071512.37.0.789314022887.issue2685@psf.upfronthosting.co.za>
Message-ID: <1209071512.37.0.789314022887.issue2685@psf.upfronthosting.co.za>


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

test_math and test_cmath currently fail on Debian/alpha, apparently due to 
mishandling of subnormal numbers.  I have high hopes that this can be 
fixed by compiling with -mieee.

The attached patch modifies the configure script to always use the -mieee 
option on gcc, when available.

----------
components: Build
files: mieee.patch
keywords: patch
messages: 65750
nosy: marketdickinson
severity: normal
status: open
title: Add -mieee to compile flags, when available
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10089/mieee.patch

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

From report at bugs.python.org  Fri Apr 25 00:14:49 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 24 Apr 2008 22:14:49 +0000
Subject: [New-bugs-announce] [issue2686] Any chance we could double the
	height of the 'Comment:' text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>


New submission from Trent Nelson <tnelson at onresolve.com>:

I'd give my left arm for the comment box to be at least double its
current height.  Once you've written more than a paragraph, it becomes a
nuisance having to scroll up and down to re-read what you've written
before typing more.  Quick win?

----------
assignee: loewis
components: None
messages: 65754
nosy: Trent.Nelson, loewis
severity: normal
status: open
title: Any chance we could double the height of the 'Comment:' text area on tracker?
type: feature request

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

From report at bugs.python.org  Fri Apr 25 03:50:43 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 25 Apr 2008 01:50:43 +0000
Subject: [New-bugs-announce] [issue2687] SSL example script fails
	mysteriously on MacOS
In-Reply-To: <1209088243.37.0.693180003312.issue2687@psf.upfronthosting.co.za>
Message-ID: <1209088243.37.0.693180003312.issue2687@psf.upfronthosting.co.za>


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

On my MacOS 10.4.11 machine, the example SSL server and client in the
documentation don't work, and they fail with a mysterious error 0.  The
attached tarball contains my slightly-modified version of the scripts
and the test key/cert I'm using.  

When I run the server, and then the client, the output of the server is:

amk at amk:~/source/p/python$ ./python.exe server.py
Waiting for connection...
Connection received from ('127.0.0.1', 61915)
Traceback (most recent call last):
  File "server.py", line 16, in <module>
    certfile='cert.pem')
  File "/Users/amk/source/p/python/Lib/ssl.py", line 466, in wrap_socket
    ssl_version=ssl_version, ca_certs=ca_certs)
  File "/Users/amk/source/p/python/Lib/ssl.py", line 103, in __init__
    cert_reqs, ssl_version, ca_certs)
ssl.SSLError: [Errno 8] _ssl.c:429: EOF occurred in violation of protocol

And the client is:
amk at amk:~/source/p/python$ ./python.exe client.py
Traceback (most recent call last):
  File "client.py", line 10, in <module>
    ssl_sock.connect(('', 9000))
  File "/Users/amk/source/p/python/Lib/ssl.py", line 204, in connect
    self.ca_certs)
ssl.SSLError: [Errno 0] _ssl.c:327: error:00000000:lib(0):func(0):reason(0)
amk at amk:~/source/p/python$ 

The error 0 is very puzzling.

Perhaps I generated the key and cert incorrectly, and parsing them is
failing in this strange way?

----------
assignee: janssen
components: Extension Modules
files: ssl-example.tgz
messages: 65770
nosy: akuchling, janssen
priority: high
severity: normal
status: open
title: SSL example script fails mysteriously on MacOS
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10102/ssl-example.tgz

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

From report at bugs.python.org  Fri Apr 25 14:10:59 2008
From: report at bugs.python.org (Robert Greimel)
Date: Fri, 25 Apr 2008 12:10:59 +0000
Subject: [New-bugs-announce] [issue2688] Error when nesting many while loops
In-Reply-To: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>
Message-ID: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>


New submission from Robert Greimel <rgreimel at gmail.com>:

nesting 20 while loops works OK.
The 21st leads to the cryptic error message

python: Python/compile.c:295: PyAST_Compile: Assertion `co ||
PyErr_Occurred()' failed.
Abort

when trying to execute the script.

----------
components: None
messages: 65778
nosy: rgreimel
severity: normal
status: open
title: Error when nesting many while loops
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr 25 16:08:36 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 14:08:36 +0000
Subject: [New-bugs-announce] [issue2689] Fix indentation in range_item
Message-ID: <1209132516.74.0.59293636973.issue2689@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: Interpreter Core
files: range.diff
keywords: patch
nosy: belopolsky
severity: normal
status: open
title: Fix indentation in range_item
versions: Python 3.0
Added file: http://bugs.python.org/file10104/range.diff

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

From report at bugs.python.org  Fri Apr 25 17:32:02 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 15:32:02 +0000
Subject: [New-bugs-announce] [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch makes range objects precompute their length on creation.  
This speeds up indexing and len at the expense of a small increase in 
range object size.  The main benefit, however is that unsupported length > 
sys.maxsize is detected early and confusing OverflowError from len(r) or 
r[i] is avoided.

See discussion starting at http://mail.python.org/pipermail/python-
3000/2008-April/013225.html .

----------
components: Interpreter Core
files: range-length.diff
keywords: patch
messages: 65786
nosy: belopolsky
severity: normal
status: open
title: Precompute range length
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file10107/range-length.diff

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

From report at bugs.python.org  Fri Apr 25 18:03:10 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:03:10 +0000
Subject: [New-bugs-announce] [issue2691] Document size_t related long object
	APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch adds documentation for the new in 2.5 APIs:

PyObject* PyLong_FromSsize_t(Py_ssize_t v)
PyObject* PyLong_FromSize_t(size_t v)

and

Py_ssize_t PyLong_AsSsize_t(PyObject *pylong)

----------
assignee: georg.brandl
components: Documentation
messages: 65788
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: Document size_t related long object APIs
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Apr 25 19:14:49 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Apr 2008 17:14:49 +0000
Subject: [New-bugs-announce] [issue2692] bytes object wrongly exposes
	writeable buffer interface
In-Reply-To: <1209143688.91.0.550204497514.issue2692@psf.upfronthosting.co.za>
Message-ID: <1209143688.91.0.550204497514.issue2692@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

IIUC, the bytes object should be immutable (in contrast to bytearray). 
But PyObject_FromWriteBuffer() does not fail.

It seems that the attached patch fixes it; however there are lots of
failures in the testsuite with the patch - even 'memoryview(b"abcd")' fails.

Index: stringobject.c
===================================================================
--- stringobject.c	(revision 62498)
+++ stringobject.c	(working copy)
@@ -966,7 +966,7 @@
 string_buffer_getbuffer(PyStringObject *self, Py_buffer *view, int flags)
 {
 	return PyBuffer_FillInfo(view, (void *)self->ob_sval, Py_SIZE(self),
-				 0, flags);
+				 1, flags);
 }
 
 static PySequenceMethods string_as_sequence = {

----------
components: Interpreter Core
messages: 65796
nosy: theller
severity: normal
status: open
title: bytes object wrongly exposes writeable buffer interface
versions: Python 3.0

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

From report at bugs.python.org  Sat Apr 26 01:36:27 2008
From: report at bugs.python.org (Greg Couch)
Date: Fri, 25 Apr 2008 23:36:27 +0000
Subject: [New-bugs-announce] [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>


New submission from Greg Couch <gregcouch at gmail.com>:

IDLE and Tk 8.5 don't well work together for both Python 2.5 and 2.6a
(SVN version).  The reasons are related but different.

In Python 2.5, you can't select any text in the IDLE window and whenever
a calltip is to appear, you get a backtrace ending with "invalid literal
for int() with base 10: '(72,'".  That comes from an interaction between
WidgetRedirector's dispatch function and _tkinter.  The Text widget's
bbox method returns a tuple of ints, the dispatch function isn't
monitoring bbox, so it returns the tuple as is to _tkinter, where
PythonCmd converts the tuple to a Python string, not a Tcl list, so when
Tkinter sees the string, it can't convert to a tuple.

The Python "2.6a2" SVN version of _tkinter fixes that bug but exposes
others (Ikinter.py, tupleobject.c), so I've attached a simple patch for
Python 2.5.  The SVN version of idle appears to work, so this patch
should only be on the 2.5 branch.

----------
components: IDLE, Tkinter
files: Python-2.5.2-idlelib.patch
keywords: patch
messages: 65828
nosy: gregc
severity: normal
status: open
title: IDLE  doesn't work with Tk 8.5
versions: Python 2.5
Added file: http://bugs.python.org/file10112/Python-2.5.2-idlelib.patch

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

From report at bugs.python.org  Sat Apr 26 06:18:43 2008
From: report at bugs.python.org (Cournapeau David)
Date: Sat, 26 Apr 2008 04:18:43 +0000
Subject: [New-bugs-announce] [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

Hi,

I wanted to build a msi using the build_msi distutils command for one of
my package, but at some point, it fails, at the function make_id, at
line 177 in mstlib/__init__.py, for a file named aixc++.py. The regex
indeed refuses any character which is not alphanumeric: is msi itself
really that strict, or could this check be relaxed ?

----------
components: Windows
messages: 65834
nosy: cdavid
severity: normal
status: open
title: msilib file names check too strict ?
type: feature request
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 26 10:47:18 2008
From: report at bugs.python.org (david reid)
Date: Sat, 26 Apr 2008 08:47:18 +0000
Subject: [New-bugs-announce] [issue2695] Ignore case when checking algorithm
	in urllib2
In-Reply-To: <1209199638.72.0.800736981101.issue2695@psf.upfronthosting.co.za>
Message-ID: <1209199638.72.0.800736981101.issue2695@psf.upfronthosting.co.za>


New submission from david reid <mail at david-reid.com>:

Small change to allow get_algorithm_impls to correctly detect when lower
case algorithm strings are passed. I recently ran into a server that
sent 'md5' and so this function failed without this small change.

    def get_algorithm_impls(self, algorithm):
        # lambdas assume digest modules are imported at the top level
        if algorithm.lower() == 'md5':
            H = lambda x: hashlib.md5(x).hexdigest()
        elif algorithm.lower() == 'sha':
            H = lambda x: hashlib.sha1(x).hexdigest()
        ...

----------
components: Library (Lib)
messages: 65836
nosy: zathras
severity: normal
status: open
title: Ignore case when checking algorithm in urllib2
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 26 12:07:34 2008
From: report at bugs.python.org (ThurnerRupert)
Date: Sat, 26 Apr 2008 10:07:34 +0000
Subject: [New-bugs-announce] [issue2696] unicode string does not get freed
	--> memory leak?
In-Reply-To: <1209204453.97.0.209118835087.issue2696@psf.upfronthosting.co.za>
Message-ID: <1209204453.97.0.209118835087.issue2696@psf.upfronthosting.co.za>


New submission from ThurnerRupert <rupert.thurner at credit-suisse.com>:

is it possible that str and unicode str are treated differently, i.e.
unicode str does not give memory back? jonas borgstr?m noticed the
following behaviour:

>>> resident_size()
3780
>>> a = ["%i" % i for i in xrange(2**22)]
>>> resident_size()
239580
>>> del a
>>> resident_size()

4128    <-- Most memory returned to the os
>>> a = [u"%i" % i for i in xrange(2**22)]
>>> resident_size()
434532
>>> del a
>>> resident_size()R

401760  <-- Almost nothing returned to the os 


for details see
http://groups.google.com/group/trac-dev/browse_thread/thread/9de74e1d2f62e2ed.

----------
messages: 65837
nosy: ThurnerRupert
severity: normal
status: open
title: unicode string does not get freed --> memory leak?
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 26 15:46:37 2008
From: report at bugs.python.org (andrew cooke)
Date: Sat, 26 Apr 2008 13:46:37 +0000
Subject: [New-bugs-announce] [issue2697] Logging ancestors ignored after
	configuration
In-Reply-To: <1209217597.75.0.0893619687269.issue2697@psf.upfronthosting.co.za>
Message-ID: <1209217597.75.0.0893619687269.issue2697@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

I am seeing some odd behaviour with logging which would be explained
if loggers that are not defined explicitly (but which are controlled
via their ancestors) must be created after the logging system is
configured via fileConfig().

That's a bit abstract, so here's the problem itself:  I define my log
within a module by doing

import logging
log = logging.getLogger(__name__)

Now typically __name__ will be something like "acooke.utils.foo".

That happens before the application configures logging, which it does
by calling logging.config.fileConfig() to load a configuration.

If I do that, then I don't see any logging output from
"acooke.utils.foo" (when using "log" from above after "fileConfig" has
been called) unless I explicitly define a logger with that name.
Neither root nor an "acooke" logger, defined in the config file, are
called.

One way to handle this is to make creation of module-level Loggers
lazy, and make sure that logging initialisation occurs before any
other logging is actually used (which is not so hard - just init log
at the start of the application).

Of course, there's a performance hit...

For example:

class Log(object):
    def __init__(self, name):
        super(Log, self).__init__()
        self._name = name
        self._lazy = None
    def __getattr__(self, key):
        if not self._lazy:
            self._lazy = logging.getLogger(self._name)
        return getattr(self._lazy, key)

and then, in some module:

from acooke.util.log import Log
log = Log(__name__)
[...]
class Foo(object):
    def my_method(self):
        log.debug("this works as expected")

----------
components: Library (Lib)
messages: 65843
nosy: acooke
severity: normal
status: open
title: Logging ancestors ignored after configuration
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 26 19:20:24 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sat, 26 Apr 2008 17:20:24 +0000
Subject: [New-bugs-announce] [issue2698] Extension module build fails for
	MinGW: missing vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

Python 2.6a2 on Windows XP

Distutils fails to build an extension module for MinGW. Even though 
mingw32 is specified as the compiler distutils.msvc9compiler is still 
loaded and it cannot find vcvarsall.bat. Here is an example:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

[snip]

C:\pygame\ext>path=%path%;C:\python26;C:\mingw\bin

C:\pygame\ext>set MINGW_ROOT_DIRECTORY=C:\mingw

C:\pygame\ext>python setup.py build --compiler=mingw32
running build
running build_ext
error: None

C:\pygame\ext>python setup.py build_ext --compiler=mingw32
Traceback (most recent call last):
  File "setup.py", line 6, in <module>
    ext_modules=[Extension('simple', ['simple.c',]),],
  File "C:\python26\lib\distutils\core.py", line 137, in setup
    ok = dist.parse_command_line()
  File "C:\python26\lib\distutils\dist.py", line 459, in 
parse_command_line
    args = self._parse_command_opts(parser, args)
  File "C:\python26\lib\distutils\dist.py", line 517, in 
_parse_command_opts
    cmd_class = self.get_command_class(command)
  File "C:\python26\lib\distutils\dist.py", line 836, in 
get_command_class
    __import__ (module_name)
  File "C:\python26\lib\distutils\command\build_ext.py", line 21, in 
<module>
    from distutils.msvccompiler import get_build_version
  File "C:\python26\lib\distutils\msvccompiler.py", line 658, in 
<module>
    from distutils.msvc9compiler import MSVCCompiler
  File "C:\python26\lib\distutils\msvc9compiler.py", line 286, in 
<module>
    VC_ENV = query_vcvarsall(VERSION, ARCH)
  File "C:\python26\lib\distutils\msvc9compiler.py", line 253, in 
query_vcvarsall
    raise IOError("Unable to find vcvarsall.bat")
IOError: Unable to find vcvarsall.bat

C:\pygame\ext>type setup.py
from distutils.core import setup, Extension

setup(name='Simple',
      version='1.0',
      description='Python extension module test',
      ext_modules=[Extension('simple', ['simple.c',]),],
      )


C:\pygame\ext>gcc --version
gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


C:\pygame\ext>python -V
Python 2.6a2

----------
components: Distutils
messages: 65850
nosy: kermode
severity: normal
status: open
title: Extension module build fails for MinGW: missing vcvarsall.bat
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr 27 01:17:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Apr 2008 23:17:39 +0000
Subject: [New-bugs-announce] [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>


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

The new warnings implementation tweaks how tracebacks are printed. This 
introduced a bug where the exception name is indented when it shouldn't 
be: e.g., ``raise KeyError`` should look like::

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  KeyError

not::

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
      KeyError

----------
assignee: brett.cannon
components: Interpreter Core
messages: 65855
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Exception name improperly indented
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr 27 03:09:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 01:09:02 +0000
Subject: [New-bugs-announce] [issue2700] document PyNumber_ToBase
In-Reply-To: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>
Message-ID: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

Including a patch.

----------
assignee: georg.brandl
components: Documentation
files: tobase_doc.patch
keywords: patch
messages: 65860
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: document PyNumber_ToBase
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10118/tobase_doc.patch

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

From report at bugs.python.org  Sun Apr 27 04:59:51 2008
From: report at bugs.python.org (Roy Smith)
Date: Sun, 27 Apr 2008 02:59:51 +0000
Subject: [New-bugs-announce] [issue2701] csv.reader accepts string instead
	of file object (duck typing gone bad)
In-Reply-To: <1209265191.29.0.100156108517.issue2701@psf.upfronthosting.co.za>
Message-ID: <1209265191.29.0.100156108517.issue2701@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

If you pass csv.reader() a filename as its first argument:

  csv.reader('filename')

instead of a file object like you're supposed to, you don't get an error.  
You instead get a reader object which returns the characters which make up 
the filename.

Technically, this is not a bug, since the documentation says, "csvfile can 
be any object which supports the iterator protocol and returns a string 
each time its next method is called", and a string meets that definition.  
Still, this is unexpected behavior, and is almost certainly not what the 
user intended.  It would be useful if a way could be devised to catch this 
kind of mistake.

----------
components: Library (Lib)
messages: 65871
nosy: roysmith
severity: normal
status: open
title: csv.reader accepts string instead of file object (duck typing gone bad)
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Apr 27 09:53:09 2008
From: report at bugs.python.org (Daniel Darabos)
Date: Sun, 27 Apr 2008 07:53:09 +0000
Subject: [New-bugs-announce] [issue2702] pickling of large recursive
	structures crashes cPickle
In-Reply-To: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>
Message-ID: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>


New submission from Daniel Darabos <darabos.daniel at gmail.com>:

The documentation[1] says:

  Trying to pickle a highly recursive data structure may exceed the
  maximum recursion depth, a RuntimeError will be raised in this
  case. You can carefully raise this limit with sys.setrecursionlimit().

The lightweight pickle module handles this problem correctly (in that it
raises a RuntimeError), but cPickle sometimes raises KeyError instead,
or just silently terminates the interpreter (=crashes). (I have not been
able to pinpoint what it depends on. In the attached example I get
silent termination, but if instead of lists I use sets to describe the
connections, I get the RuntimeError.)

This was mentioned in issue 2480, but that has now been changed to a
feature request to eliminate recursion altogether. That may have a lower
priority, but this crash can be hard to diagnose in a complex
application, and I am not sure if sys.setrecursionlimit() affects
cPickle behavior (I guess not).

[1]: http://docs.python.org/lib/node317.html

----------
components: Library (Lib)
files: bugdemo.py
messages: 65876
nosy: alexandre.vassalotti, bkline, cyhawk, jcea, schmir
severity: normal
status: open
title: pickling of large recursive structures crashes cPickle
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10119/bugdemo.py

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

From report at bugs.python.org  Sun Apr 27 11:56:36 2008
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 27 Apr 2008 09:56:36 +0000
Subject: [New-bugs-announce] [issue2703] SimpleXMLRPCDispatcher.__init__ is
	not python2.4-backward-compatible
In-Reply-To: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>
Message-ID: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>


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

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

"SimpleXMLRPCDispatcher.__init__ used to take a single argument
(self) in python2.4 and now it takes three. The two new arguments
need to get default values or else this breaks backwards
compatibility badly."

while SimpleXMLRPCDispatcher is not described as part of the interface,
it is mentioned in the docs. The fix seems to be easy. Ok for trunk and
the branch?

----------
components: Library (Lib)
files: dispatcher.diff
keywords: patch, patch
messages: 65883
nosy: doko
severity: normal
status: open
title: SimpleXMLRPCDispatcher.__init__ is not python2.4-backward-compatible
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10120/dispatcher.diff

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

From report at bugs.python.org  Sun Apr 27 20:02:40 2008
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 27 Apr 2008 18:02:40 +0000
Subject: [New-bugs-announce] [issue2704] IDLE: Patch to make PyShell behave
	more like a Terminal interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

See attached diff file. Patching PyShell.py Version 1.2.1

PyShell ignores letter/number key presses when the cursor is not on the
command line. Instead it should redirect any letter/number key presses
to the command line. (Changed ModifiedUndoDelegator)

Also, up/down arrow presses should scroll through history when the
cursor is on the command line. But when the cursor is not on the command
line, the arrow keys should move around the PyShell window. (Added new
bindings with conditional logic)

----------
components: IDLE
files: patch_PyShell.py
messages: 65888
nosy: serwy
severity: normal
status: open
title: IDLE: Patch to make PyShell behave more like a Terminal interface
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10124/patch_PyShell.py

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

From report at bugs.python.org  Sun Apr 27 21:08:54 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 27 Apr 2008 19:08:54 +0000
Subject: [New-bugs-announce] [issue2705] incompatible change to
	warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>


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

In Python 2.5 and earlier, the `showwarning? function in the `warnings?
module has this signature:

  def showwarning(message, category, filename, lineno, file=None):

In trunk (and presumably what will become Python 2.6), this has become:

  def showwarning(message, category, filename, lineno, file=None,
line=None):

`showwarning? is documented as a hook which libraries or applications
may override in order to control how warnings are reported.  The
addition of a new parameter to the function and the change to related
code to call it with an argument for that new parameter means that
libraries and applications which replaced it will not work without
modification on Python 2.6.  Instead, a `TypeError? will be raised when
a warning is emitted.

I suggest restoring the previous signature for `showwarning? and adding
a new (perhaps preferred) API for showing a warning with the extra
information available.  It may also make sense to emit a deprecation
warning when an overridden old-style `showwarning? is found.

----------
components: Library (Lib)
messages: 65894
nosy: exarkun
severity: normal
status: open
title: incompatible change to warnings.showwarning
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Apr 27 23:04:07 2008
From: report at bugs.python.org (webograph)
Date: Sun, 27 Apr 2008 21:04:07 +0000
Subject: [New-bugs-announce] [issue2706] datetime: define division
	timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>


New submission from webograph <webograph at eml.cc>:

i suggest that division be defined for timedelta1/timedelta2, in that
sense that it gives how many times timedelta2 fits in timedelta1 (ie the
usual meaning of division), using integer arithmetics for floor division
(//) and returning float for truediv (/ after `from __future__ import
division`)

use case
--------

aside from the obvious how-many-times-does-a-fit-into-b, this solves the
issue of having individual methods for conversion to a number of
seconds, hours, days or nanocenturies (as described in #1673409).
example:

from datetime import timedelta
duration = timedelta(hours=1.5, seconds=20)
print "Until the time is up, you can listen to 'We will rock you' %d
times."%(duration//timedelta(minutes=5, seconds=3))
import time
time.sleep(duration/timedelta(seconds=1))


history
-------

this issue follows a discussion on python-list, re-initiated by [1].

there have previously been similar feature requests on datetime, most of
which have been rejected due to ambiguities (e.g. [2]), conflicts with
time_t or issues with time zones.

the only issue i've seen that can be relevant here is the
integer-vs-float discussion, which is here handled by floordiv (//) and
truediv.

patch
-----

i've written a patch against svn trunk revision 62520.

it uses function pointers to reduce code duplication; in case this
inappropriate here, i also have a pointerless version.

i familiar with c but not experienced, especially with the python ways
of writing c. most of the code is just adapted from other functions in
the same files, so it is probably, but should nevertheless checked with
special care.

i've also added test, but am not sure what has to be tested and what not.


compatibility
-------------

only cases in which division would fail without the patch are changed.
this will be a problem if (and only if) someone divides unknown objects
and waits for TypeError to be raised.
such behavior is probably rare.


[1] <mid:4813CD56.40800 at eml.cc>,
http://mail.python.org/pipermail/python-list/2008-April/488406.html
[2] http://mail.python.org/pipermail/python-dev/2002-March/020604.html

----------
components: Library (Lib)
files: datetime_datetime_division.patch
keywords: patch
messages: 65902
nosy: webograph
severity: normal
status: open
title: datetime: define division timedelta/timedelta
type: feature request
Added file: http://bugs.python.org/file10126/datetime_datetime_division.patch

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

From report at bugs.python.org  Mon Apr 28 08:43:14 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Mon, 28 Apr 2008 06:43:14 +0000
Subject: [New-bugs-announce] [issue2707] Tiny fix for os.walk docstring
In-Reply-To: <1209364994.21.0.532528115565.issue2707@psf.upfronthosting.co.za>
Message-ID: <1209364994.21.0.532528115565.issue2707@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

os.walk.__doc__ has the following example-line (os.py, line 271):
  for root, dirs, files in walk('python/Lib/email'):

it should be os.walk

----------
components: Library (Lib)
messages: 65911
nosy: Yinon
severity: normal
status: open
title: Tiny fix for os.walk docstring
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr 28 16:10:41 2008
From: report at bugs.python.org (Kristian Lauridsen)
Date: Mon, 28 Apr 2008 14:10:41 +0000
Subject: [New-bugs-announce] [issue2708] IDLE subprocess error
In-Reply-To: <1209391841.34.0.293801648559.issue2708@psf.upfronthosting.co.za>
Message-ID: <1209391841.34.0.293801648559.issue2708@psf.upfronthosting.co.za>


New submission from Kristian Lauridsen <diablos_pitbull at hotmail.com>:

Hi all.
I'w been looking for an answer to this. 
If I use IDLE for som "just fore fun" programming and then exit, I have 
to "kill" IDLE, dispite theres nothin "running" persay, then when i 
start IDLE again I get too error messages popping up:

1: Socket Error: Connection refused
2: IDLE's subprocess didn't make connection. Either IDLE can't start a 
subprocess or personal firewall is blocking the connection.

The code written in IDLE that triggers the problem can be something 
simple like:
>>> a = 'hello world'
>>> print a

I have to reboot to get past the error.
I'm only getting the error when running vista and xp theres no problom 
in any of the other systems i'v tried (mainly linux)
I should mention that the error dosn't come every time I "kill" IDLE, I 
would say about every 3rd run, or there about.
I'v tried removeing/killing windows owen firewall and then running IDLE 
but with the same result.
Like I said, i been look around fore a "fix" fore this but havent found 
any...
If I have made a "double post" please let me know and remove this 
post....

----------
components: IDLE
messages: 65918
nosy: Kris
severity: normal
status: open
title: IDLE subprocess error
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr 28 18:33:15 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 28 Apr 2008 16:33:15 +0000
Subject: [New-bugs-announce] [issue2709] tk.rst possibly wrong ?
In-Reply-To: <1209400395.54.0.768474211008.issue2709@psf.upfronthosting.co.za>
Message-ID: <1209400395.54.0.768474211008.issue2709@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

tk.rst tells, among other things:

"`Tkinter`'s chief virtues are that it is fast, and that it usually comes
bundled with Python. Although it has been used to create some very good
applications,  including IDLE, it has weak documentation ..."

Why does it say Tkinter has weak documentation ? There is a printed book
("Python and Tkinter Programming"), several online tutorials and
references, there is a wiki too, the mail list and possibly something
else I've missed.

----------
assignee: georg.brandl
components: Documentation
messages: 65922
nosy: georg.brandl, gpolo
severity: normal
status: open
title: tk.rst possibly wrong ?
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Apr 28 21:44:53 2008
From: report at bugs.python.org (Don Hanlen)
Date: Mon, 28 Apr 2008 19:44:53 +0000
Subject: [New-bugs-announce] [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>


New submission from Don Hanlen <dhanlen at owt.com>:

IDLE internal error in runcode()
Traceback (most recent call last):
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 235, in asyncqueue
    self.putmessage((seq, request))
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 332, in putmessage
    n = self.sock.send(s[:BUFSIZE])
error: (10035, 'The socket operation could not complete without blocking')

Does this look familiar to anyone?  I can't figure out what to do about
it.  Python 2.5, windoze.  I get it when I execute a Tkinter op that
works elsewhere.

changing this (works):

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    width = self.checkerSize)

to

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    font=("Times", str(self.checkerSize/2), "bold"),
    width = self.checkerSize)

for example.  The same code works fine elsewhere.  I thought I'd ask
here before I try (no clue) increasing BUFSIZE in rpc.py?  I'm not crazy
about tinkering with code I have no clue about..

It has been suggested that the problem is competition with IDLE for
tkinter resources.

-- 

don

----------
files: tkinterwork.py
messages: 65928
nosy: dhanlen
severity: normal
status: open
title: error: (10035, 'The socket operation could not complete without blocking')
versions: Python 2.5
Added file: http://bugs.python.org/file10133/tkinterwork.py

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

From report at bugs.python.org  Mon Apr 28 21:44:52 2008
From: report at bugs.python.org (Don Hanlen)
Date: Mon, 28 Apr 2008 19:44:52 +0000
Subject: [New-bugs-announce] [issue2711] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411892.21.0.718182356449.issue2711@psf.upfronthosting.co.za>
Message-ID: <1209411892.21.0.718182356449.issue2711@psf.upfronthosting.co.za>


New submission from Don Hanlen <dhanlen at owt.com>:

IDLE internal error in runcode()
Traceback (most recent call last):
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 235, in asyncqueue
    self.putmessage((seq, request))
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 332, in putmessage
    n = self.sock.send(s[:BUFSIZE])
error: (10035, 'The socket operation could not complete without blocking')

Does this look familiar to anyone?  I can't figure out what to do about
it.  Python 2.5, windoze.  I get it when I execute a Tkinter op that
works elsewhere.

changing this (works):

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    width = self.checkerSize)

to

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    font=("Times", str(self.checkerSize/2), "bold"),
    width = self.checkerSize)

for example.  The same code works fine elsewhere.  I thought I'd ask
here before I try (no clue) increasing BUFSIZE in rpc.py?  I'm not crazy
about tinkering with code I have no clue about..

It has been suggested that the problem is competition with IDLE for
tkinter resources.

-- 

don

----------
files: tkinterwork.py
messages: 65929
nosy: dhanlen
severity: normal
status: open
title: error: (10035, 'The socket operation could not complete without blocking')
versions: Python 2.5
Added file: http://bugs.python.org/file10132/tkinterwork.py

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

From report at bugs.python.org  Mon Apr 28 23:01:21 2008
From: report at bugs.python.org (ndbecker)
Date: Mon, 28 Apr 2008 21:01:21 +0000
Subject: [New-bugs-announce] [issue2712] enhanced ioctl
In-Reply-To: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>
Message-ID: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>


New submission from ndbecker <ndbecker2 at gmail.com>:

IIUC, current ioctl is not capable of handling arbitrary argument 
types.
This code will allow any arg type (such as structures with pointers to
embedded structures).

The code for _IOC is taken from linux and might not be portable.import 

-----
from ctypes import *

libc = CDLL ('/lib/libc.so.6')
#print libc.ioctl

def set_ioctl_argtype (arg_type):
    libc.ioctl.argtypes = (c_int, c_int, arg_type)

IOC_WRITE = 0x1

_IOC_NRBITS=	8
_IOC_TYPEBITS=	8
_IOC_SIZEBITS=	14
_IOC_DIRBITS=	2

_IOC_NRSHIFT=	0
_IOC_TYPESHIFT=	(_IOC_NRSHIFT+_IOC_NRBITS)
_IOC_SIZESHIFT=	(_IOC_TYPESHIFT+_IOC_TYPEBITS)
_IOC_DIRSHIFT=	(_IOC_SIZESHIFT+_IOC_SIZEBITS)


def IOC (dir, type, nr, size):
    return (((dir)  << _IOC_DIRSHIFT) | \
	 ((type) << _IOC_TYPESHIFT) | \
	 ((nr)   << _IOC_NRSHIFT) | \
	 ((size) << _IOC_SIZESHIFT))

def ioctl (fd, request, args):
    return libc.ioctl (fd, request, args)
----

Example (not complete):
class eos_dl_args_t (Structure):
    _fields_ = [("length", c_ulong),
                ("data", c_void_p)]

args = eos_dl_args_t()
args.length = len (c)
args.data = cast (pointer (c), c_void_p)

from eioctl import *

set_ioctl_argtype (POINTER (eos_dl_args_t))

EOS_IOC_MAGIC = 0xF4
request = IOC(IOC_WRITE, EOS_IOC_MAGIC, 0x00, 0) # ignore size

err = ioctl (fd, request, args)

----------
components: Extension Modules
messages: 65933
nosy: ndbecker
severity: normal
status: open
title: enhanced ioctl
type: feature request

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

From report at bugs.python.org  Mon Apr 28 23:42:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Apr 2008 21:42:55 +0000
Subject: [New-bugs-announce] [issue2713] Py3k warn on unicode escapes in raw
	strings
In-Reply-To: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>
Message-ID: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch gives a Py3k warning when a unicode escape occurs in a raw
unicode string.

----------
components: Unicode
files: unicode_escape_warn.patch
keywords: patch
messages: 65936
nosy: benjamin.peterson
severity: normal
status: open
title: Py3k warn on unicode escapes in raw strings
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10134/unicode_escape_warn.patch

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

From report at bugs.python.org  Tue Apr 29 01:23:00 2008
From: report at bugs.python.org (Gregory Dai)
Date: Mon, 28 Apr 2008 23:23:00 +0000
Subject: [New-bugs-announce] [issue2714] Unable to start IDLE on Windows
	Server 2003 x64 Edition w/ SP2
In-Reply-To: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>
Message-ID: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>


New submission from Gregory Dai <gregory.dai at gmail.com>:

Installed 2.5.2 Intel msi on
Windows Server 2003 Standard x64 Edition w/ SP2
on
Intel Xeon CPU 3.2GHz, 8GB of RAM

Selected IDLE from its startup menu item, but it refused to started.
Tried several times w/ the same outcome.

----------
components: IDLE
messages: 65943
nosy: qgd000
severity: normal
status: open
title: Unable to start IDLE on Windows Server 2003 x64 Edition w/ SP2
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 29 02:08:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Apr 2008 00:08:07 +0000
Subject: [New-bugs-announce] [issue2715] Remove carbon-specific code from
	binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>


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

There is carbon-specific code in binhex. It really should go so that the 
module is completely platform-independent. This is especially pertinent 
for 3.0 as all Mac-specific modules are slated to go.

----------
components: Library (Lib)
messages: 65947
nosy: brett.cannon
priority: high
severity: normal
status: open
title: Remove carbon-specific code from binhex
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 29 02:22:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Apr 2008 00:22:50 +0000
Subject: [New-bugs-announce] [issue2716] Reimplement audioop because of
	copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>


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

The audioop module contains a comment that is somewhat troubling from an 
IP standpoint:

  /* Code shamelessly stolen from sox, 12.17.7, g711.c
   ** (c) Craig Reese, Joe Campbell and Jeff Poskanzer 1989 */

Because of this it would be best to remove the current module and re-
implement it from scratch (or remove it entirely).

----------
components: Library (Lib)
messages: 65948
nosy: brett.cannon
priority: high
severity: normal
status: open
title: Reimplement audioop because of copyright issues
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr 29 04:11:28 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Apr 2008 02:11:28 +0000
Subject: [New-bugs-announce] [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

On python-dev Guido lamented the fact that tempfile.mkstemp()
returns a file descriptor instead of a file object.  This
patch adds tempfile.mkstempf to remedy that.

----------
components: Library (Lib)
files: mkstempf.diff
keywords: easy, patch, patch
messages: 65951
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: tempfile.mkstempf
versions: Python 2.6
Added file: http://bugs.python.org/file10136/mkstempf.diff

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

From report at bugs.python.org  Tue Apr 29 17:08:36 2008
From: report at bugs.python.org (Jeroen van der Ham)
Date: Tue, 29 Apr 2008 15:08:36 +0000
Subject: [New-bugs-announce] [issue2718] Logging.basicConfig ignores level=0
In-Reply-To: <1209481716.33.0.891360600754.issue2718@psf.upfronthosting.co.za>
Message-ID: <1209481716.33.0.891360600754.issue2718@psf.upfronthosting.co.za>


New submission from Jeroen van der Ham <vdham at uva.nl>:

logging.basicConfig seems to ignore level=0:

>>> import logging
>>> logging.basicConfig(level=0)
>>> logging.getLogger().getEffectiveLevel()
30


>>> import logging
>>> logging.basicConfig(level=10)
>>> logging.getLogger().getEffectiveLevel()
10

----------
components: Library (Lib)
messages: 65969
nosy: vdham
severity: normal
status: open
title: Logging.basicConfig ignores level=0
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr 29 23:02:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Apr 2008 21:02:28 +0000
Subject: [New-bugs-announce] [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>


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

Backporting 3.0's next() builtin.

There's no change w.r.t. __next__/next, that is tracked in #2336.

----------
assignee: gvanrossum
components: Interpreter Core
files: nextbackport.diff
keywords: 26backport, patch
messages: 65980
nosy: georg.brandl, gvanrossum
priority: critical
severity: normal
status: open
title: Backport next()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10141/nextbackport.diff

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

From report at bugs.python.org  Tue Apr 29 23:42:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 21:42:06 +0000
Subject: [New-bugs-announce] [issue2720] make compiling struct be passed
	around to all ast helpers
In-Reply-To: <1209505325.8.0.542617617713.issue2720@psf.upfronthosting.co.za>
Message-ID: <1209505325.8.0.542617617713.issue2720@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch causes struct *compiling to be passed around to all of the
ast helper functions. Since most functions already take it, this makes
it more consistent as a whole. Also, the filename (from
compiling->c_filename) is needed to issue warnings with PyErr_WarnExplicit.

----------
components: Interpreter Core
files: ast_compiling_struct.patch
keywords: patch
messages: 65982
nosy: benjamin.peterson
severity: normal
status: open
title: make compiling struct be passed around to all ast helpers
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10142/ast_compiling_struct.patch

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

From report at bugs.python.org  Wed Apr 30 00:26:31 2008
From: report at bugs.python.org (Paul Winkler)
Date: Tue, 29 Apr 2008 22:26:31 +0000
Subject: [New-bugs-announce] [issue2721] unittest.makeSuite undocumented and
	"obsolete" - but what to use instead?
In-Reply-To: <1209507990.95.0.785874849779.issue2721@psf.upfronthosting.co.za>
Message-ID: <1209507990.95.0.785874849779.issue2721@psf.upfronthosting.co.za>


New submission from Paul Winkler <pw_lists at slinkp.com>:

A comment in unittest.py says "these functions should be considered
obsolete". But I've seen a lot of code in the wild still using
unittest.makeSuite(MyTestCase)... in fact it's used frequently in the
python standard library tests.

And I don't see a replacement for this use case: given a subclass of
TestCase, conveniently turn all its test* methods into a suite. How are
we supposed to do that now?

Either makeSuite should be documented, or a suitable replacement should
be provided and documented.

----------
assignee: georg.brandl
components: Documentation
messages: 65986
nosy: georg.brandl, slinkp
severity: normal
status: open
title: unittest.makeSuite undocumented and "obsolete" - but what to use instead?
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Apr 30 02:01:54 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 30 Apr 2008 00:01:54 +0000
Subject: [New-bugs-announce] [issue2722] os.getcwd fails for long path names
	on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>


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

$ python -c "print len('`pwd`'); import os; print os.getcwd()"
1174
Traceback (most recent call last):
  File "<string>", line 1, in ?
OSError: [Errno 34] Numerical result out of range
$

The getcwd man page documents the ERANGE failure and suggests that the
calling application allocate a larger buffer and try again.

----------
components: Library (Lib)
messages: 65987
nosy: exarkun
severity: normal
status: open
title: os.getcwd fails for long path names on linux
versions: Python 2.4

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

From report at bugs.python.org  Wed Apr 30 06:36:32 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 04:36:32 +0000
Subject: [New-bugs-announce] [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <guido at python.org> 
wrote:
..
>  Let's also fix __len__() so that it returns sys.{maxint,maxsize} when
>  the result doesn't fit in a Py_ssize_t.

http://mail.python.org/pipermail/python-3000/2008-April/013343.html

With attached patch given

class x:
    def __len__(self):
        return 2**100

len(x()) and len(range(2**100)) will return sys.maxsize.

----------
components: Interpreter Core
files: len.diff
keywords: patch
messages: 65989
nosy: belopolsky
severity: normal
status: open
title: Truncate __len__() at sys.maxsize
versions: Python 3.0
Added file: http://bugs.python.org/file10143/len.diff

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

From report at bugs.python.org  Wed Apr 30 10:47:48 2008
From: report at bugs.python.org (Sandeep Sabnani)
Date: Wed, 30 Apr 2008 08:47:48 +0000
Subject: [New-bugs-announce] [issue2724] Error in Python tutorial
	(http://docs.python.org/tut/node6.html)
In-Reply-To: <1209545263.37.0.933925653998.issue2724@psf.upfronthosting.co.za>
Message-ID: <1209545263.37.0.933925653998.issue2724@psf.upfronthosting.co.za>


New submission from Sandeep Sabnani <sandeepsabnani at gmail.com>:

Section 4.4 on page http://docs.python.org/tut/node6.html has a for loop
which uses the range function. However, the displayed output of that
loop is not correct. I ran the same code and got the output as follows:

3 is a prime number
4 = 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 = 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 = 2 * 4
9 is a prime number
9 = 3 * 3

Can this be corrected in the tutorial as it can be confusing for a
python newbie!

Thanks!

----------
assignee: georg.brandl
components: Documentation
messages: 65996
nosy: georg.brandl, sandeepsabnani
severity: normal
status: open
title: Error in Python tutorial (http://docs.python.org/tut/node6.html)
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr 30 14:08:08 2008
From: report at bugs.python.org (Thomas Lee)
Date: Wed, 30 Apr 2008 12:08:08 +0000
Subject: [New-bugs-announce] [issue2725] Handle ASDLSyntaxErrors gracefully
In-Reply-To: <1209557288.23.0.65253319009.issue2725@psf.upfronthosting.co.za>
Message-ID: <1209557288.23.0.65253319009.issue2725@psf.upfronthosting.co.za>


New submission from Thomas Lee <tom at vector-seven.com>:

The current code in Parser/asdl.py doesn't handle syntax errors very
well. A minor problem to be sure, since the net result is the same (i.e.
build fails), but the error message being displayed is entirely
unhelpful to the developer.

The attached patch will display the error message as was seemingly intended.

This probably affects earlier versions (including python-trunk), but I
haven't tested.

----------
components: Build
files: fix-asdl-errors.patch
keywords: patch
messages: 65999
nosy: thomas.lee
severity: normal
status: open
title: Handle ASDLSyntaxErrors gracefully
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10144/fix-asdl-errors.patch

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

From report at bugs.python.org  Wed Apr 30 16:04:15 2008
From: report at bugs.python.org (Abhik Shah)
Date: Wed, 30 Apr 2008 14:04:15 +0000
Subject: [New-bugs-announce] [issue2726] Autodoc's autoclass directive
	should include constructor docstring
In-Reply-To: <1209564254.38.0.0869277765.issue2726@psf.upfronthosting.co.za>
Message-ID: <1209564254.38.0.0869277765.issue2726@psf.upfronthosting.co.za>


New submission from Abhik Shah <abhikshah at gmail.com>:

The autoclass directive adds the class constructor's argspec to the header and shows the class docstring 
below it but doesn't add the constructor's docstring.  I usually use the class docstring to describe the 
class and the constructor's docstring to describe the constructor arguments so if the constructor argspec 
is being shown, I would expect the description of it to be included below.

Result of svn diff sphinx/ext/autodoc.py:

Index: sphinx/ext/autodoc.py
===================================================================
--- sphinx/ext/autodoc.py	(revision 62582)
+++ sphinx/ext/autodoc.py	(working copy)
@@ -154,6 +154,13 @@
     result.append(indent + '.. %s:: %s%s' % (what, qualname, args), '<autodoc>')
     result.append('', '<autodoc>')
 
+    # added by abhik (4/29/08)
+    if what == 'class':
+        initdoc = inspect.getdoc(getattr(todoc, '__init__'))
+        if initdoc:
+            docstring = docstring if docstring else ''
+            docstring += "\n" + indent + initdoc
+
     # the module directive doesn't like content
     if what != 'module':
         indent += '   '


I don't know how other people would expect autodoc to work so maybe this behavior could be controlled by 
a config param?

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 66002
nosy: abhik, georg.brandl
severity: normal
status: open
title: Autodoc's autoclass directive should include constructor docstring
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr 30 21:30:19 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 19:30:19 +0000
Subject: [New-bugs-announce] [issue2727] clarify tp_nextiter behavior in the
	C API documentation
In-Reply-To: <1209583819.19.0.371095659675.issue2727@psf.upfronthosting.co.za>
Message-ID: <1209583819.19.0.371095659675.issue2727@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

See discussion in issue2719 for details.

----------
assignee: georg.brandl
components: Documentation
files: doc-typeobj.diff
keywords: patch
messages: 66016
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: clarify tp_nextiter behavior in the C API  documentation
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10146/doc-typeobj.diff

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

From report at bugs.python.org  Wed Apr 30 23:28:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Apr 2008 21:28:44 +0000
Subject: [New-bugs-announce] [issue2728] Failing decimal doctest
In-Reply-To: <1209590924.27.0.894325194913.issue2728@psf.upfronthosting.co.za>
Message-ID: <1209590924.27.0.894325194913.issue2728@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I was removing from __future__ import with_statment in the stdlib when I
came across this disabled doctest in decimal.py:

    # The string below can't be included in the docstring until Python 2.6
    # as the doctest module doesn't understand __future__ statements
    """
    >>> from __future__ import with_statement
    >>> print getcontext().prec
    28
    >>> with localcontext():
    ...     ctx = getcontext()
    ...     ctx.prec += 2
    ...     print ctx.prec
    ...
    30
    >>> with localcontext(ExtendedContext):
    ...     print getcontext().prec
    ...
    9
    >>> print getcontext().prec
    28
    """

When it was enabled, it failed.

----------
components: Library (Lib)
messages: 66026
nosy: benjamin.peterson
severity: normal
status: open
title: Failing decimal doctest
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 30 23:57:04 2008
From: report at bugs.python.org (Manuel Kaufmann)
Date: Wed, 30 Apr 2008 21:57:04 +0000
Subject: [New-bugs-announce] [issue2729] Link error in What's New in Python
	2.6
In-Reply-To: <1209592624.39.0.481461750945.issue2729@psf.upfronthosting.co.za>
Message-ID: <1209592624.39.0.481461750945.issue2729@psf.upfronthosting.co.za>


New submission from Manuel Kaufmann <humitos at gmail.com>:

I found a link error in section "What's New in Python 2.6" to Trac 
project.

I attach the patch file

----------
assignee: georg.brandl
components: Documentation
files: patch.diff
keywords: patch
messages: 66028
nosy: georg.brandl, humitos
severity: normal
status: open
title: Link error in What's New in Python 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file10148/patch.diff

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