From report at bugs.python.org  Tue Jun  1 00:20:15 2010
From: report at bugs.python.org (Christian Schubert)
Date: Mon, 31 May 2010 22:20:15 +0000
Subject: [New-bugs-announce] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>


New submission from Christian Schubert <bugs at apexo.de>:

invoking select.poll.poll() concurrently from multiple threads frequently yields garbage in one thread:

while poll_poll in thread 1 is parsing its result, another thread 2 calling poll may overwrite revents; assuming poll_result was 1 in thread 1 and thread 2 managed to clear all revents before thread 1 started scanning ufds, thread 1 would iterate straight through all ufds, past its bounds (no bound checks there), and return the first out-of-bounds entry that happens to have revents != 0

this issue needs at least documentation (although bounds-checking to prevent garbage in the result wouldn't hurt)

also, since there doesn't seem to be any locking w/ regards to ufds, it might be possible to corrupt python's heap, by concurrently invoking poll_register and poll_poll. poll_register could move the ufds array to another location while resizing it and poll_poll would subsequently overwrite memory that is not allocated anymore or allocated by someone else (did not test that)

python 2.5.5

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 106815
nosy: apexo, docs at python
priority: normal
severity: normal
status: open
title: select.poll is not thread safe
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun  1 00:50:12 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 31 May 2010 22:50:12 +0000
Subject: [New-bugs-announce] [issue8866] socket.getaddrinfo() should support
	keyword arguments
In-Reply-To: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>
Message-ID: <1275346212.88.0.3146354655.issue8866@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As of now socket.getaddrinfo() only supports positional arguments, so that if I want to, say, specify "flags" argument I'm forced to specify "0" for other missing arguments:

>>> socket.getaddrinfo("www.python.org", 0, 0, 0, socket.SOL_TCP)
[(2, 1, 6, '', ('82.94.164.162', 0)), (10, 1, 6, '', ('2001:888:2000:d::a2', 0, 0, 0))]
>>>
>>> socket.getaddrinfo("www.python.org", flags=socket.SOL_TCP)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: getaddrinfo() takes no keyword arguments
>>>

----------
components: Library (Lib)
messages: 106817
nosy: exarkun, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.getaddrinfo() should support keyword arguments
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  1 01:22:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 May 2010 23:22:37 +0000
Subject: [New-bugs-announce] [issue8867] serve.py (using wsgiref) cannot
	serve Python docs under	Python3 due to encoding issues
In-Reply-To: <1275348157.42.0.660423745202.issue8867@psf.upfronthosting.co.za>
Message-ID: <1275348157.42.0.660423745202.issue8867@psf.upfronthosting.co.za>


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

If you do a 'make serve' in the docs directory (after doing a make html, of course) and try to open the What's New link in the served doc pages, the following error results:

ValueError: Unicode data must contain only code points representable in ISO-8859-1 encoding

----------
components: Library (Lib)
messages: 106819
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: serve.py (using wsgiref) cannot serve Python docs under Python3 due to encoding issues
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  1 16:13:03 2010
From: report at bugs.python.org (Michiel de Hoon)
Date: Tue, 01 Jun 2010 14:13:03 +0000
Subject: [New-bugs-announce] [issue8868] Framework install does not behave
	as a framework
In-Reply-To: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>
Message-ID: <1275401583.76.0.0937518467482.issue8868@psf.upfronthosting.co.za>


New submission from Michiel de Hoon <mdehoon at users.sourceforge.net>:

(The discussion for this bug started on the pythonmac-sig mailing list; see http://mail.python.org/pipermail/pythonmac-sig/2010-May/022362.html)

When I try to install Python as a framework:

./configure --enable-framework
make
make install

then Python gets installed under /Library/Frameworks/Python.framework/Versions/2.7, but it doesn't seem to function as a framework:

>>> import MacOS
>>> MacOS.WMAvailable()
False
>>> 

Python 2.6.5 returns True here. This is important for GUI extension modules; such modules do not interact correctly with the window manager if Python is not installed as a framework.

I see the same behavior with the current Python in trunk with Mac OS X 10.4 and 10.5 both with Python installed from source and the precompiled python 2.7b2. Python revision 77030 seems to be the last revision without this problem. In revision 77031, posix_spawn() was introduced instead of execv() in pythonw.c to start the Python executable.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 106838
nosy: mdehoon, ronaldoussoren
priority: normal
severity: normal
status: open
title: Framework install does not behave as a framework
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun  1 16:40:38 2010
From: report at bugs.python.org (stier08)
Date: Tue, 01 Jun 2010 14:40:38 +0000
Subject: [New-bugs-announce] [issue8869] execfile does not work with UNC
	paths
In-Reply-To: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>
Message-ID: <1275403238.02.0.475988525563.issue8869@psf.upfronthosting.co.za>


New submission from stier08 <stier08 at gmail.com>:

execfile() builtin function does not work with UNC paths on Windows platform (Windows 7 x64 has been tested, python 2.6.5)

Since standard IO operations successfully process UNC paths, therefore this behavior of execfile() seems to be a bug.

Code to reproduce (assuming drive c: is present and you have rw permissions)
>>> a=u'\\\\?\\c:\\a.py'
>>> open(a,"w").write("print 'hellow'") # successful write to UNC file 
>>> file(a).read() # successful read from UNC file 
"print 'hellow'"
>>> execfile(a) # ERROR
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 2] No such file or directory: '\\\\?\\c:\\a.py'

See description of UNC naming convention
at msdn http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
at wikipedia http://en.wikipedia.org/wiki/Path_(computing)#Uniform_Naming_Convention

----------
components: Unicode, Windows
messages: 106841
nosy: stier08
priority: normal
severity: normal
status: open
title: execfile does not work with UNC paths
type: behavior
versions: Python 2.6

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

From p.wentworth at ru.ac.za  Tue Jun  1 18:28:04 2010
From: p.wentworth at ru.ac.za (Peter Wentworth)
Date: Tue, 1 Jun 2010 18:28:04 +0200
Subject: [New-bugs-announce] Turtle Graphics slowdown
Message-ID: <24B0150B4DCD07499EA29EB9D9A4411E015C5CF7@mail.ict.ru.ac.za>

Hi - I observe very erratic (repeatable) slowdown (e.g. 50 times slower
to do some of the sequences of 10 loop iterations) with this
demonstration program. 

The problem only seems to happen when we enable line 46 ...

               tess.dot(None,0,255,0)   

I've added some printing of timings too.

 

This is Python 2.6.5 (r265:79063) on Windows XP.  Is it specifically an
artefact on Windows, or does it also slow down like this on *nix?
Any ideas why?    (I'm not looking for a way to speed it up - I'm
looking for an explanation J)

 

Thanks

Peter

 

---

 

# http://code.activestate.com/recipes/576982/ (r1)

# Levy Dragon Fractal Curve

# FB - 200912093

 

from turtle import *

import time

 

def draw_fractal(length, angle, level, initial_state, target,
replacement, target2, replacement2):

 

    state = initial_state

 

    tess = Turtle()

    tess.hideturtle()

 

    screen = tess.getscreen()

    screen.colormode(255)

    screen.bgcolor("pink")

    screen.delay(0)

    tess.speed(0)

 

    for counter in range(level):

        state2 = ''

        for character in state:

            if character == target:

                state2 += replacement

            elif character == target2:

                state2 += replacement2

            else:

                state2 += character

        state = state2

 

    print(state2)

    # draw

    startTime = time.time()

    moveCount = 0

    for character in state:

        

        moveCount += 1

        if (moveCount % 10 == 0) :

            nowTime = time.time()

            print "Last block of moves took ", nowTime-startTime

            startTime = nowTime

 

        if character == 'F':

            tess.forward(length)

            tess.dot(None,0,255,0)  # If one enables this, things get
bad

        elif character == '+':

            tess.right(angle)

        elif character == '-':

            tess.left(angle)

 

    tess.penup()

    tess.goto(-300,+300)

    tess.write("Click to exit", font=("Comic Sans MS",22, "bold"))

    screen.exitonclick()

 

if __name__ == '__main__':

    draw_fractal(9, 90, 11, 'FX', 'X', 'X+YF+', 'Y', '-FX-Y')

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20100601/fa042912/attachment.html>

From report at bugs.python.org  Tue Jun  1 20:38:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 18:38:01 +0000
Subject: [New-bugs-announce] [issue8870] --user-access-control=force
	produces invalid installer on	Vista
In-Reply-To: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>
Message-ID: <1275417481.6.0.247175279763.issue8870@psf.upfronthosting.co.za>


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

Running `python setup.py bdist_wininst --user-access-control=force` produces invalid installer that fails to install with the error message:

Failed to start elevated process (ShellExecute returned 5)

----------
assignee: tarek
components: Distutils
messages: 106852
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: --user-access-control=force produces invalid installer on Vista
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  1 21:22:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 01 Jun 2010 19:22:19 +0000
Subject: [New-bugs-announce] [issue8871] --user-access-control=auto has no
	effect
In-Reply-To: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>
Message-ID: <1275420139.65.0.104008426141.issue8871@psf.upfronthosting.co.za>


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

Seems like `--user-access-control=auto` option [1] introduced in Python 2.6 for to bdist_wininst has no effect on Vista. 

Test.
1. Get a Vista.
2. `hg clone http://bitbucket.org/techtonik/python-wget/`
3. Add
{{{
    scripts=['wget.py'],
}}}
to setup.py
4. `python setup.py bdist_wininst --user-access-control=auto`
5. Execute wget-0.6.win32.exe
6. Watch the error
{{{
Access is denied.
CreateFile (C:\Python27\Scripts\wget.py)
}}}
7. Python is always installed for "All users" on Vista

[1] http://docs.python.org/distutils/builtdist.html#vista-user-access-control-uac

----------
assignee: tarek
components: Distutils
messages: 106853
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: --user-access-control=auto has no effect
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  1 22:12:18 2010
From: report at bugs.python.org (Chris)
Date: Tue, 01 Jun 2010 20:12:18 +0000
Subject: [New-bugs-announce] [issue8872] if/else stament bug?
In-Reply-To: <1275423138.87.0.563453181958.issue8872@psf.upfronthosting.co.za>
Message-ID: <1275423138.87.0.563453181958.issue8872@psf.upfronthosting.co.za>


New submission from Chris <chrits44 at gmx.com>:

i am trying to learn to program in Python from a book on programming that says to use Python 3 

i downloaded the Python 3.1.2 Windows x86 MSI installer for my machine aka an HP DV2500 running Win 7

it runs fine, but when i try to write the test program from my book i can't get past the if/else statement aka it gives me a syntax error when i get to the point of an if/else statement aka i program to ask the user to guess the number .. and then i try to create an if/else statement to print a you lose type statement if the input guess is not equal to the number specified by the program. for example i program the game to = 777 and print the you lose type message if the user's guess is not equal to 777, however i use the check module command from the run window in IDLE and it gave me a syntax error when i typed it the way the book said ... I've tried to figure this out myself but have had no success .. so i looked up if statements in the Python tutorials on python.org and tried that format and am still getting a syntax error

----------
components: IDLE, Windows
files: hash.py
messages: 106857
nosy: chrits55
priority: normal
severity: normal
status: open
title: if/else stament bug?
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17515/hash.py

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

From report at bugs.python.org  Wed Jun  2 00:18:46 2010
From: report at bugs.python.org (Hugh Secker-Walker)
Date: Tue, 01 Jun 2010 22:18:46 +0000
Subject: [New-bugs-announce] [issue8873] Popen uses 333 times as much CPU as
	a shell pipe on Mac	OS X
In-Reply-To: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>
Message-ID: <1275430726.49.0.216093303643.issue8873@psf.upfronthosting.co.za>


New submission from Hugh Secker-Walker <hughsw at users.sourceforge.net>:

Popen seems to be *very* costly, CPU wise, on Mac OS X.

I need to read and process bytes from the stdout of another process that outputs bytes in a rate-limited fashion, e.g. 80000 bytes per second.  If I use a shell pipeline and a simple Python script to read the bytes and log some details then top and time both agree that the Python script is using roughly 1 second of CPU time for every 2000 seconds of elapsed time.

If I change the script to use Popen to start the first process and to read from proc.stdout, then top and time both agree that the Python script uses roughly 1 second of CPU time for every 6 seconds of elapsed time.  That is, using Popen uses 333 times as much CPU as using a shell pipeline.

In practice, this means that using a shell pipeline has no measureable impact on system performance, and I can run 300 concurrent pipeline jobs, whereas using Popen limits me to running 6 such concurrent jobs.

This is on an up-to-date Mac OS X 10.5.8 system.  The behavior happens with both the stock Python 2.5 from Apple and with Python 2.6 from Macports.

On Ubuntu Linux the Popen solution is perhaps 2% slower than using a shell pipeline.

I'll attach three scripts:
bytestream -- simple program that sends bytes to its stdout
pull0 -- Python script that reads its stdin and logs a couple of stats
pull1 -- Python script that uses Popen to start bytestream and pulls from proc.stdout and runs abysmally slowly.

Use this with a concurrent top to see the shell pipeline behavior:
$ ./bytestream 80000 4 | time ./pull0 11000

Use this with a concurrent top to see the Popen behavior:
$ time ./pull1 ./bytestream 80000 4 11000

In both cases you'll see that system and user time are approximately equal, but that they're roughly 333 times higher for pull1.  Is there a clue in the fact that both times go up by about the same huge factor?

-Hugh

----------
components: Library (Lib)
files: bytestream
messages: 106862
nosy: hughsw
priority: normal
severity: normal
status: open
title: Popen uses 333 times as much CPU as a shell pipe on Mac OS X
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17517/bytestream

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

From report at bugs.python.org  Wed Jun  2 01:45:43 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 01 Jun 2010 23:45:43 +0000
Subject: [New-bugs-announce] [issue8874] py3k documentation mentions
	deprecated opcode LOAD_LOCALS
In-Reply-To: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>
Message-ID: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>


New submission from Yaniv Aknin <yaniv.aknin at gmail.com>:

The documentation of the dis module mentions LOAD_LOCALS, which used to exist in Python 2.x and I believe was removed from py3k (doesn't appear in recent Include/opcode.h).

The exact offending section is: http://docs.python.org/py3k/library/dis.html#opcode-LOAD_LOCALS
I think it should just be edited out.

----------
assignee: docs at python
components: Documentation
messages: 106869
nosy: Yaniv.Aknin, docs at python
priority: normal
severity: normal
status: open
title: py3k documentation mentions deprecated opcode LOAD_LOCALS
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  2 04:45:31 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 02 Jun 2010 02:45:31 +0000
Subject: [New-bugs-announce] [issue8875] XML-RPC improvement is described
	twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>


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

http://docs.python.org/dev/whatsnew/2.7.html#new-and-improved-modules

"The XML-RPC client and server, provided by..." appears twice.

----------
assignee: docs at python
components: Documentation
messages: 106875
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: XML-RPC improvement is described twice.
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  2 15:38:36 2010
From: report at bugs.python.org (samtygier)
Date: Wed, 02 Jun 2010 13:38:36 +0000
Subject: [New-bugs-announce] [issue8876] distutils should not assume that
	hardlinks will work
In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>
Message-ID: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za>


New submission from samtygier <samtygier at yahoo.co.uk>:

distutils will currently try to use hardlinks if os has a 'link' attribute, however sometimes os.link() will fail, for example the filesystem may not support it (see attached traceback).

in commands/sdist.py in make_release_tree() there is the test:
        if hasattr(os, 'link'):        # can make hard links on this system
            link = 'hard'
            msg = "making hard links in %s..." % base_dir

'link' is then passed to copy_file() in file_util.py, which trusts that if link == 'hard', then hardlinking will work.

there has been discussion in the past, but i dont think it has been fixed
http://thread.gmane.org/gmane.comp.python.distutils.devel/2076

----------
assignee: tarek
components: Distutils
files: hardlink-traceback.txt
messages: 106881
nosy: samtygier, tarek
priority: normal
severity: normal
status: open
title: distutils should not assume that hardlinks will work
versions: Python 2.6
Added file: http://bugs.python.org/file17521/hardlink-traceback.txt

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

From report at bugs.python.org  Wed Jun  2 16:09:05 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 02 Jun 2010 14:09:05 +0000
Subject: [New-bugs-announce] [issue8877] 2to3 fixes stdlib import wrongly
In-Reply-To: <1275487745.39.0.469741822942.issue8877@psf.upfronthosting.co.za>
Message-ID: <1275487745.39.0.469741822942.issue8877@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

djc at enrai src $ ls -l test/*
-rw-r--r-- 1 djc users 34 Jun  2 16:00 test/http.py
-rw-r--r-- 1 djc users  0 Jun  2 16:00 test/__init__.py
djc at enrai src $ cat test/http.py
from httplib import BadStatusLine
djc at enrai src $ 2to3 test/*
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- test/http.py (original)
+++ test/http.py (refactored)
@@ -1,1 +1,1 @@
-from httplib import BadStatusLine
+from .http.client import BadStatusLine
RefactoringTool: Files that need to be modified:
RefactoringTool: test/http.py

... which doesn't work, of course. On the other hand, http.py is not in a package, it works correctly. If test/http.py is moved to test/blah.py instead, it also works correctly. 2to3 should be able to conclude that the "httplib" it was before did not refer to .http, but refered to http.client.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 106882
nosy: djc
priority: normal
severity: normal
status: open
title: 2to3 fixes stdlib import wrongly
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  2 16:47:42 2010
From: report at bugs.python.org (Neil Crouch)
Date: Wed, 02 Jun 2010 14:47:42 +0000
Subject: [New-bugs-announce] [issue8878] IDLE - str(integer) - TypeError:
	'str' object is not	callable
In-Reply-To: <1275490062.25.0.32490402155.issue8878@psf.upfronthosting.co.za>
Message-ID: <1275490062.25.0.32490402155.issue8878@psf.upfronthosting.co.za>


New submission from Neil Crouch <neil.crouch at tradingtechnologies.com>:

Unable to convert int to str in idle but from the cmd python prompt it work sfine.

----------
components: IDLE
files: IDLE_err.txt
messages: 106887
nosy: Stranger381
priority: normal
severity: normal
status: open
title: IDLE - str(integer) - TypeError: 'str' object is not callable
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17523/IDLE_err.txt

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

From report at bugs.python.org  Wed Jun  2 20:47:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 02 Jun 2010 18:47:38 +0000
Subject: [New-bugs-announce] [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>


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

Add os.link support for Windows


(mostly a reminder to myself to finish the patch I have)

----------
assignee: brian.curtin
components: Extension Modules, Windows
messages: 106908
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement os.link on Windows
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun  2 23:01:38 2010
From: report at bugs.python.org (Edwin Pozharski)
Date: Wed, 02 Jun 2010 21:01:38 +0000
Subject: [New-bugs-announce] [issue8880] ConfigParser.set does not convert
	non-string values
In-Reply-To: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>
Message-ID: <1275512498.11.0.636017814706.issue8880@psf.upfronthosting.co.za>


New submission from Edwin Pozharski <pozharski at gmail.com>:

set() method of ConfigParser accepts boolean True/False as values at runtime without converting them to strings internally.  As a result, getboolean() method reports the following error

  File "/usr/lib/python2.6/ConfigParser.py", line 350, in getboolean
    if v.lower() not in self._boolean_states:
AttributeError: 'bool' object has no attribute 'lower'

since it expects get() method to return strings.  (Same problem occurs if other types are used, int/float, etc)

Altering set() behavior may be not the best thing to do, I'd rather suggest that getboolean() converts the get() output to string.

Of course, the way to avoid this problem is always convert values submitted to set() to strings, but it's a hard-to-catch bug.  In my case, I was stuck with problematic configuration when assigning values to wx.CheckBox.GetValue(), which returns boolean.

----------
messages: 106912
nosy: Edwin.Pozharski
priority: normal
severity: normal
status: open
title: ConfigParser.set does not convert non-string values
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun  2 23:31:28 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 02 Jun 2010 21:31:28 +0000
Subject: [New-bugs-announce] [issue8881] socket.getaddrinfo() should return
	named tuples
In-Reply-To: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>
Message-ID: <1275514288.42.0.225628200657.issue8881@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As of right now socket.getaddrinfo() returns a sequence of 5-tuples reflecting family, type, protocol, canonname, and address of a socket:

>>> socket.getaddrinfo(None, 0)
[(10, 1, 6, '', ('::1', 0, 0, 0)), (10, 2, 17, '', ('::1', 0, 0, 0)), (10, 3, 0, '', ('::1', 0, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 0)), (2, 2, 17, '', ('127.0.0.1', 0)), (2, 3, 0, '', ('127.0.0.1', 0))]

For readability it would be good if they were named tuples instead:

>>> socket.getaddrinfo(None, 0)[0]
addr_info(family=10, type=1, protocol=6, canonname='', address=('::1', 0, 0, 0))

Optionally, integers can be replaced by socket constant names:

>>> socket.getaddrinfo(None, 0)[0]
addr_info(family=socket.AF_INET6, type=socket.SOCK_STREAM, protocol=socket.IPPROTO_TCP, canonname='', address=('::1', 0, 0, 0))

----------
components: Library (Lib)
messages: 106916
nosy: exarkun, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.getaddrinfo() should return named tuples
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  3 03:27:50 2010
From: report at bugs.python.org (Edward Pilatowicz)
Date: Thu, 03 Jun 2010 01:27:50 +0000
Subject: [New-bugs-announce] [issue8882] socketmodule.c`getsockaddrarg()
	should not check the	length of sun_path
In-Reply-To: <1275528470.51.0.813873994417.issue8882@psf.upfronthosting.co.za>
Message-ID: <1275528470.51.0.813873994417.issue8882@psf.upfronthosting.co.za>


New submission from Edward Pilatowicz <edward.pilatowicz at oracle.com>:

recently i was writing some python code that attempted to bind a unix
domain socket to a long filesystem path.  this code was failing and
telling me that the path name was too long.  tracing python i saw that
it wasn't event issuing a system call for my bind() request.  eventually
i tracked down the problem to socketmodule.c`getsockaddrarg():

http://svn.python.org/view/python/trunk/Modules/socketmodule.c?view=markup

there we see that getsockaddrarg() checks to verify that the specified
path is less than "sizeof addr->sun_path", where addr is a struct
sockaddr_un.  this seems incorrect to me.

on most systems sockaddr_un.sun_path is defined as a small character
array.  this limit is an ancient bit of unix legacy and most modern
systems do not actually limit domain socket names to a path as short as
sun_path.  on solaris the real limit is MAXPATHLEN, there by allowing
unix domain sockets to be bound to any filesystem path.

the posix specification also says that users of the sockaddr_un 
structure should not make any assumptions about the maximum supported
length of sun_path.

from:
    http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/un.h.html

we have:
    char        sun_path[]    socket pathname
    ...

    The size of sun_path has intentionally been left undefined. This is
    because different implementations use different sizes. For example,
    4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since
    most implementations originate from BSD versions, the size is
    typically in the range 92 to 108.

    Applications should not assume a particular length for sun_path or
    assume that it can hold {_POSIX_PATH_MAX} characters (255).

hence, it seems to me that python should not actually be doing any size
checks on the path passed to getsockaddrarg().  instead is should
dynamically allocate a sockaddr_un large enough to hold whatever string
was pass in.  this structure can then be passed on to system calls which
can they check if the specified path is of a supported length.  (if you
look at the posix definitions for bind() and connect() you'll see that 
they both can return ENAMETOOLONG if the passed in pathname is too 
large.)

----------
components: None
messages: 106929
nosy: Edward.Pilatowicz
priority: normal
severity: normal
status: open
title: socketmodule.c`getsockaddrarg() should not check the length of sun_path
type: behavior
versions: Python 2.6

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

From martin at v.loewis.de  Thu Jun  3 08:56:52 2010
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Jun 2010 08:56:52 +0200
Subject: [New-bugs-announce] [issue8882] socketmodule.c`getsockaddrarg()
 should not check the	length of sun_path
In-Reply-To: <1275528470.51.0.813873994417.issue8882@psf.upfronthosting.co.za>
References: <1275528470.51.0.813873994417.issue8882@psf.upfronthosting.co.za>
Message-ID: <4C075234.1020503@v.loewis.de>

>      Applications should not assume a particular length for sun_path or
>      assume that it can hold {_POSIX_PATH_MAX} characters (255).
>
> hence, it seems to me that python should not actually be doing any size
> checks on the path passed to getsockaddrarg().

You are misinterpreting the specification. What they say is that the 
right way of doing it is the way Python currently does it.

"not assume a particular length" means "not assume, in the source code,
and specific fixed length, such as 108, or 255". Now, if the program 
must not assume any specific length, it must use sizeof instead to 
determine how large sun_path is.

If your operating system declares sun_path to be shorter than the 
strings it actually supports, complain to your operating system vendor 
that they fix their header files.

From report at bugs.python.org  Thu Jun  3 09:31:49 2010
From: report at bugs.python.org (Yuriy Taraday)
Date: Thu, 03 Jun 2010 07:31:49 +0000
Subject: [New-bugs-announce] [issue8883] Proxy exception lookup fails on
	MacOS in urllib.
In-Reply-To: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>
Message-ID: <1275550309.78.0.672707816894.issue8883@psf.upfronthosting.co.za>


New submission from Yuriy Taraday <yorik.sar at gmail.com>:

I have straight IP in my proxy exception list like "192.168.0.2" without mask specification.

The proxy_bypass_macosx_sysconf function verifies each item in this list by regexp r"(\d+(?:\.\d+)*)(/\d+)?" that produces two groups: IP and mask. The mask can be None here (as in my case) and this None case isn't handled, so urllib crashes with "TypeError: 'NoneType' object is unsubscriptable".

I couldn't find specification of MacOS proxy exceptions list, so I don't know whether you can use just IP or prefix without mask specification. If you can, here is small patch that adds nesessary check and guesses mask if it is not specified. If you cannot, the last question mark should be removed from regex.

----------
components: Library (Lib)
files: urllib.py.diff
keywords: patch
messages: 106933
nosy: yorik.sar
priority: normal
severity: normal
status: open
title: Proxy exception lookup fails on MacOS in urllib.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17526/urllib.py.diff

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

From report at bugs.python.org  Thu Jun  3 11:33:24 2010
From: report at bugs.python.org (Gaz Davidson)
Date: Thu, 03 Jun 2010 09:33:24 +0000
Subject: [New-bugs-announce] [issue8884] Allow binding to local address in
	httplib / http.client
In-Reply-To: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>
Message-ID: <1275557604.57.0.107374927825.issue8884@psf.upfronthosting.co.za>


New submission from Gaz Davidson <garethdavidson at gmail.com>:

The option to bind to a local IP address when creating an HTTP connection would be very useful for web testing tools like FunkLoad and webunit. 

For example in FunkLoad it would allow us to run tests with IP-based load balancing.

----------
components: IO
messages: 106934
nosy: Gaz.Davidson
priority: normal
severity: normal
status: open
title: Allow binding to local address in httplib / http.client
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jun  3 13:14:11 2010
From: report at bugs.python.org (Mark Nottingham)
Date: Thu, 03 Jun 2010 11:14:11 +0000
Subject: [New-bugs-announce] [issue8885] markerbase declaration errors
	aren't recoverable
In-Reply-To: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>
Message-ID: <1275563651.6.0.351540013915.issue8885@psf.upfronthosting.co.za>


New submission from Mark Nottingham <mnot at mnot.net>:

In markupbase.py's ParserBase.parse_declaration, an unexpected character is caught like this:

            else:
                self.error(
                    "unexpected %r char in declaration" % rawdata[j])

However, the position (j) isn't updated, which means that error() will be called again once it returns.

For example, this declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" http://www.w3.org/TR/html4/loose.dtd>

(which I think is generated by MS Office) will trigger this behaviour.

Two possible resolutions:

1) increment J and try the next character in this case

2) document that error() is not recoverable; i.e., it MUST raise an exception.

My preference is strongly for #1 (as HTML parsing should be forgiving, and HTMLParser is based upon markerbase).

----------
components: Library (Lib)
messages: 106938
nosy: mnot
priority: normal
severity: normal
status: open
title: markerbase declaration errors aren't recoverable
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  3 13:39:27 2010
From: report at bugs.python.org (Erik Carstensen)
Date: Thu, 03 Jun 2010 11:39:27 +0000
Subject: [New-bugs-announce] [issue8886] zipfile.ZipExtFile should be a
	context manager
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>


New submission from Erik Carstensen <sandberg at virtutech.com>:

It's nice that ZipFile is a context manager in 2.7.  It would be nice and more consistent if the objects returned from ZipFile.open() were context managers too.

----------
components: Library (Lib)
messages: 106941
nosy: sandberg
priority: normal
severity: normal
status: open
title: zipfile.ZipExtFile should be a context manager
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jun  3 13:42:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 11:42:54 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry?=
 =?utf-8?b?4oCdIHdvcmtzIGJ1dCBub3Qg4oCccHlkb2Mgc3RyLnRyYW5zbGF0ZeKAnQ==?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>


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

Inconsistent behavior:
pydoc3 str: works
pydoc3 str.translate: doesn?t
pydoc3 builtins.str: works
pydoc3 builtins.str.translate: doesn?t

I think pydoc3 str.translate should work. I?ll be able to try to write a patch in some weeks.

----------
components: Library (Lib)
messages: 106942
nosy: merwok
priority: normal
severity: normal
status: open
title: ?pydoc str? works but not ?pydoc str.translate?
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  3 13:49:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 11:49:59 +0000
Subject: [New-bugs-announce] [issue8888] Promote SafeConfigParser and warn
	about ConfigParser
In-Reply-To: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>
Message-ID: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>


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

Problems like #8880 could be prevented with a deprecation notice for the ConfigParser class, in favor of SafeConfigParser. (Not sure if R.?David Murray meant just a recommendation or a real deprecation.)

----------
assignee: docs at python
components: Documentation
messages: 106943
nosy: docs at python, merwok, r.david.murray
priority: normal
severity: normal
status: open
title: Promote SafeConfigParser and warn about ConfigParser
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun  3 20:50:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jun 2010 18:50:06 +0000
Subject: [New-bugs-announce] [issue8889] test_support.transient_internet
	fails on Freebsd because	socket has no attribute EAI_NODATA
In-Reply-To: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>
Message-ID: <1275591006.22.0.670569241556.issue8889@psf.upfronthosting.co.za>


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

test_support.transient_internet was modified to check for more errors, but one of them, socket.EAI_NODATA, is not supported by FreeBSD.  The attached patch rewrites transient_internet to only test EAI error codes that exist, and also improves the skip message.

----------
components: Tests
files: transient_internet.patch
keywords: patch
messages: 106972
nosy: haypo, r.david.murray
priority: normal
severity: normal
status: open
title: test_support.transient_internet fails on Freebsd because socket has no attribute EAI_NODATA
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17534/transient_internet.patch

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

From report at bugs.python.org  Thu Jun  3 23:11:54 2010
From: report at bugs.python.org (Henri Salo)
Date: Thu, 03 Jun 2010 21:11:54 +0000
Subject: [New-bugs-announce] [issue8890] Module logging has dangerous
	examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>


New submission from Henri Salo <henri at nerv.fi>:

Module logging has dangerous examples as one can see from: <http://docs.python.org/library/logging.html#simple-examples> 15.6.1.1:

> import logging
> LOG_FILENAME = '/tmp/logging_example.out'
> logging.basicConfig(filename=LOG_FILENAME,level=logging.DEBUG)
> logging.debug('This message should go to the log file')

It is not very wise to guide programmers to create programming mistakes. More information about the situation from: <http://www.owasp.org/index.php/Insecure_Temporary_File>.

----------
components: None
messages: 106982
nosy: Henri.Salo
priority: normal
severity: normal
status: open
title: Module logging has dangerous examples
type: security
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  3 23:13:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Jun 2010 21:13:38 +0000
Subject: [New-bugs-announce] [issue8891] sort files before archiving for
	consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>


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

I am troubleshooting local issue with distutils and UAC on Windows, and I need to compare resulting binary archives. Unfortunately files to bdist archives are added in random order and this complicates comparisons. This patch makes distutils archives more deterministic.

----------
assignee: tarek
components: Distutils
files: sort_files_in_zip.26.patch
keywords: patch
messages: 106983
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: sort files before archiving for consistency
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file17538/sort_files_in_zip.26.patch

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

From report at bugs.python.org  Fri Jun  4 00:20:51 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 03 Jun 2010 22:20:51 +0000
Subject: [New-bugs-announce] [issue8892] 2to3 fails with assertion failure
	on "from itertools	import *"
In-Reply-To: <1275603651.87.0.583205697426.issue8892@psf.upfronthosting.co.za>
Message-ID: <1275603651.87.0.583205697426.issue8892@psf.upfronthosting.co.za>


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

fix_itertools_imports.py fails on a "*" import

2to3 fails on this code:
   from itertools import *

with a traceback:
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 3680, in test_star
    self.warns_unchanged(s, "Cannot handle star imports")
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 49, in warns_unchanged
    self.warns(before, before, message, unchanged=True)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 43, in warns
    tree = self._check(before, after)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/tests/test_fixers.py", line 32, in _check
    tree = self.refactor.refactor_string(before, self.filename)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/refactor.py", line 359, in refactor_string
    self.refactor_tree(tree, name)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/refactor.py", line 393, in refactor_tree
    self.traverse_by(self.post_order_heads, tree.post_order())
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/refactor.py", line 417, in traverse_by
    new = fixer.transform(node, results)
  File "/home/david/coding/python-svn/trunk-2to3-issues/Lib/lib2to3/fixes/fix_itertools_imports.py", line 24, in transform
    assert child.type == syms.import_as_name
AssertionError

(seen when running 2to3 on python-lxml ; see problem in downstream tracker: https://bugzilla.redhat.com/show_bug.cgi?id=600036 )

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 106991
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: 2to3 fails with assertion failure on "from itertools import *"
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  4 01:50:44 2010
From: report at bugs.python.org (Christophe Kalt)
Date: Thu, 03 Jun 2010 23:50:44 +0000
Subject: [New-bugs-announce] [issue8893] file.{read,
	readlines} behaviour on Solaris
In-Reply-To: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
Message-ID: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>


New submission from Christophe Kalt <python at ote.taranis.org>:

The following snippet of code is a concise way to exhibit the problem:

import os

wr = open('/tmp/test', 'w')
wr.write('oink\noink\n')
rd = open('/tmp/test', 'r')
rdlns = open('/tmp/test', 'r')
# first, read til EOF is reached (which is right away)
assert len(rd.read()) == 0
assert len(rdlns.readlines()) == 0
# add data to the file
wr.flush()
# try to read again
print 'read     : ', rd.read().split() # fails
print 'readlines: ', rdlns.readlines() # fails
print 'readline : ', rdlns.readline().strip() # succeeds
# cleanup
wr.close()
rd.close()
rdlns.close()
os.remove('/tmp/test')


On Linux, here is the output:
$ python2.6 src/readlines.py
read     :  ['oink', 'oink']
readlines:  ['oink\n', 'oink\n']
readline :  

On Solaris, here is the output:
$ python src/readlines.py
read     :  []
readlines:  []
readline :  oink

The problems comes from the fact that once EOF is reached, nothing more will be read from the file on subsequent reads, as noted in the manual page (http://docs.sun.com/app/docs/doc/816-5168/getchar-3c?a=view):

"If the stream is at end-of-file, the end-of-file indicator for the stream is set and these functions return EOF. For standard-conforming (see standards(5)) applications, if the end-of-file indicator for the stream is set, these functions return EOF whether or not the stream is at end-of-file."

The attached diff fixes the problem.

----------
assignee: theller
components: ctypes
files: fileobject.diff
keywords: patch
messages: 106999
nosy: kalt, theller
priority: normal
severity: normal
status: open
title: file.{read,readlines} behaviour on Solaris
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17542/fileobject.diff

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

From report at bugs.python.org  Fri Jun  4 09:10:28 2010
From: report at bugs.python.org (jurjen Bos)
Date: Fri, 04 Jun 2010 07:10:28 +0000
Subject: [New-bugs-announce] [issue8894] urllib2 authentication manager
	retries forever if	password is wrong
In-Reply-To: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>
Message-ID: <1275635428.44.0.0623896045557.issue8894@psf.upfronthosting.co.za>


New submission from jurjen Bos <j.bos-interpay at xs4all.nl>:

If you use an authentication manager from urllib2, it will submit user code and password if authentication fails.
However, if the password is wrong, the authentication manager will happily try again, again with the same password.
A simple way to circumvent this is attached: it modifies the password manager's behaviour to submit each password only once.
One problem I see is in cases where a program needs to log in multiple times in the same site: I propose an extra call to the password manager to reset the "visited" flag.

More details and sample code are in the file.

----------
components: Library (Lib)
files: circumvent.py
messages: 107009
nosy: Jurjen
priority: normal
severity: normal
status: open
title: urllib2 authentication manager retries forever if password is wrong
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17545/circumvent.py

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

From report at bugs.python.org  Fri Jun  4 11:05:58 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 04 Jun 2010 09:05:58 +0000
Subject: [New-bugs-announce] [issue8895] newline arg/attribute in the module
	io
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>


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

I was confused about the newline argument/attribute
in the misc. classes of the io module until I realize
there is a spelling issue between the docs and the
real implementation. (Py 2.6.5, Py2.7b2). Py 3.x not
tested.

>>> sys.version
2.7b2 (r27b2:81019, May  9 2010, 11:33:14) [MSC v.1500 32 bit (Intel)]
>>> sio = io.StringIO(u'abc')
>>> sio.encoding, type(sio.encoding)
(None, <type 'NoneType'>)
>>> sio.errors, type(sio.errors)
(None, <type 'NoneType'>)
>>> sio.newline, type(sio.newline)
Traceback (most recent call last):
  File "<psi last command>", line 1, in <module>
AttributeError: '_io.StringIO' object has no attribute 'newline'
>>> sio.newlines, type(sio.newlines)
(None, <type 'NoneType'>)
>>> 


>>> tio = io.TextIOWrapper(io.BytesIO())
>>> tio.buffer, type(tio.buffer)
(<_io.BytesIO object at 0x02E6E600>, <type '_io.BytesIO'>)
>>> tio.encoding, type(tio.encoding)
('cp1252', <type 'str'>)
>>> tio.errors, type(tio.errors)
('strict', <type 'str'>)
>>> tio.line_buffering, type(tio.line_buffering)
(False, <type 'bool'>)
>>> tio.newline, type(tio.newline)
Traceback (most recent call last):
  File "<psi last command>", line 1, in <module>
AttributeError: '_io.TextIOWrapper' object has no attribute 'newline'
>>> tio.newlines, type(tio.newlines)
(None, <type 'NoneType'>)

>>> sys.version
2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
>>> import io
>>> tio = io.TextIOWrapper(io.BytesIO())
>>> tio.encoding, type(tio.encoding)
('cp1252', <type 'str'>)
>>> tio.line_buffering, type(tio.line_buffering)
(False, <type 'bool'>)
>>> tio.errors, type(tio.errors)
(u'strict', <type 'unicode'>)
>>> tio.newline, type(tio.newline)
Traceback (most recent call last):
  File "<psi last command>", line 1, in <module>
AttributeError: 'TextIOWrapper' object has no attribute 'newline'
>>> tio.newlines, type(tio.newlines)
(None, <type 'NoneType'>)
>>> [e for e in dir(tio) if 'new' in e]
['__new__', 'newlines']
>>>

----------
components: IO
messages: 107017
nosy: jmfauth
priority: normal
severity: normal
status: open
title: newline arg/attribute in the module io
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  4 16:07:18 2010
From: report at bugs.python.org (Forest Bond)
Date: Fri, 04 Jun 2010 14:07:18 +0000
Subject: [New-bugs-announce] [issue8896] email.encoders.encode_base64 sets
	payload to bytes, should set to str
In-Reply-To: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>
Message-ID: <1275660438.53.0.968124979089.issue8896@psf.upfronthosting.co.za>


New submission from Forest Bond <forest at alittletooquiet.net>:

Ran into this while tackling issue3244.  Encoded payload members should not be bytes.  In the case of base64, we should have an ascii string.

----------
components: Library (Lib)
files: python-email-encoders-base64-str.patch
keywords: patch
messages: 107055
nosy: forest_atq
priority: normal
severity: normal
status: open
title: email.encoders.encode_base64 sets payload to bytes, should set to str
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17550/python-email-encoders-base64-str.patch

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

From report at bugs.python.org  Fri Jun  4 19:34:55 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Fri, 04 Jun 2010 17:34:55 +0000
Subject: [New-bugs-announce] [issue8897] sunau bytes / str TypeError in Py3k
In-Reply-To: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>
Message-ID: <1275672895.91.0.97400241219.issue8897@psf.upfronthosting.co.za>


New submission from Thomas Jollans <thomas at jollans.com>:

The sunau module, essentially, "doesn't work". This looks like a problem with the bytes/unicode transition of "str" in Python 3.x vs Python 2:

Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sunau
>>> aufile = sunau.open('test.au', 'w')
>>> aufile.setsampwidth(2)
>>> aufile.setframerate(44100)
>>> aufile.setnchannels(1)
>>> aufile.writeframes(b'aabbccdd')
Exception wave.Error: Error('# channels not specified',) in <bound method Wave_write.__del__ of <wave.Wave_write object at 0x1fa8ed0>> ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/sunau.py", line 393, in writeframes
    self.writeframesraw(data)
  File "/usr/lib/python3.1/sunau.py", line 383, in writeframesraw
    self._ensure_header_written()
  File "/usr/lib/python3.1/sunau.py", line 418, in _ensure_header_written
    self._write_header()
  File "/usr/lib/python3.1/sunau.py", line 452, in _write_header
    self._file.write(self._info)
TypeError: must be bytes or buffer, not str
>>> 

The wave and aifc modules work as expected when used like this, as does the above code in Python 2.6. Au_read.readframes correctly returns a bytes.

I haven't tested this on a development version of Python.

----------
components: Library (Lib)
messages: 107081
nosy: tjollans
priority: normal
severity: normal
status: open
title: sunau bytes / str TypeError in Py3k
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun  4 20:53:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 18:53:51 +0000
Subject: [New-bugs-announce] [issue8898] The email package should defer to
	the codecs module for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>


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

Currently the email module maintains a set of "charset" aliases that it maps to codec names before looking up the codec in the codecs module.  Ideally it should instead be able to just look up any 'charset' name, and if it is a valid alias for a codec, the codec module would return the codec with the canonical name.  It is possible (I haven't checked yet) that the email module needs a different canonical  'charset' name for certain codecs, but if so it can do that mapping after getting the canonical codec name from codecs.

To implement this we need to make two simple changes:

1) add any aliases the email module recognizes but the codecs module doesn't to the codecs module.

2) rewrite email.charset so that it does not have an ALIASES table (but may have a smaller 'canonical charset map' table instead).

----------
assignee: r.david.murray
components: Library (Lib)
keywords: easy
messages: 107087
nosy: l0nwlf, lemburg, r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: The email package should defer to the codecs module for all aliases
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun  4 21:47:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 19:47:17 +0000
Subject: [New-bugs-announce] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>


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

The time.struct_time class is missing class and field docstrings: 

>>> time.struct_time.__doc__ is None
True
>>> time.struct_time.tm_year.__doc__ is None
True

This is significant because it is not obvious that field values are different from those of C language struct tm fields with the same names. (While module level docstring describes the timetuple, it does not list the names of the struct_time fields or mentions struct_time.)

With the attached patch,

>>> from time import *
>>> localtime()
time.struct_time(tm_year=2010, tm_mon=6, tm_mday=4, tm_hour=15, tm_min=27, tm_sec=15, tm_wday=4, tm_yday=155, tm_isdst=1)
>>> help(_)
Help on struct_time object:

time.struct_time = class struct_time(__builtin__.object)
 |  The time value as returned by gmtime(), localtime(), and strptime(), and accepted
 |  by asctime(), mktime() and strftime(), may be considered as a sequence of 9 integers.
 |  Note that several fields' values are not the same as those defined by the C language
 |  standard for struct tm.  For example, the value of tm_year is the actual year, not
 |  year - 1900.   See individual fields' descriptions for details.
...
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  tm_hour
 |      hours, range [0 - 23]
 |  
 |  tm_isdst
 |      1 if summer time is in effect, 0 if not, and -1 if cannot be determined
 |  
 |  tm_mday
 |      day of month, range [1 - 31]
 |  
 |  tm_min
 |      minutes, range [0 - 59]
 |  
 |  tm_mon
 |      month of year, range [1 - 12]
 |  
 |  tm_sec
 |      seconds, range [0 - 61])
 |  
 |  tm_wday
 |      day of week, range [0,6], Monday is 0
 |  
 |  tm_yday
 |      day of year, range [1,366]
 |  
 |  tm_year
 |      year, for example, 1993
 |  
 |  ----------------------------------------------------------------------

----------
assignee: belopolsky
components: Documentation
files: struct_time_doc.diff
keywords: easy, patch
messages: 107089
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Add docstrings to time.struct_time
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17556/struct_time_doc.diff

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

From report at bugs.python.org  Sat Jun  5 01:58:18 2010
From: report at bugs.python.org (Michael Huster)
Date: Fri, 04 Jun 2010 23:58:18 +0000
Subject: [New-bugs-announce] [issue8900] IDLE crashes if Preference set to
	At Startup -> Open Edit	Window
In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>
Message-ID: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>


New submission from Michael Huster <mhuster55 at gmail.com>:

This only seems to be a problem under Windows.
>From a Portable Python discussion:
I am using Portable Python 1.1, python 3.0.1.
I am trying to set up a .bat file file to easily start IDLE. But IDLE
is throwing an error and failing some of the time.
It only happens if IDLE is set up to start in the edit mode. (Which I
prefer.) And then it only throws the error the first time a file is
opened. It doesn't seem to matter what kind of file is opened. The
other symptom is that a new line is inserted at the top of the file
that is opened.

The error is (I'm typing it by hand):
Exception in Tkinter callback
Traceback (most recent call last):
 File "E:\py30\App\lib\tkinter\__init__.py", line 1399, in __call__
   return self.func(*args)
 File "E:\py30\App\lib\idlelib\MultiCall.py", line 174, in handler
doafterhandler.pop()()
 File "E:\py30\App\lib\idlelib\MultiCall.py", line 221, in <lambda>
doit = lambda: self.bindedfuncs[triplet[2]][triplet[0]].remove(func)
ValueError: list.remove(x): x not in list

I can work around this with a batch file that uses python.exe, not
pythonw.exe, but it leaves an annoying command shell window open.

I also tested IDLE under a normal python installation and the same thing happens, so, sorry, it is not a PP thing. There must be a bug in IDLE under py 3.0. I'll file this with python.org.

----------
components: IDLE
messages: 107113
nosy: mhuster
priority: normal
severity: normal
status: open
title: IDLE crashes if Preference set to At Startup -> Open Edit Window
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun  5 04:39:25 2010
From: report at bugs.python.org (flashk)
Date: Sat, 05 Jun 2010 02:39:25 +0000
Subject: [New-bugs-announce] [issue8901] Windows registry path not ignored
	with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

Hi,

I noticed that Python still uses the Windows registry to initialize sys.path, when the -E option is used.

>From my understanding, this option is mostly used by programs that are running an embedded version of python, and don't want it to be affected by global installations. Ignoring the registry, along with environment variables, seems to be the correct behavior in this case.

I asked about this on the python-dev list (http://mail.python.org/pipermail/python-dev/2010-June/100492.html) and was told to submit a patch for this if I wanted it fixed before the 2.7 release.

I've included a patch for 2.7 and 3.2

----------
components: Interpreter Core
files: IgnoreWindowsRegistry_27.patch
keywords: patch
messages: 107121
nosy: flashk
priority: normal
severity: normal
status: open
title: Windows registry path not ignored with -E option
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17558/IgnoreWindowsRegistry_27.patch

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

From report at bugs.python.org  Sat Jun  5 08:36:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 06:36:29 +0000
Subject: [New-bugs-announce] [issue8902] add datetime.time.now() for
	consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>


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

There is:
datetime.date.today()
datetime.datetime.today()
datetime.datetime.now([tz])

But no:
datetime.time.now([tz])

----------
components: Library (Lib)
messages: 107122
nosy: techtonik
priority: normal
severity: normal
status: open
title: add datetime.time.now() for consistency
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  5 08:48:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 06:48:27 +0000
Subject: [New-bugs-announce] [issue8903] datetime functions
In-Reply-To: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>
Message-ID: <1275720507.31.0.185559003971.issue8903@psf.upfronthosting.co.za>


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

Current OOP API of datetime is ugly:

from datetime import datetime
print datetime.today().isoformat()

The proposal is to add today() and now() as module functions:

from datetime import today, now
print today()
# datetime.date(2010, 6, 5)
print now()
# datetime.datetime(2010, 6, 5, 9, 48, 4, 868000)

----------
components: Library (Lib)
messages: 107123
nosy: techtonik
priority: normal
severity: normal
status: open
title: datetime functions
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  5 12:30:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 10:30:48 +0000
Subject: [New-bugs-announce] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>


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

It would be helpful to have examples how to patch docs in some place like 
http://docs.python.org/bugs.html

For example, in CHM version of 2.6.5 manual open() anchor points to reference/datamodel.html#index-844 and to tutorial/inputoutput.html#index-1080 but not to library/functions.html#open

----------
assignee: docs at python
components: Documentation
messages: 107127
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: quick example how to fix docs

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

From report at bugs.python.org  Sat Jun  5 13:45:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 11:45:41 +0000
Subject: [New-bugs-announce] [issue8905] difflib: support input generators
In-Reply-To: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>
Message-ID: <1275738341.19.0.989231664853.issue8905@psf.upfronthosting.co.za>


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

difflib operates on the lists, but it should be possible to use arbitrary generators. This will require internal limit on buffer size that has a side advantage of limiting difflib to available memory.

----------
components: Library (Lib)
messages: 107130
nosy: techtonik
priority: normal
severity: normal
status: open
title: difflib: support input generators
type: resource usage
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  5 14:30:06 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Sat, 05 Jun 2010 12:30:06 +0000
Subject: [New-bugs-announce] [issue8906] Document TestCase attributes in
	class docstring
In-Reply-To: <1275741006.84.0.66027792452.issue8906@psf.upfronthosting.co.za>
Message-ID: <1275741006.84.0.66027792452.issue8906@psf.upfronthosting.co.za>


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

The unittest.TestCase class has some public attributes: failureException, longMessage and maxDiff.  They each have a description in a comment, but I think it would be good if that description got moved into the class docstring so that it would be found using help().

----------
components: Library (Lib)
messages: 107132
nosy: ezio.melotti, flub
priority: normal
severity: normal
status: open
title: Document TestCase attributes in class docstring
type: feature request
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jun  5 17:39:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 15:39:08 +0000
Subject: [New-bugs-announce] [issue8907] time module documentation differs
	in trunk and py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>


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

Doc/library/time.rst differs in trunk and py3k.  It appears that the trunk version is more up to date and can simply replace the py3k version, but I would like to have another pair of eyes to take a look before committing.

I also noticed that time.asctime signature is displayed as asctime([t]) and as asctime([tuple]) in docstring.  I think docstring variant is better.

----------
assignee: belopolsky
components: Documentation
files: time-doc.diff
keywords: patch
messages: 107141
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: time module documentation differs in trunk and py3k
versions: Python 3.2
Added file: http://bugs.python.org/file17562/time-doc.diff

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

From report at bugs.python.org  Sat Jun  5 18:45:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:45:01 +0000
Subject: [New-bugs-announce] [issue8908] friendly errors for UAC errors in
	windows installers
In-Reply-To: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>
Message-ID: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>


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

The problem investigated in issue8870 detected that bdist_wininst installers fail in Vista and Windows 7 with enabled UAC (user access control) when run from local drives with non-MS file systems and from network drives.

The error message returned in this case is not explanative at all.
"Failed to start elevated process (ShellExecute returned 5)"

Further investigation revealed that if network samba share requires authentication, and authentication passes, then the installer won't fail. Unfortunately, I can not setup network access to unauthenticated Samba shares right now to test behavior, but I attach installer generated with --user-access-control=force in case somebody can help.

The error message needs to be improved to give users immediate hint what Windows UAC doesn't allow to run privileged executables from non-MS file systems and/or network drives.

----------
assignee: tarek
components: Distutils, Distutils2
files: wget-0.6.win32.force.exe
messages: 107149
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: friendly errors for UAC errors in windows installers
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17563/wget-0.6.win32.force.exe

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

From report at bugs.python.org  Sat Jun  5 23:41:21 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 21:41:21 +0000
Subject: [New-bugs-announce] [issue8909] mention bitmap size for
	bdist_wininst
Message-ID: <1275774081.13.0.449044323851.issue8909@psf.upfronthosting.co.za>


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


----------
assignee: tarek
components: Distutils, Documentation
files: mention.bdist.bitmap.size.diff
keywords: patch
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: mention bitmap size for bdist_wininst
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file17565/mention.bdist.bitmap.size.diff

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

From report at bugs.python.org  Sun Jun  6 05:06:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:06:20 +0000
Subject: [New-bugs-announce] [issue8910] Write a text file explaining why
	Lib/test/data exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The directory is empty by default as that's where some temporary files are put during testing. Should have a text file in there explaining this fact.

----------
components: Tests
keywords: easy
messages: 107176
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Write a text file explaining why Lib/test/data exists

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

From report at bugs.python.org  Sun Jun  6 05:23:26 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:23:26 +0000
Subject: [New-bugs-announce] [issue8911] regrtest.main should have a test
	skipping argument
In-Reply-To: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za>
Message-ID: <1275794606.83.0.993053669818.issue8911@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you look at importlib.regrtest you will notice it has to muck with sys.argv in order to get certain tests skipped. It would be much better if regrtest.main had an argument you could specify instead which listed the tests to skip.

This might lead to breaking out the command line parsing into the __main__ block at the end of the file instead of having it all in regrtest.main.

----------
components: Tests
keywords: easy
messages: 107177
nosy: brett.cannon
priority: low
severity: normal
status: open
title: regrtest.main should have a test skipping argument
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:24:39 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:24:39 +0000
Subject: [New-bugs-announce] [issue8912] `make patchcheck` should check the
	whitespace of .c/.h	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

This would be especially useful now that only spaces are used in .c/.h files and not tabs.

----------
messages: 107178
nosy: brett.cannon
priority: low
severity: normal
status: open
title: `make patchcheck` should check the whitespace of .c/.h files
type: feature request

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

From report at bugs.python.org  Sun Jun  6 05:26:19 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:26:19 +0000
Subject: [New-bugs-announce] [issue8913] Document that datetime.__format__
	is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Documenting that would help get people using datetime objects with string.format more.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 107179
nosy: brett.cannon, docs at python
priority: low
severity: normal
status: open
title: Document that datetime.__format__ is datetime.strftime
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:32:54 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:32:54 +0000
Subject: [New-bugs-announce] [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Just like I did for Python 2.7.

Should use this issue to keep track of what I have already processed and what I had to skip because OS X doesn't have the right files.

----------
components: Extension Modules, Interpreter Core
messages: 107180
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Run clang's static analyzer
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:35:09 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:35:09 +0000
Subject: [New-bugs-announce] [issue8915] Use locale.nl_langinfo in _strptime
In-Reply-To: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za>
Message-ID: <1275795309.62.0.41465361185.issue8915@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

It might perform better to use locale.nl_langinfo to get the current locale's datetime information instead of reverse-engineering from strftime (need to benchmark to see if this is true). This would need to be conditional as the datetime info might not be exposed through nl_langinfo.

----------
components: Library (Lib)
messages: 107181
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Use locale.nl_langinfo in _strptime
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 05:39:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:39:20 +0000
Subject: [New-bugs-announce] [issue8916] Move PEP 362 (function signature
	objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

To get function signature objects (PEP 362) moving forward I should get it into the inspect module. That way people can start using it more beyond those in PyPI (http://pypi.python.org/pypi/pep362).

Michael Foord has mentioned how IronPython could use function signature objects. This would be a first step in getting the objects standardized enough so that IronPython could eventually consider putting them on all of their objects.

----------
components: Library (Lib)
messages: 107182
nosy: brett.cannon, michael.foord
priority: low
severity: normal
status: open
title: Move PEP 362 (function signature objects) into inspect
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 16:47:43 2010
From: report at bugs.python.org (tanaga)
Date: Sun, 06 Jun 2010 14:47:43 +0000
Subject: [New-bugs-announce] [issue8917] Segmentation error happens in
	Embedding Python.
In-Reply-To: <1275835663.33.0.520214000656.issue8917@psf.upfronthosting.co.za>
Message-ID: <1275835663.33.0.520214000656.issue8917@psf.upfronthosting.co.za>


New submission from tanaga <muranaga9 at gmail.com>:

A segmentation error happens in Embedding Python.

condition
    When I called four times of Py_Main in one process.
    and When I used ctypes in the script.

A happening
    segmentation error(core dumped)



[user at localhost debug]$ 
[user at localhost debug]$ ls -l
total 24
-rwxrwxrwx 1 user user 333 May 30 03:17 build.sh
-rwxrwxrwx 1 user user 385 Jun  6 23:27 ctypes_segmfault.c
-rwxrwxrwx 1 user user  14 Jun  6 23:25 import_ctypes.py
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ./build.sh 
/usr/local/lib/libpython2.6.a(posixmodule.o): In function `posix_tmpnam':
/work/Python-2.6.5/./Modules/posixmodule.c:7207: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/usr/local/lib/libpython2.6.a(posixmodule.o): In function `posix_tempnam':
/work/Python-2.6.5/./Modules/posixmodule.c:7162: warning: the use of `tempnam' is dangerous, better use `mkstemp'
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ls -l             
total 4212
-rwxrwxrwx 1 user user     333 May 30 03:17 build.sh
-rwxrwxr-x 1 user user 4256056 Jun  6 23:30 ctypes_segmfault
-rwxrwxrwx 1 user user     385 Jun  6 23:27 ctypes_segmfault.c
-rw-rw-r-- 1 user user    4664 Jun  6 23:30 ctypes_segmfault.o
-rwxrwxrwx 1 user user      14 Jun  6 23:25 import_ctypes.py
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ./ctypes_segmfault
----- 0 -----
----- 1 -----
----- 2 -----
----- 3 -----
Segmentation fault (core dumped)
[user at localhost debug]$ 
[user at localhost debug]$ 
[user at localhost debug]$ ls -l
total 5960
-rwxrwxrwx 1 user user     333 May 30 03:17 build.sh
-rw------- 1 user user 1933312 Jun  6 23:31 core.2981
-rwxrwxr-x 1 user user 4256056 Jun  6 23:30 ctypes_segmfault
-rwxrwxrwx 1 user user     385 Jun  6 23:27 ctypes_segmfault.c
-rw-rw-r-- 1 user user    4664 Jun  6 23:30 ctypes_segmfault.o
-rwxrwxrwx 1 user user      14 Jun  6 23:25 import_ctypes.py
[user at localhost debug]$ 


so I watched core with gdb.


[user at localhost debug]$ gdb ctypes_segmfault core.2981 
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/user/debug/ctypes_segmfault...done.

warning: core file may not match specified executable file.
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/python2.6/lib-dynload/_ctypes.so...done.
Loaded symbols for /usr/local/lib/python2.6/lib-dynload/_ctypes.so
Reading symbols from /usr/local/lib/python2.6/lib-dynload/_struct.so...done.
Loaded symbols for /usr/local/lib/python2.6/lib-dynload/_struct.so
Core was generated by `./ctypes_segmfault'.
Program terminated with signal 11, Segmentation fault.
#0  0x080a103a in type_dealloc (type=0x9f3180) at Objects/typeobject.c:2610
2610            _PyObject_GC_UNTRACK(type);
(gdb) bt
#0  0x080a103a in type_dealloc (type=0x9f3180) at Objects/typeobject.c:2610
#1  0x080888ef in dict_dealloc (mp=0xb7ef313c) at Objects/dictobject.c:911
#2  0x080888ef in dict_dealloc (mp=0xb7f4c02c) at Objects/dictobject.c:911
#3  0x080e7599 in _PyImport_Fini () at Python/import.c:240
#4  0x080f47cc in Py_Finalize () at Python/pythonrun.c:460
#5  0x08058183 in Py_Main (argc=1, argv=0xbfe5c6c8) at Modules/main.c:596
#6  0x080579d3 in main () at ./ctypes_segmfault.c:16
(gdb) quit
[user at localhost debug]$ 

fumm... I don't know about inside of Python Interpreter.



[user at localhost debug]$ cat ctypes_segmfault.c
#include <stdio.h>
#include <Python.h>

/* ulimit -c unlimited */

int main(void) {
  char *argpy[] = { "python", "import_ctypes.py" };
  
  printf("----- 0 -----\n");
  Py_Main(2, argpy);
  printf("----- 1 -----\n");
  Py_Main(2, argpy);
  printf("----- 2 -----\n");
  Py_Main(2, argpy);
  printf("----- 3 -----\n");
  Py_Main(2, argpy);
  printf("----- 4 -----\n");
  
  return 0;
}
[user at localhost debug]$ 
[user at localhost debug]$ cat build.sh 
#!/bin/sh

gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 \
    -Wall -Wstrict-prototypes -I/usr/local/include/python2.6/ \
    -DPy_BUILD_CORE -o ctypes_segmfault.o ./ctypes_segmfault.c

gcc -pthread  -Xlinker -export-dynamic -o ctypes_segmfault \
    ctypes_segmfault.o \
    -lpython2.6 -lpthread -ldl  -lutil   -lm
[user at localhost debug]$ 
[user at localhost debug]$ cat import_ctypes.py 
import ctypes
[user at localhost debug]$

----------
assignee: theller
components: Interpreter Core, ctypes
files: ctypes_segmfault.c
messages: 107194
nosy: tanaga, theller
priority: normal
severity: normal
status: open
title: Segmentation error happens in Embedding Python.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17572/ctypes_segmfault.c

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

From report at bugs.python.org  Sun Jun  6 19:51:00 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 06 Jun 2010 17:51:00 +0000
Subject: [New-bugs-announce] [issue8918] distutils test failure on solaris:
	IOError: [Errno 2] No	such file or directory: '_configtest.i'
In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>
Message-ID: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>


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

OS = SunOS ginsu 5.10 Generic_125101-10 i86pc i386 i86pc
Python 2.7rc1

======================================================================
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/apy/rrun/tmp/autotest/apy/lib/python2.7/distutils/tests/test_config_cmd.py", line 46
, in test_search_cpp
    match = cmd.search_cpp(pattern='xxx', body='// xxx')
  File "/export/home/apy/rrun/tmp/autotest/apy/lib/python2.7/distutils/command/config.py", line 211, in search_cpp
    file = open(out)
IOError: [Errno 2] No such file or directory: '_configtest.i'

----------
assignee: tarek
components: Distutils, Tests
messages: 107196
nosy: srid, tarek
priority: normal
severity: normal
status: open
title: distutils test failure on solaris: IOError: [Errno 2] No such file or directory: '_configtest.i'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  6 19:56:24 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 17:56:24 +0000
Subject: [New-bugs-announce] [issue8919] python should read ~/.pythonrc.py
	by default
In-Reply-To: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>
Message-ID: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>


New submission from lesmana <lesmana at gmx.de>:

if started as an interactive session python should check for and read ~/.pythonrc.py by default.

furthermore there should be two options added:
--rcfile filename
this will read filename instead of ~/.pythonrc
--norc
this will prevent reading ~/.pythonrc

(this is inspired by how bash handles initialization)

afterwards the variable PYTHONSTARTUP can be deprecated.

as far as i know, everything which can be done by the variable PYTHONSTARTUP can be done with the suggested method. the advantage of the suggested method is that it is "intuitive" in the sense that it is the way most other tools do it (bash for example).

----------
messages: 107197
nosy: lesmana
priority: normal
severity: normal
status: open
title: python should read ~/.pythonrc.py by default
type: feature request

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

From report at bugs.python.org  Sun Jun  6 20:02:45 2010
From: report at bugs.python.org (lesmana)
Date: Sun, 06 Jun 2010 18:02:45 +0000
Subject: [New-bugs-announce] [issue8920] PYTHONSTARTUP should expand "~"
In-Reply-To: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>
Message-ID: <1275847365.81.0.275671627787.issue8920@psf.upfronthosting.co.za>


New submission from lesmana <lesmana at gmx.de>:

for example, this should be legal:
PYTHONSTARTUP="~/.pythonrc.py"

workaround (in bash)
PYTHONSTARTUP=$(echo ~)"/.pythonrc.py"

----------
messages: 107198
nosy: lesmana
priority: normal
severity: normal
status: open
title: PYTHONSTARTUP should expand "~"
type: feature request

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

From report at bugs.python.org  Sun Jun  6 20:02:53 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 06 Jun 2010 18:02:53 +0000
Subject: [New-bugs-announce] [issue8921] 2.7rc1: test_ttk failures on OSX
	10.4
In-Reply-To: <1275847373.81.0.425210704121.issue8921@psf.upfronthosting.co.za>
Message-ID: <1275847373.81.0.425210704121.issue8921@psf.upfronthosting.co.za>


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

Several test_ttk failures on OSX 10.4 (w/ Tcl/Tk 8.5 installed in /Library/Frameworks) and Python 2.7rc1

======================================================================
ERROR: test_tab_identifiers (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_ttk/test_widgets
.py", line 560, in test_tab_identifiers
    self.assertEqual(self.nb.tab('@5,5'), self.nb.tab('current'))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/ttk.py", line 922, in tab
    return _val_or_dict(kw, self.tk.call, self._w, "tab", tab_id)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/ttk.py", line 318, in _val
_or_dict
    res = func(*(args + options))
TclError: tab '@5,5' not found

======================================================================
FAIL: test_identify (test_ttk.test_widgets.WidgetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_ttk/test_widgets
.py", line 27, in test_identify
    self.assertEqual(self.widget.identify(5, 5), "label")
AssertionError: 'Button.button' != 'label'

======================================================================
FAIL: test_traversal (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_ttk/test_widgets
.py", line 721, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child1))
AssertionError: '.73168616' != '.73169536'

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

----------
assignee: ronaldoussoren
components: Macintosh, Tests, Tkinter
messages: 107199
nosy: ronaldoussoren, srid
priority: normal
severity: normal
status: open
title: 2.7rc1: test_ttk failures on OSX 10.4
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  6 20:23:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:23:57 +0000
Subject: [New-bugs-announce] [issue8922] Improve encoding shortcuts in
	PyUnicode_AsEncodedString()
In-Reply-To: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>
Message-ID: <1275848637.97.0.606582513318.issue8922@psf.upfronthosting.co.za>


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

PyUnicode_Decode() and PyUnicode_AsEncodedString() calls directly builtin decoders/encoders for some known encodings (eg. "utf-8"), instead of using the slow path (call PyCodec_Decode() / PyCodec_Encode()). 

PyUnicode_Decode() does normalize the encoding name: convert to lower and replace "_" by "-", as normalizestring() does. But PyUnicode_AsEncodedString() doesn't normalize the encoding name, it just use strcmp(). PyUnicode_Decode() has a shortcut for ISO-8859-1, whereas PyUnicode_AsEncodedString() doesn't (only for "latin-1").

Attached patch creates a subfunction (static) normalize_encoding(), use it in PyUnicode_Decode() and PyUnicode_AsEncodedString(), and adds a shortcut for ISO-8859-1 to PyUnicode_AsEncodedString().

----------
components: Unicode
files: unicode_shortcuts.patch
keywords: patch
messages: 107203
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Improve encoding shortcuts in PyUnicode_AsEncodedString()
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file17574/unicode_shortcuts.patch

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

From report at bugs.python.org  Sun Jun  6 20:28:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 18:28:41 +0000
Subject: [New-bugs-announce] [issue8923] Remove unused "errors" argument
	from	_PyUnicode_AsDefaultEncodedString()
In-Reply-To: <1275848921.87.0.52681950966.issue8923@psf.upfronthosting.co.za>
Message-ID: <1275848921.87.0.52681950966.issue8923@psf.upfronthosting.co.za>


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

_PyUnicode_AsDefaultEncodedString() has two arguments: unicode (input string) and errors. If errors is not NULL, it calls Py_FatalError()!

The argument is useful: all functions call it with errors=NULL.

Attached patch removes the argument.

----------
components: Unicode
files: unicode_errors.patch
keywords: patch
messages: 107204
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove unused "errors" argument from _PyUnicode_AsDefaultEncodedString()
versions: Python 3.2
Added file: http://bugs.python.org/file17575/unicode_errors.patch

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

From report at bugs.python.org  Sun Jun  6 21:01:52 2010
From: report at bugs.python.org (Peter Landgren)
Date: Sun, 06 Jun 2010 19:01:52 +0000
Subject: [New-bugs-announce] [issue8924] Error in error message in logging
In-Reply-To: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>
Message-ID: <1275850912.41.0.0811394159532.issue8924@psf.upfronthosting.co.za>


New submission from Peter Landgren <peter.talken at telia.com>:

This is in Windows.
I got an error message in Logging in my application Gramps.
However, there is an error message generated by by this logging, so the original message is never output.
The last line indicate a problem with bytes in certain positions. I was able to check it and it is the Swedish character "?".

The logging call is:
...
    except (IOError, OSError), msg:
        msg = unicode(str(msg), sys.getfilesystemencoding())
        LOG.error(_("Could not make database directory: ") + msg)
which results in:
3165: ERROR: clidbman.py: line 335: Kunde inte skapa databasmappen: [Error 3] Det g??r inte att hitta s??kv??ge
n: u'F:\\'

Traceback (most recent call last):
  File "C:\Python26\lib\logging\__init__.py", line 769, in emit
    msg = self.format(record)
  File "C:\Python26\lib\logging\__init__.py", line 649, in format
    return fmt.format(record)
  File "C:\Python26\lib\logging\__init__.py", line 448, in format
    s = s + record.exc_text
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 608-610: invalid data
4893: ERROR: gramps.py: line 138: Unhandled exception
Traceback (most recent call last):
  File "C:\Program Files (x86)\gramps\gui\grampsgui.py", line 353, in __startgramps
    "Error details: %s %s" % (repr(e), fn), exc_info=True)
  File "C:\Python26\lib\logging\__init__.py", line 1075, in error
    self._log(ERROR, msg, args, **kwargs)
  File "C:\Python26\lib\logging\__init__.py", line 1166, in _log
    self.handle(record)
  File "C:\Python26\lib\logging\__init__.py", line 1176, in handle
    self.callHandlers(record)
  File "C:\Python26\lib\logging\__init__.py", line 1213, in callHandlers
    hdlr.handle(record)
  File "C:\Python26\lib\logging\__init__.py", line 674, in handle
    self.emit(record)
  File "C:\Program Files (x86)\gramps\GrampsLogger\_GtkHandler.py", line 26, in emit
    ErrorView(error_detail=self,rotate_handler=self._rotate_handler)
  File "C:\Program Files (x86)\gramps\GrampsLogger\_ErrorView.py", line 39, in __init__
    self.draw_window()
  File "C:\Program Files (x86)\gramps\GrampsLogger\_ErrorView.py", line 94, in draw_window
    tb_label.get_buffer().set_text(self._error_detail.get_formatted_log())
  File "C:\Program Files (x86)\gramps\GrampsLogger\_GtkHandler.py", line 29, in get_formatted_log
    return self.format(self._record)
  File "C:\Python26\lib\logging\__init__.py", line 649, in format
    return fmt.format(record)
  File "C:\Python26\lib\logging\__init__.py", line 448, in format
    s = s + record.exc_text
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 608-610: invalid data

If I change line 448 in "C:\Python26\lib\logging\__init__.py" to:
    s = s + unicode(str(record.exc_text), sys.getfilesystemencoding())

I get the correct message:
4523: ERROR: grampsgui.py: line 353: Gramps terminated because of OS Error
Error details: WindowsError(3, 'Det g\xe5r inte att hitta s\xf6kv\xe4gen') F:\grdbtest\*.*
Traceback (most recent call last):
  File "C:\Program Files (x86)\gramps\gui\grampsgui.py", line 337, in __startgramps
    Gramps(argparser)
  File "C:\Program Files (x86)\gramps\gui\grampsgui.py", line 268, in __init__
    gui=True)
  File "C:\Program Files (x86)\gramps\cli\arghandler.py", line 81, in __init__
    self.dbman = CLIDbManager(self.dbstate)
  File "C:\Program Files (x86)\gramps\cli\clidbman.py", line 100, in __init__
    self._populate_cli()
  File "C:\Program Files (x86)\gramps\cli\clidbman.py", line 175, in _populate_cli
    for dpath in os.listdir(dbdir):
WindowsError: [Error 3] Det g??r inte att hitta s??kv??gen: u'F:\\grdbtest\\*.*'

(There is a secondary problem with rendering some characers. All strings were generated on a Windows system,
but I report using a Linux system.)

----------
components: Library (Lib)
messages: 107208
nosy: PeterL
priority: normal
severity: normal
status: open
title: Error in error message in logging
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun  6 21:03:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 19:03:55 +0000
Subject: [New-bugs-announce] [issue8925] Improve c-api/arg.rst: use "bytes"
	or "str" types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/c-api/arg.html is unclear about what is a "string".

Attached patch:
 - Use directly bytes, bytearray and str types
 - Replace "default encoding" by "``'utf-8'`` encoding"
 - Add bytes and/or bytearray to "... buffer compatible object" because it's not easy to understand what is a buffer compatible object, especially because there are different kind of buffer objects: read-only, read-write, pinned, etc.
 - Fix reST syntax ("..note ::")
 - Fix "es", "es#", "et" and "et#" formats: they doesn't accept "character buffer compatible object" (can someone double check that?)

Py_BuildValue(): I choosed to mark U and U# formats as deprecated alias to s/s# => see issue #8848.

I wrote the patch by reading getargs.c.

----------
assignee: docs at python
components: Documentation, Unicode
files: arg.patch
keywords: patch
messages: 107209
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"
versions: Python 3.2
Added file: http://bugs.python.org/file17576/arg.patch

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

From report at bugs.python.org  Sun Jun  6 21:11:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 19:11:10 +0000
Subject: [New-bugs-announce] [issue8926] getargs.c: release the buffer on
	error
In-Reply-To: <1275851470.16.0.472008534505.issue8926@psf.upfronthosting.co.za>
Message-ID: <1275851470.16.0.472008534505.issue8926@psf.upfronthosting.co.za>


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

PyArg_ParseTuple("t") calls PyObject_GetBuffer() and then raise an error if arg->ob_type->tp_as_buffer->bf_releasebuffer is not NULL. I think that it should call PyBuffer_Release(&view) before raising the error, or simply check bf_releasebuffer before calling PyObject_GetBuffer().

getbuffer() calls PyObject_GetBuffer() and then raise an error if the buffer is not contiguous. I think that it should call PyBuffer_Release() before the error.

Attached patch fixes both errors.

Tell me if I'm wrong :-)

----------
components: Interpreter Core
files: getarg_release.patch
keywords: patch
messages: 107210
nosy: haypo
priority: normal
severity: normal
status: open
title: getargs.c: release the buffer on error
versions: Python 3.2
Added file: http://bugs.python.org/file17577/getarg_release.patch

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

From report at bugs.python.org  Sun Jun  6 21:37:40 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 06 Jun 2010 19:37:40 +0000
Subject: [New-bugs-announce] [issue8927] Cannot handle complex requirement
	resolution
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

[This looks like a bug report against PIP because Tarek told me distutils2 would be responsible for this kind of thing and that there was an open ticket for it.  However, I can't find any such ticket so I'm posting it here]

Not only does pip not check for conflicts as noted in http://bitbucket.org/ianb/pip/src/tip/pip/req.py#cl-928, it doesn't consider any requirements on a package other than the first. So if I have

A requires B and C
B requires D<=1.1
C requires D<=0.9

installing A will give us D==1.1 rather than D==0.9

Once responsibility for this functionality is sorted out, we may be able to close this ticket or http://bitbucket.org/ianb/pip/issue/119

----------
assignee: tarek
components: Distutils2
messages: 107214
nosy: dabrahams, tarek
priority: normal
severity: normal
status: open
title: Cannot handle complex requirement resolution
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun  6 22:02:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 20:02:41 +0000
Subject: [New-bugs-announce] [issue8928] wininst: could not create key
In-Reply-To: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>
Message-ID: <1275854561.45.0.0117544967496.issue8928@psf.upfronthosting.co.za>


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

Projects that still support Python 2.4 are building distributions with either 2.4.x or 2.5.x versions, because they afraid that newer installers won't run on Windows XP or Windows 2000.

http://trac.edgewall.org/ticket/9404#comment:2

Unfortunately, these installers fail to create uninstall keys with an error like:
Could not create
    scons-py2.6
Could not set key value
    Python 2.6 SCons - a software construction tool
Could not set key value
    ...\Python26\Removescons.exe" -u ...

This is similar to http://bugs.python.org/issue600952 that was reported for Python 2.1 / 2.2 long ago.

http://scons.tigris.org/issues/show_bug.cgi?id=2533
http://trac.edgewall.org/attachment/ticket/9404/win7_install_warnings.png

----------
assignee: tarek
components: Distutils, Windows
messages: 107219
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: wininst: could not create key
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun  6 22:48:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 06 Jun 2010 20:48:29 +0000
Subject: [New-bugs-announce] [issue8929] wininst: msvcr90 dependency in x64
	build
In-Reply-To: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>
Message-ID: <1275857309.36.0.937792645197.issue8929@psf.upfronthosting.co.za>


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

Installers generated with x64 version of Python 2.6.5 seems to have msvcr90.dll dependency that may not be present on all platforms.

http://trac.edgewall.org/ticket/9404#comment:17

----------
assignee: tarek
components: Distutils
messages: 107227
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: wininst: msvcr90 dependency in x64 build
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun  7 00:08:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Jun 2010 22:08:37 +0000
Subject: [New-bugs-announce] [issue8930] messed up formatting after
	reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>


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

Some C code is incorrectly formatted after the Grand Indenting (TM). Take a gander at stringobject.c for an example.

----------
messages: 107240
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: messed up formatting after reindenting

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

From report at bugs.python.org  Mon Jun  7 01:07:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Jun 2010 23:07:15 +0000
Subject: [New-bugs-announce] [issue8931] '#' has no affect with 'c' type
In-Reply-To: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za>
Message-ID: <1275865635.78.0.716511257083.issue8931@psf.upfronthosting.co.za>


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

$ python3
Python 3.1.2 (release31-maint, May  3 2010, 22:18:46)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> format(ord("a"), "c")
'a'
>>> format(ord("a"), "#c")
'a'

I wonder if '#' with 'c' should raise an exception.

----------
assignee: eric.smith
components: Interpreter Core
messages: 107250
nosy: benjamin.peterson, eric.smith
priority: normal
severity: normal
status: open
title: '#' has no affect with 'c' type
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jun  7 16:18:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Jun 2010 14:18:31 +0000
Subject: [New-bugs-announce] [issue8932] test_capi fails --without-threads
In-Reply-To: <1275920311.66.0.668508833074.issue8932@psf.upfronthosting.co.za>
Message-ID: <1275920311.66.0.668508833074.issue8932@psf.upfronthosting.co.za>


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

test_capi fails when compiled --without-threads:

test test_capi failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nSystemError: error return without exception set\n[34135 refs]' != b'Fatal Python error: PyThreadState_Get: no current thread'

Re-running test test_capi in verbose mode
test_instancemethod (test.test_capi.CAPITest) ... ok
test_no_FatalError_infinite_loop (test.test_capi.CAPITest) ... FAIL

======================================================================
FAIL: test_no_FatalError_infinite_loop (test.test_capi.CAPITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nSystemError: error return without exception set\n[34135 refs]' != b'Fatal Python error: PyThreadState_Get: no current thread'

----------------------------------------------------------------------
Ran 2 tests in 0.635s

FAILED (failures=1)
test test_capi failed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 49, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nSystemError: error return without exception set\n[34135 refs]' != b'Fatal Python error: PyThreadState_Get: no current thread'

----------
components: Tests
keywords: buildbot
messages: 107267
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi fails --without-threads
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun  7 18:22:41 2010
From: report at bugs.python.org (Benjamin Liles)
Date: Mon, 07 Jun 2010 16:22:41 +0000
Subject: [New-bugs-announce] [issue8933] Invalid detection of metadata
	version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>


New submission from Benjamin Liles <benliles at gmail.com>:

The detection for metadata version does not follow what is specified in PEP 241 and PEP 314.

Specifically, the following fields are being sent as version 1.0 when they are not allowed as per PEP 241:

* Classifier
* Download-URL

----------
assignee: tarek
components: Distutils
messages: 107268
nosy: benliles, tarek
priority: normal
severity: normal
status: open
title: Invalid detection of metadata version
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Jun  7 20:56:05 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 07 Jun 2010 18:56:05 +0000
Subject: [New-bugs-announce] [issue8934] aifc should use str instead of
	bytes (wave, sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>


New submission from Thomas Jollans <thomas at jollans.com>:

aifc getcomptype() and setcomptype() use bytes while the corresponding methods in the sunau and wave modules use str (b'NONE', b'ULAW' vs 'NONE', 'ULAW'). This means that programmers wanting simple format-agnostic audio file output will have to special-case aifc. This was not necessary in Python 2.x, where all three modules used str (obviously). IMHO, there is no reason for this incompatibility.

The solution I propose is to change aifc to use unicode str for "information" strings and bytes for raw data only, like the other two modules. This is, the way I see it, the most sensible behaviour.

I'm attaching a patch that does just this: it changes aifc to use str for all (non-data) strings: comptype, compname, and markers. I've also changed the testcase accordingly.

The problem is, obviously, that this could break existing code. I doubt that it would break a lot of code since:
 - not that many people use aifc anyway (I think), and py3k is still
   young
 - py3k code that's out there now would most likely handle both
   scenarios anyway to account for the wave and sunau modules
 - setcomptype() would still accept bytes.

On the other hand, it would, as I said, simplify writing format-agnostic code. Special-casing any module wouldn't have been necessary with Python 2, why should Python 3 be any different?

There, I've made my case. Georg, I put you on the nosy list because of
  [svn r64023] Remove cl usage from aifc and use bytes throughout.
You, apparently, made the decision I'm arguing should be reverted, if indeed anyone consciously made it at all.

If this is applied, it would have to be properly documented, of course.

----------
components: Library (Lib)
files: aifc_use_str.diff
keywords: patch
messages: 107274
nosy: georg.brandl, tjollans
priority: normal
severity: normal
status: open
title: aifc should use str instead of bytes (wave, sunau compatibility)
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17583/aifc_use_str.diff

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

From report at bugs.python.org  Tue Jun  8 02:58:40 2010
From: report at bugs.python.org (Stan Klein)
Date: Tue, 08 Jun 2010 00:58:40 +0000
Subject: [New-bugs-announce] [issue8935] Syntax error in os.py
In-Reply-To: <1275958720.19.0.807704526769.issue8935@psf.upfronthosting.co.za>
Message-ID: <1275958720.19.0.807704526769.issue8935@psf.upfronthosting.co.za>


New submission from Stan Klein <sklein at cpcug.org>:

I got the following traceback on an "import os" statement:


Traceback (most recent call last):
  File "setup.py", line 53, in ?
    import traceback
  File "/usr/lib/python2.6/traceback.py", line 3, in ?
    import linecache
  File "/usr/lib/python2.6/linecache.py", line 9, in ?
    import os
  File "/usr/lib/python2.6/os.py", line 758
    bs = b""
           ^
SyntaxError: invalid syntax

>From looking at 2.4, the fix is probably bs=""

----------
components: Library (Lib)
messages: 107294
nosy: sklein
priority: normal
severity: normal
status: open
title: Syntax error in os.py
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun  8 05:46:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 03:46:41 +0000
Subject: [New-bugs-announce] [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>


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

webbrowser.open("127.0.0.1:8080") opens page in IE even if default system browser is Chrome.

----------
components: Library (Lib), Windows
messages: 107297
nosy: techtonik
priority: normal
severity: normal
status: open
title: webbrowser regression on windows
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  8 07:38:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 05:38:54 +0000
Subject: [New-bugs-announce] [issue8937] SimpleHTTPServer should contain
	usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>


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

Currently SimpleHTTPServer docs contains phrase "For example usage, see the implementation of the test() function." with no reference where this test() function is located. This is not user friendly.

----------
assignee: docs at python
components: Documentation
messages: 107304
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: SimpleHTTPServer should contain usage example
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  8 13:34:32 2010
From: report at bugs.python.org (Pavel Denisow)
Date: Tue, 08 Jun 2010 11:34:32 +0000
Subject: [New-bugs-announce] [issue8938] Mac OS  dialogs(Save As...,
	Load) translation
In-Reply-To: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>
Message-ID: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>


New submission from Pavel Denisow <denisov at ext.panasonic.ru>:

We have a problem with using native Mac OS dialogs (Save As..., Load) on Russian Mac:
Dialogs are not translated even with file-translation. See attached screenshots.
Same code in Linux works perfect. C++ QT project in Mac has translation in native dialogs.
Test project on python and PyQT contains not-translated dialogs.
For tk and EasyDialogs result is the same - not translated.

Mac OS: 10.5.2, Russian locale.
Python: 2.5.1


PyQt test project
----------------------------------------
from PyQt4 import QtGui, QtCore


app = QtGui.QApplication(sys.argv)

QtGui.QFileDialog().getSaveFileName()
QtGui.QFileDialog().getOpenFileName()

sys.exit(app.exec_())
----------------------------------------




tk test project
----------------------------------------
from tkCommonDialog import Dialog


class OpenDialog(Dialog):
    command = "tk_getOpenFile"
class SaveDialog(Dialog):
    command = "tk_getSaveFile"


OpenDialog().show()
SaveDialog().show()
----------------------------------------



EasyDialogs test project
----------------------------------------
import EasyDialogs

EasyDialogs.AskFileForSave()
EasyDialogs.AskFileForOpen()
----------------------------------------

----------
assignee: ronaldoussoren
components: Macintosh, Unicode
files: filedialogs_mac.zip
messages: 107314
nosy: Pavel.Denisow, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac OS  dialogs(Save As..., Load) translation
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file17588/filedialogs_mac.zip

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

From report at bugs.python.org  Tue Jun  8 15:14:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 13:14:36 +0000
Subject: [New-bugs-announce] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>


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

Following r81811 (and issue8925), perhaps we should start using e.g. PyUnicode, PyBytes, PyLong, etc. in the C API docs to more closely follow the C API rather than use the type names you see at the Python level.

----------
assignee: haypo
components: Documentation
messages: 107320
nosy: haypo, lemburg, pitrou
priority: normal
severity: normal
status: open
title: Use C type names (PyUnicode etc;) in the C API docs
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun  8 15:23:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 13:23:16 +0000
Subject: [New-bugs-announce] [issue8940] *HTTPServer need a summary page
	with API inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>


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

The abundance of methods and hierarchy depth of various servers from "Internet Protocols and Support" section makes it extremely hard to navigate information. You need a strong OOP background to be able to use this doc effectively, as examples are not intuitive otherwise.

Usually you need a decent IDE (such as Eclipse) to get a picture of class hierarchy and a table of all available methods with a mark where they were inherited from.

Such table (at least Class Hierarchy view screenshot from Eclipse) should be available in reference for descendant classes.

----------
assignee: docs at python
components: Documentation
messages: 107321
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: *HTTPServer need a summary page with API inheritance table
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun  8 18:15:24 2010
From: report at bugs.python.org (Dave Opstad)
Date: Tue, 08 Jun 2010 16:15:24 +0000
Subject: [New-bugs-announce] [issue8941] utf-32be codec failing on 16-bit
	python build for 32-bit	value
In-Reply-To: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>
Message-ID: <1276013724.21.0.174818104611.issue8941@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

The utf-32 little-endian codec works fine, but the big-endian codec is producing incorrect results:

Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b'\x00\x00\x01\x00', 'utf-32le') # works
'\U00010000'
>>> str(b'\x00\x01\x00\x00', 'utf-32be') # doesn't work
'\ud800\x02'

----------
components: Unicode
messages: 107326
nosy: opstad
priority: normal
severity: normal
status: open
title: utf-32be codec failing on 16-bit python build for 32-bit value
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun  8 18:15:32 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 08 Jun 2010 16:15:32 +0000
Subject: [New-bugs-announce] [issue8942] __path__ attribute of modules
	loaded by zipimporter is	untested
In-Reply-To: <1276013732.57.0.515191754786.issue8942@psf.upfronthosting.co.za>
Message-ID: <1276013732.57.0.515191754786.issue8942@psf.upfronthosting.co.za>


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

Packages loaded from zip files have a __path__ sort of like any other package.  The zipimport tests don't verify that this attribute has the correct value, though.

----------
components: Tests
messages: 107327
nosy: exarkun
priority: normal
severity: normal
status: open
title: __path__ attribute of modules loaded by zipimporter is untested

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

From report at bugs.python.org  Tue Jun  8 18:24:23 2010
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 08 Jun 2010 16:24:23 +0000
Subject: [New-bugs-announce] [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

Unable to pickle classes used in the InteractiveConsole. The code attached works in python 2.5 and fails on python 3.1.2.

----------
components: Library (Lib)
files: fast_test.py
messages: 107328
nosy: fabioz
priority: normal
severity: normal
status: open
title: Bug in InteractiveConsole
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17589/fast_test.py

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

From report at bugs.python.org  Tue Jun  8 20:57:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Jun 2010 18:57:13 +0000
Subject: [New-bugs-announce] [issue8944]
	test_winreg.test_reflection_functions fails on Windows	Server 2003
In-Reply-To: <1276023433.0.0.59191647284.issue8944@psf.upfronthosting.co.za>
Message-ID: <1276023433.0.0.59191647284.issue8944@psf.upfronthosting.co.za>


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

The key/subkey used in this test causes a failure when run on Windows Server 2003 x64.

----------
assignee: brian.curtin
components: Tests, Windows
messages: 107337
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_winreg.test_reflection_functions fails on Windows Server 2003
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jun  8 21:10:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Jun 2010 19:10:45 +0000
Subject: [New-bugs-announce] [issue8945] Bug in **kwds expansion on call?
In-Reply-To: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>
Message-ID: <1276024245.06.0.703861128554.issue8945@psf.upfronthosting.co.za>


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

In 2.6, the requirement for **kwds keyword argument expansion in calls (LangRef 5.3.4. Calls) is relaxed from "(subclass of) dictionary" (2.5) to "mapping".  The requirement in this context for 'mapping' is not specified. LRef3.2 merely says "The subscript notation a[k]  selects the item indexed by k from the mapping a;". Here, .keys seems to be needed in addition to .__getitem__. (.items alone does not make an object a mapping.)

In python-list thread "Which objects are expanded by double-star ** operator?", Peter Otten posted 2.6 results for

class A(object):
     def keys(self): return list("ab")
     def __getitem__(self, key):
         return 42
        
class B(dict):
     def keys(self): return list("ab")
     def __getitem__(self, key):
         return 42

def f(**kw):
     print(kw)

f(**A())
# {'a': 42, 'b': 42}

b = B(); print(b['a'], b['b']) # I added this
# 42, 42
f(**b)
# {}

I get same with 3.1. It appears .keys() is called in the first case, but not the second, possibly due to an internal optimization.

The different of outcome seems like a bug, though one could argue that the doc is so vague that it makes no promise to be broken.

----------
components: Interpreter Core
messages: 107338
nosy: tjreedy
priority: normal
severity: normal
status: open
title: Bug in **kwds expansion on call?
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun  8 22:25:46 2010
From: report at bugs.python.org (Dave Opstad)
Date: Tue, 08 Jun 2010 20:25:46 +0000
Subject: [New-bugs-announce] [issue8946] PyBuffer_Release signature in 3.1
	documentation is	incorrect
In-Reply-To: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>
Message-ID: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

According to the 3.1 documentation, the prototype for PyBuffer_Release is:

void PyBuffer_Release(PyObject *obj, Py_buffer *view);

However, abstract.h has this prototype:

PyAPI_FUNC(void) PyBuffer_Release(Py_buffer *view);

The documentation's reference to "obj" should be removed.

----------
assignee: docs at python
components: Documentation
messages: 107342
nosy: docs at python, opstad
priority: normal
severity: normal
status: open
title: PyBuffer_Release signature in 3.1 documentation is incorrect
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun  8 22:51:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 20:51:08 +0000
Subject: [New-bugs-announce] [issue8947] Provide as_integer_ratio() method
	to Decimal
In-Reply-To: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>
Message-ID: <1276030268.17.0.98739433208.issue8947@psf.upfronthosting.co.za>


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

Here is my use case: recently implemented timedelta * float operation starts with converting float to an int ratio.  The same algorithm can be used for decimals, but they don't support as_integer_ratio().

----------
components: Extension Modules
messages: 107345
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Provide  as_integer_ratio() method to Decimal
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  8 22:55:25 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 08 Jun 2010 20:55:25 +0000
Subject: [New-bugs-announce] [issue8948] cleanup functions are not executed
	with	unittest.TestCase.debug()
In-Reply-To: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>
Message-ID: <1276030525.65.0.633421030518.issue8948@psf.upfronthosting.co.za>


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

Also class / module tearDowns are not executed with TestSuite.debug()

----------
assignee: michael.foord
components: Library (Lib)
messages: 107346
nosy: michael.foord
priority: normal
severity: normal
status: open
title: cleanup functions are not executed with unittest.TestCase.debug()
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jun  8 23:23:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 21:23:23 +0000
Subject: [New-bugs-announce] [issue8949] PyArg_Parse*(): "z" should not
	accept bytes
In-Reply-To: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>
Message-ID: <1276032203.54.0.364398342729.issue8949@psf.upfronthosting.co.za>


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

"z" is supposed to be the same format than "s" but accepts None.... Except that "z" does also accept bytes. I suppose that "s" was "fixed" between Python2 and Python3, but "z" is not fixed yet.

I think that it can be fixed in Python 3.2 without any deprecation process.

----------
components: Interpreter Core
messages: 107351
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*(): "z" should not accept bytes
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun  8 23:42:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jun 2010 21:42:48 +0000
Subject: [New-bugs-announce] [issue8950] In getargs.c,
	make 'L' code raise TypeError for float arguments.
In-Reply-To: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>
Message-ID: <1276033368.49.0.876712618605.issue8950@psf.upfronthosting.co.za>


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

Currently all but one of the integer format codes for getargs.c raise TypeError when passed a float.  The 'L' code produces a warning rather than raising an error.

This was deliberate at the time, because all except the 'L' code already raised a DeprecationWarning in Python 3.1, and were converted to raise TypeError for 3.2.  Since the 'L' code didn't raise a warning for float inputs in 3.1, directly raising a TypeError in 3.2 seemed a bit abrupt.

However, I'd like to revisit this decision, and make the 'L' code raise a TypeError in 3.2.  Note that

(1) The 'L' code represents the Py_LONG_LONG type, and isn't used very much;  I think the risk of unexpected breakage from this change is fairly small.

(2) One of the places that the 'L' code *is* used is when parsing strange C types (like off_t) that are matched with either size_t, long or long long at configure + build time.  So one platform might end up parsing off_t types with the 'n' code, while another parses them with the 'L' code.  It would be desirable for both platforms to have the same behaviour when passed a float.

Any objections to making this change?

See also issue 5080.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 107352
nosy: haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: In getargs.c, make 'L' code raise TypeError for float arguments.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun  9 00:11:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:11:05 +0000
Subject: [New-bugs-announce] [issue8951] PyArg_Parse*(): factorize code of
	's' and 'z' formats, and 'u' and 'Z' formats
In-Reply-To: <1276035065.31.0.617634960026.issue8951@psf.upfronthosting.co.za>
Message-ID: <1276035065.31.0.617634960026.issue8951@psf.upfronthosting.co.za>


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

Code of 's' and 'z' formats is *mostly* the same... except a bug (#8949).

Code of 'u' and 'Z' formats can also easily be factorized.

I don't really understand why the code was duplicated.

----------
components: Interpreter Core
files: factorize_getargs_sz_uZ.patch
keywords: patch
messages: 107356
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' formats
versions: Python 3.2
Added file: http://bugs.python.org/file17592/factorize_getargs_sz_uZ.patch

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

From report at bugs.python.org  Wed Jun  9 12:34:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 10:34:48 +0000
Subject: [New-bugs-announce] [issue8952] Doc/c-api/arg.rst: fix
	documentation of number formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>


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

The documentation of PyArg_Parse*() number formats specify that only int / float / complex are accepted, whereas any int / float / complex compatible object is accepted. "compatible" means that it has an __int__() / __float__() / __complex__() method, or nb_int / nb_float of Py_TYPE(obj)->tp_as_number->nb_int is defined (tp_as_number has no nb_complex).

I suppose that the following paragraph is also outdated:

"It is possible to pass "long" integers (integers whose value exceeds the
 platform's :const:`LONG_MAX`) however no proper range checking is done --- the
 most significant bits are silently truncated when the receiving field is too
 small to receive the value (actually, the semantics are inherited from downcasts
 in C --- your mileage may vary)."

Moreover, "without overflow checking" should be explained (Mark told me that the number is truncated to a power of 2).

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 107379
nosy: docs at python, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Doc/c-api/arg.rst: fix documentation of number formats
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun  9 15:07:45 2010
From: report at bugs.python.org (Jean Jordaan)
Date: Wed, 09 Jun 2010 13:07:45 +0000
Subject: [New-bugs-announce] [issue8953] Syntax error
	in	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>


New submission from Jean Jordaan <jean.jordaan at gmail.com>:

http://docs.python.org/library/decimal.html#recipes
has this code: 

    for i in range(places):
        build(next() if digits else '0')

Mismatched parenthesis.

----------
assignee: docs at python
components: Documentation
messages: 107396
nosy: Jean.Jordaan, docs at python
priority: normal
severity: normal
status: open
title: Syntax error in http://docs.python.org/library/decimal.html#recipes
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun  9 16:20:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 09 Jun 2010 14:20:44 +0000
Subject: [New-bugs-announce] [issue8954] wininst regression: errors when
	building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>


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

2.5.1 version of distutils was able to correctly build wininst dists from linux. Right now there are errors which I'll describe in more details once I can get some Linux box.

----------
assignee: tarek
components: Distutils
messages: 107398
nosy: tarek, techtonik
priority: normal
severity: normal
status: open
title: wininst regression: errors when building on linux
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun  9 17:44:15 2010
From: report at bugs.python.org (James)
Date: Wed, 09 Jun 2010 15:44:15 +0000
Subject: [New-bugs-announce] [issue8955] import doesn't notice changes to
	working directory
In-Reply-To: <1276098255.67.0.264247838489.issue8955@psf.upfronthosting.co.za>
Message-ID: <1276098255.67.0.264247838489.issue8955@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Attempting to change the working directory and then import based on that change has no effect. Import seems impossible. Attached is tarball example. As seen below, bar1.py can import foo from src, however bar2.py bar3.py and bar4.py cannot, despite their respective scripts changing their cwd. Below is results of a terminal session. Thanks in advance.

james at hostname:~$ tree import_bug/
import_bug/
|-- bar1.py
|-- __init__.py
|-- src
|   |-- foo.py
|   `-- __init__.py
`-- test
    |-- bar2.py
    |-- bar3.py
    |-- bar4.py
    |-- bar5.py
    `-- __init__.py

2 directories, 9 files
james at hostname:~$ cat import_bug/src/foo.py 
# this is foo.py
print('this is foo.py')

james at hostname:~$ cat import_bug/bar1.py 
# this is bar1.py
import os



print(os.getcwd())
from src import foo
print('this is bar1.py')

james at hostname:~$ cat import_bug/test/bar2.py 
# this is bar2.py
import os

os.chdir(os.path.join(os.path.dirname(__file__), os.pardir))

print(os.getcwd())
from src import foo
print('this is bar2.py')

james at hostname:~$ python import_bug/bar1.py 
/home/james
this is foo.py
this is bar1.py
james at hostname:~$ python import_bug/test/bar2.py 
/home/james/import_bug
Traceback (most recent call last):
  File "import_bug/test/bar2.py", line 7, in <module>
    from src import foo
ImportError: No module named src
james at hostname:~$

----------
components: Library (Lib)
files: import_bug.tar
messages: 107403
nosy: purpleidea
priority: normal
severity: normal
status: open
title: import doesn't notice changes to working directory
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file17600/import_bug.tar

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

From report at bugs.python.org  Wed Jun  9 20:25:36 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Jun 2010 18:25:36 +0000
Subject: [New-bugs-announce] [issue8956] Incorrect ValueError message
	for	subprocess.Popen.send_signal() on Windows
In-Reply-To: <1276107936.75.0.980203852578.issue8956@psf.upfronthosting.co.za>
Message-ID: <1276107936.75.0.980203852578.issue8956@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

def send_signal(self, sig):
            """Send a signal to the process
            """
            if sig == signal.SIGTERM:
                self.terminate()
            elif sig == signal.CTRL_C_EVENT:
                os.kill(self.pid, signal.CTRL_C_EVENT)
            elif sig == signal.CTRL_BREAK_EVENT:
                os.kill(self.pid, signal.CTRL_BREAK_EVENT)
            else:
                raise ValueError("Only SIGTERM is supported on Windows")


Just noticed right now while I was reading subprocess source code.
I guess that should be "Only SIGTERM, CTRL_C_EVENT or CTRL_BREAK_EVENT are supported on Windows".

----------
components: Library (Lib)
messages: 107408
nosy: astrand, giampaolo.rodola
priority: normal
severity: normal
status: open
title: Incorrect ValueError message for subprocess.Popen.send_signal() on Windows
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jun  9 22:24:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Jun 2010 20:24:40 +0000
Subject: [New-bugs-announce] [issue8957] strptime('%c',
	..) fails to parse output of strftime('%c',
	..) in non-English locale
In-Reply-To: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>
Message-ID: <1276115080.37.0.388300880324.issue8957@psf.upfronthosting.co.za>


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

The following code:

import locale, time
locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8")
t = time.localtime()
s = time.strftime('%c', t)
time.strptime('%c', s)

Raises

ValueError: time data '%c' does not match format 'Mer  9 jui 16:14:46 2010'

in any locale where month follows day in '%c' format.  Note that attached C code works as expected on my OSX laptop.

I wonder it it would make sense to call platform strptime where available? I wonder if platform support for strptime has improved since 2002 when _strptime.py was introduced.

----------
assignee: belopolsky
components: Extension Modules
files: strptime-locale-bug.c
messages: 107413
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: strptime('%c', ..) fails to parse output of strftime('%c', ..) in non-English locale
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17601/strptime-locale-bug.c

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

From report at bugs.python.org  Wed Jun  9 23:20:55 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 09 Jun 2010 21:20:55 +0000
Subject: [New-bugs-announce] [issue8958] 2.7rc1 tarfile.py:
	`bltn_open(targetpath, "wb")` -> IOError: Is a directory
In-Reply-To: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>
Message-ID: <1276118455.66.0.211402542637.issue8958@psf.upfronthosting.co.za>


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

1. Find an OSX 10.5.8 machine 
2. wget http://hntool.googlecode.com/files/hntool-0.1.1.tar.gz
3. $ python2.7 -c "import tarfile as T; t=T.open('hntool-0.1.1.tar.gz'); t.extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2159, in _extract_member
    self.makefile(tarinfo, targetpath)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tarfile.py", line 2198, in makefile
    target = bltn_open(targetpath, "wb")
IOError: [Errno 21] Is a directory: './hntool-0.1.1/hntool'

...


Note that, when extracted open via other tools, hntool-0.1.1.tar.gz contains within it ... both a directory named "HnTool" (note the case) and a file  called "hntool".

----------
components: Library (Lib)
messages: 107419
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7rc1 tarfile.py: `bltn_open(targetpath, "wb")` -> IOError: Is a directory
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 10 09:05:59 2010
From: report at bugs.python.org (Michael Curran)
Date: Thu, 10 Jun 2010 07:05:59 +0000
Subject: [New-bugs-announce] [issue8959] WINFUNCTYPE wrapped ctypes
	callbacks not functioning	correctly in Python 2.7
In-Reply-To: <1276153559.93.0.766128008061.issue8959@psf.upfronthosting.co.za>
Message-ID: <1276153559.93.0.766128008061.issue8959@psf.upfronthosting.co.za>


New submission from Michael Curran <mick at nvaccess.org>:

There seem to be problems with WINFUNCTYPE callbacks causing exceptions, and or getting their return value ignored by the caller, when using Python 2.7 rc1.
Two examples provided.

Example 1:
Providing a WINFUNCTYPE wrapped python function when calling EnumWindows from user32.dll with ctypes, EnumWindows enumerates (calls the python function) for the first 5 windows and then causes a WindowsError, sometimes an access violation (reading, or writing), or even other strange unknown exceptions.
This specific testcase is attached to the bug.
Run this script in  Python 2.7 you should see the WindowsErrors. On Python 2.6 it successfully enumerates through all windows.

Example 2:
Hooking low-level keyboard input in Windows with SetWindowsHookEx from user32.dll, providing a WINFUNCTYPE wrapped python function as the callback, and then typing some keys, causes the callback to be called but the return value is always ignored, which means the hook never blocks keys completely, even if  the value 1 is returned from the callback, to do so.
Again, a testcase is attached to the bug.
Run this script in Python. It will ask you to type some characters and press enter. On Python 2.6 no characters should be echoed to the screen, but you will hear beeps to let you know the keyboard hook is seeing the keys. On Python 2.7, the keys will be echoed to the screen, and you will also hear the beeps (meaning that the hook was seeing the keys, but was unable to actually block them -- its return value was being ignored).
Also in Python 2.7, after the quit message is sent to the hook thread, GetMessageW (in user32.dll) causes a WindowsError exception. This does not happen on Python 2.6.

Perhaps it may be related to this entry in the Python 2.7 What's new:
The underlying libffi library has been updated to version 3.0.9, containing various fixes for different platforms. (Updated by Matthias Klose; issue 8142.)

----------
assignee: theller
components: ctypes
files: test_callbackRetval.py
messages: 107447
nosy: mdcurran, theller
priority: normal
severity: normal
status: open
title: WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file17604/test_callbackRetval.py

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

From report at bugs.python.org  Thu Jun 10 14:49:33 2010
From: report at bugs.python.org (=?utf-8?q?Vojt=C4=9Bch_Rylko?=)
Date: Thu, 10 Jun 2010 12:49:33 +0000
Subject: [New-bugs-announce] [issue8960] 2.6 README
In-Reply-To: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>
Message-ID: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>


New submission from Vojt?ch Rylko <vojta.rylko at seznam.cz>:

In 2.6 README are this paragraphs from 2.5 README:

A number of features are not supported in Python 2.5 anymore. Some
support code is still present, but will be removed in Python 2.6. 

The following systems are still supported in Python 2.5, but
support will be dropped in 2.6:
- Systems using --with-wctype-functions
- Win9x, WinME

Following Microsoft's closing of Extended Support for
Windows 98/ME (July 11, 2006), Python 2.6 will stop
supporting these platforms.

----------
assignee: docs at python
components: Documentation
messages: 107458
nosy: docs at python, vojta.rylko
priority: normal
severity: normal
status: open
title: 2.6 README
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 10 15:57:36 2010
From: report at bugs.python.org (=?utf-8?b?VGFtw6FzIEd1bMOhY3Np?=)
Date: Thu, 10 Jun 2010 13:57:36 +0000
Subject: [New-bugs-announce] [issue8961] compile Python-2.7rc1 on AIX 5.3
	with xlc_r
In-Reply-To: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>
Message-ID: <1276178256.7.0.316939316511.issue8961@psf.upfronthosting.co.za>


New submission from Tam?s Gul?csi <gt-dev at gthomas.homelinux.org>:

I'm trying to compile Python2.7rc1 on AIX 5.3 with the following call:
FW=/home/kobe/kobed/tgulacsi/freeware
CC='xlc_r -q64' CXX='xlC_r -q64' AR='ar -X64' NM='nm -X64' LD='ld -X64' \
LD_LIBRARY_PATH=$FW/lib:$LD_LIBRARY_PATH \
  ./configure -C --without-gcc \
  CFLAGS="-DHAVE_BROKEN_POSIX_SEMAPHORES -I$FW/include" \
  LDFLAGS='-L$FW/lib' \
  ARFLAGS='cru' \
  --prefix=$FW

make

The result is attached, as I see sysconfig.get_config_var doesn't have CONFIG_ARGS set.

Thanks in advance,
Tam?s Gul?csi

----------
components: Build
files: python-2.7rc1-aix5.3.log
messages: 107460
nosy: tgulacsi
priority: normal
severity: normal
status: open
title: compile Python-2.7rc1 on AIX 5.3 with xlc_r
versions: Python 2.7
Added file: http://bugs.python.org/file17606/python-2.7rc1-aix5.3.log

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

From report at bugs.python.org  Thu Jun 10 18:21:05 2010
From: report at bugs.python.org (Caitlin Kavanaugh)
Date: Thu, 10 Jun 2010 16:21:05 +0000
Subject: [New-bugs-announce] [issue8962] IOError: [Errno 13] permission
	denied
In-Reply-To: <1276186865.91.0.457294354342.issue8962@psf.upfronthosting.co.za>
Message-ID: <1276186865.91.0.457294354342.issue8962@psf.upfronthosting.co.za>


New submission from Caitlin Kavanaugh <cnkavanaugh at gmail.com>:

Hi, I'm new to python, so I'm sorry if my explanation is terribly concise, I'm trying to explain it with fairly limited terminology.

I have been attempting to write data out to a file, yet I continually receive the error:

IOError: [Errno 13] permission denied '/trained.nn'

No matter where or what I try to save the file as, it returns this error with the corresponding file name. My friend insists that I need to use a slash, yet I'm not sure this is the correct syntax. Otherwise, I'm absolutely lost in how to solve this.

I tried looking up possible solutions first, but either the terminology was beyond me, or they supplied a piece of code that could fix it. I don't really want a plug and chug solution. I really want to understand this, so any explanation would be greatly appreciated.

Thank you!

----------
components: Windows
messages: 107463
nosy: Caitlin.Kavanaugh
priority: normal
severity: normal
status: open
title: IOError: [Errno 13] permission denied
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 10 21:07:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jun 2010 19:07:19 +0000
Subject: [New-bugs-announce] [issue8963] test_urllibnet failure
In-Reply-To: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>
Message-ID: <1276196839.19.0.231590602267.issue8963@psf.upfronthosting.co.za>


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

This test failure just happened to me on a py3k checkout:

test test_urllibnet failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_urllibnet.py", line 191, in test_data_header
    time.strptime(datevalue, dateformat)
  File "/home/antoine/py3k/debug/Lib/_strptime.py", line 461, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/home/antoine/py3k/debug/Lib/_strptime.py", line 332, in _strptime
    (data_string, format))
ValueError: time data 'Thu, 10 Jun 2010 19:03:39 GMT' does not match format '%a, %d %b %Y %H:%M:%S GMT'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_urllibnet.py", line 193, in test_data_header
    self.fail('Date value not in %r format', dateformat)
TypeError: fail() takes at most 2 arguments (3 given)

----------
assignee: orsenthil
components: Library (Lib), Tests
messages: 107470
nosy: belopolsky, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_urllibnet failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 10 23:11:35 2010
From: report at bugs.python.org (Frederic Torres)
Date: Thu, 10 Jun 2010 21:11:35 +0000
Subject: [New-bugs-announce] [issue8964] Method _sys_version() module
	Lib\platform.py does parse	correctly IronPython 2.x version
In-Reply-To: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>
Message-ID: <1276204295.1.0.731236969654.issue8964@psf.upfronthosting.co.za>


New submission from Frederic Torres <fredericaltorres at gmail.com>:

Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version

The format of sys.version now start with a version number and (
2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)

File:     Lib\platform.py
Function: def _sys_version(sys_version=None):
Line:     1326

----------
components: Library (Lib)
messages: 107487
nosy: fredericaltorres, lemburg
priority: normal
severity: normal
status: open
title: Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 11 00:39:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Jun 2010 22:39:39 +0000
Subject: [New-bugs-announce] [issue8965] test_imp fails on OSX when LANG is
	set
In-Reply-To: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>
Message-ID: <1276209579.85.0.692160054001.issue8965@psf.upfronthosting.co.za>


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

$ LANG=C ./python.exe -m test.regrtest test_imp
test_imp
test test_imp failed -- Traceback (most recent call last):
  File "Lib/test/test_imp.py", line 109, in test_issue5604
    self.assertEqual(fs_encoding, 'utf-8')
AssertionError: 'ascii' != 'utf-8'
- ascii+ utf-8

1 test failed:
    test_imp


Same with LC_ALL=C.  Passes on Linux.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 107498
nosy: belopolsky, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_imp fails on OSX when LANG is set
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 11 01:03:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jun 2010 23:03:27 +0000
Subject: [New-bugs-announce] [issue8966] ctypes: remove implicit conversion
	between unicode and	bytes
In-Reply-To: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>
Message-ID: <1276211007.74.0.406425558952.issue8966@psf.upfronthosting.co.za>


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

ctypes doesn't have strict separation between bytes and characters, whereas Python3 splitted str/unicode of Python2 into bytes/str which a strict separation. The result is that sometimes it works (no error), sometimes it fails (the first time that the user inserts a non-ASCII character).

I wrote 3 patches:
 - ctypes_s_set.patch: fix s_set(), return an unicode string instead of a bytes string
 - ctypes_conversion.patch: remove ctypes.set_conversion_mode() and all code using it (remove the implicit conversions)
 - ctypes_tests.patch: fix all tests according the changes introduced by the two previous patches

ctypes_s_set.patch is trivial and fixes a real bug. ctypes_conversion.patch does basically remove code. ctypes_tests.patch is the biggest part because the test suite is mostly based on the implicit conversion.

Except the parts removing the calls to ctypes.set_conversion_mode() and the tests testing the implicit conversion, ctypes_tests.patch can be commited alone because it improves the test suite (use the right types).

----------
assignee: theller
components: Unicode, ctypes
files: ctypes_conversion.patch
keywords: patch
messages: 107499
nosy: haypo, theller
priority: normal
severity: normal
status: open
title: ctypes: remove implicit conversion between unicode and bytes
versions: Python 3.2
Added file: http://bugs.python.org/file17610/ctypes_conversion.patch

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

From report at bugs.python.org  Fri Jun 11 02:09:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:09:15 +0000
Subject: [New-bugs-announce] [issue8967] Create PyErr_GetWindowsMessage()
	function
In-Reply-To: <1276214955.6.0.858876193041.issue8967@psf.upfronthosting.co.za>
Message-ID: <1276214955.6.0.858876193041.issue8967@psf.upfronthosting.co.za>


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

PyErr_SetExcFromWindowsErrWithFilenameObject() and PyErr_SetFromErrnoWithFilenameObject() have the same code to read the localized error message. The code can be factorized in a new function PyErr_GetWindowsMessage().

About the patch:
 - free s_buf just after the call to PyUnicode_FromUnicode(), don't wait until the end of the function
 - free s_buf if s_buf is not NULL and len==0. I suppose that this case is impossible, if len==0, s_buf is set to NULL or leaved unchanged (so it's also equal to NULL)

I wrote the function to raise an UnicodeDecodeError with a Windows error message.

----------
components: Interpreter Core, Unicode, Windows
files: pyerr_getwindowsmessage.patch
keywords: patch
messages: 107505
nosy: haypo
priority: normal
severity: normal
status: open
title: Create PyErr_GetWindowsMessage() function
versions: Python 3.2
Added file: http://bugs.python.org/file17615/pyerr_getwindowsmessage.patch

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

From report at bugs.python.org  Fri Jun 11 02:27:43 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Fri, 11 Jun 2010 00:27:43 +0000
Subject: [New-bugs-announce] [issue8968] token type constants are not
	documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

the token module defines constants for token types e.g

 NAME = 1
 NUMBER = 2
 STRING = 3
 NEWLINE = 4

etc.

These constants are very useful for any code which needs to tokenize python source, yet they are not listed in the documentation.


Is this a documentation bug?

----------
assignee: docs at python
components: Documentation
messages: 107509
nosy: docs at python, isandler
priority: normal
severity: normal
status: open
title: token type constants are not documented
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 11 02:33:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 00:33:08 +0000
Subject: [New-bugs-announce] [issue8969] Windows: use (mbcs in) strict mode
	to encode/decode	filenames, and enable os.fsencode()
In-Reply-To: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>
Message-ID: <1276216388.28.0.366593840574.issue8969@psf.upfronthosting.co.za>


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

mbcs encoding doesn't support surrogateescape (see #850997), and mbcs should only be used in strict mode to encode/decode filenames.

os.fsencode() should also be enabled on Windows. First I tried to disable this function on Windows to avoid the evil mbcs encoding, but mbcs encoding *is* used by some modules written in C (functions using PyUnicode_FSConverter(): encode the filename to bytes with mbcs encoding on Windows). Eg. _ssl module use PyUnicode_FSConverter() to get filenames because the underlying library, OpenSSL, requires bytes for the filenames (C type: char*). Enable os.fsencode() on Windows helps some tests (eg. fix test_ssl).

Use "strict" error handler, instead of "surrogateescape", to encode/decode filenames with mbcs encoding, does nothing yet because mbcs codec ignore the errors argument. These changes prepare the work on mbcs codec: see #850997.

Note: os.fsencode() was introduced by #8514.

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
files: fsencode_mbcs.patch
keywords: patch
messages: 107510
nosy: haypo
priority: normal
severity: normal
status: open
title: Windows: use (mbcs in) strict mode to encode/decode filenames, and enable os.fsencode()
versions: Python 3.2
Added file: http://bugs.python.org/file17616/fsencode_mbcs.patch

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

From report at bugs.python.org  Fri Jun 11 09:21:36 2010
From: report at bugs.python.org (Rick Johnson)
Date: Fri, 11 Jun 2010 07:21:36 +0000
Subject: [New-bugs-announce] [issue8970] Tkinter Litmus Test
In-Reply-To: <1276240896.62.0.886214435094.issue8970@psf.upfronthosting.co.za>
Message-ID: <1276240896.62.0.886214435094.issue8970@psf.upfronthosting.co.za>


New submission from Rick Johnson <rantingrick at gmail.com>:

There has been much discussion in the past and recently on c.l.p about how many python programmers *actually* use Tkinter. Recently i have been involved in a lengthy discussion on c.l.p about whether or not we should remove Tkinter, replace Tkinter, or fix Tkinter. 

However i feel a decision this important cannot be made from pydev, c.l.p, or anywhere. I believe the only proper way to proceed is to get a *real* vote from *real* python programmers out in the trenches. 

But how do we do that you may ask? Well thats a good question. Not every Python programmer lives on c.l.p, or any *one* place. The only way to truly reach everyone is thru Python itself in form of a Warning message. 

So i propose that an import warning be added to the next possible releases of Python 3.x and Python 3.x. This warning will be triggered upon importing Tkinter and should also be shown when starting IDLE. The message should read loosely as follows...

"""
-------------------------------------------------
 ModuleRemovalWarning: Tkinter (and dependencies)
-------------------------------------------------
The Tkinter module (Python's GUI module) is currently being considered for removal from the python stdlib FOREVER. We are providing this warning so that you can give the python devlopment team (and the wider community) your input on the subject. If you feel that Tkinter should or should not be removed we strongly incurage you to voice your opinion. You can do by casting your vote at "www.savetkinter.com". Whether your a complete noobie or a seasoned Pythonista we need to hear everyone. Voting will end on MM-DD-YYYY, so make sure your vote is counted!
"""

----------
components: IDLE, Tkinter
messages: 107531
nosy: rantingrick
priority: normal
severity: normal
status: open
title: Tkinter Litmus Test
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Jun 11 09:27:42 2010
From: report at bugs.python.org (Rick Johnson)
Date: Fri, 11 Jun 2010 07:27:42 +0000
Subject: [New-bugs-announce] [issue8971] Tkinter Litmus Test
In-Reply-To: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>
Message-ID: <1276241262.66.0.609835750644.issue8971@psf.upfronthosting.co.za>


New submission from Rick Johnson <rantingrick at gmail.com>:

There has been much discussion in the past and recently on c.l.p about how many python programmers *actually* use Tkinter. Recently i have been involved in a lengthy discussion on c.l.p about whether or not we should remove Tkinter, replace Tkinter, or fix Tkinter. 

However i feel a decision this important cannot be made from pydev, c.l.p, or anywhere. I believe the only proper way to proceed is to get a *real* vote from *real* python programmers out in the trenches. 

But how do we do that you may ask? Well thats a good question. Not every Python programmer lives on c.l.p, or any *one* place. The only way to truly reach everyone is through Python itself in form of a Warning message. 

So i propose that an import warning be added to the next possible releases of Python 2.x and Python 3.x. This warning will be triggered upon importing Tkinter and should also be shown when starting IDLE. The message should read loosely as follows...

"""
-------------------------------------------------
 ModuleRemovalWarning: Tkinter (and dependencies)
-------------------------------------------------
The Tkinter module (Python's GUI module) is currently being considered for removal from the python stdlib FOREVER. We are providing this warning so that you can give the python development team (and the wider community) your feedback on the subject. If you feel that Tkinter should or should not be removed we strongly encourage you to voice your opinion. You can do by casting your vote at "www.savetkinter.com". We need to hear everyone whether your a complete newbie or a seasoned Pythonista.  Voting will end on MM-DD-YYYY  so make sure your vote is counted!
"""

----------
components: IDLE, Tkinter
messages: 107532
nosy: rantingrick
priority: normal
severity: normal
status: open
title: Tkinter Litmus Test
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Jun 11 15:11:08 2010
From: report at bugs.python.org (shypike)
Date: Fri, 11 Jun 2010 13:11:08 +0000
Subject: [New-bugs-announce] [issue8972] subprocess.list2cmdline doesn't
	quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>


New submission from shypike <shypike at sabnzbd.org>:

subprocess.py/list2cmdline should also put double quotes around strings that contain ampersands (&), but no spaces.
If not, the Windows command processor will split the command into two separate parts. In short, '&' needs the same treatment as '|'.

----------
components: Windows
messages: 107544
nosy: shypike
priority: normal
severity: normal
status: open
title: subprocess.list2cmdline doesn't quote the & character
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jun 11 17:32:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 15:32:37 +0000
Subject: [New-bugs-announce] [issue8973] Inconsistent docstrings in struct
	module
In-Reply-To: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>
Message-ID: <1276270357.95.0.610857929794.issue8973@psf.upfronthosting.co.za>


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

Module level pack, unpack etc. methods have similar functionality with Struct instance methods, but docs are different.  The immediate issue is the lack of signature in the module level methods' docstrings.


$ ./python.exe -m pydoc struct.Struct.pack
Help on method_descriptor in struct.Struct:

struct.Struct.pack = pack(...)
    S.pack(v1, v2, ...) -> bytes
    
    Return a bytes containing values v1, v2, ... packed according to this
    Struct's format. See struct.__doc__ for more on format strings.

and

$ ./python.exe -m pydoc struct.pack
Help on built-in function pack in struct:

struct.pack = pack(...)
    Return bytes containing values v1, v2, ... packed according to fmt.

----------
components: Extension Modules
messages: 107556
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
status: open
title: Inconsistent docstrings in struct module
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 11 19:16:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 17:16:55 +0000
Subject: [New-bugs-announce] [issue8974] svnmerge errors in msgfmt.py
In-Reply-To: <1276276615.62.0.0556230549588.issue8974@psf.upfronthosting.co.za>
Message-ID: <1276276615.62.0.0556230549588.issue8974@psf.upfronthosting.co.za>


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

svnmerge for r81698 introduced incorrect print(sys.stderr, ...) calls. Attached patch fixes it. Apply with patch -p1.

----------
assignee: loewis
components: Demos and Tools
files: strange-print.diff
keywords: patch
messages: 107563
nosy: loewis, merwok
priority: normal
severity: normal
status: open
title: svnmerge errors in msgfmt.py
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17628/strange-print.diff

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

From report at bugs.python.org  Fri Jun 11 19:34:49 2010
From: report at bugs.python.org (Popa Claudiu)
Date: Fri, 11 Jun 2010 17:34:49 +0000
Subject: [New-bugs-announce] [issue8975] Bug in cookiejar
In-Reply-To: <1276277689.33.0.403419112347.issue8975@psf.upfronthosting.co.za>
Message-ID: <1276277689.33.0.403419112347.issue8975@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

Hello. This is my first report, sorry if I won't do it right.
I found a bug in cookielib, which looks like this(a traceback):

"""C:\Python31\lib\http\cookiejar.py:1586: UserWarning: http.cookiejar bug!
Traceback (most recent call last):
  File "C:\Python31\lib\http\cookiejar.py", line 1584, in make_cookies
    parse_ns_headers(ns_hdrs), request)
  File "C:\Python31\lib\http\cookiejar.py", line 1541, in _cookies_from_attrs_se
t
    cookie = self._cookie_from_cookie_tuple(tup, request)
  File "C:\Python31\lib\http\cookiejar.py", line 1460, in _cookie_from_cookie_tu
ple
    version = int(version)
ValueError: invalid literal for int() with base 10: '1.0'

  _warn_unhandled_exception()"""

----------
components: Library (Lib)
messages: 107564
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Bug in cookiejar
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun 11 21:21:30 2010
From: report at bugs.python.org (Chris Blazick)
Date: Fri, 11 Jun 2010 19:21:30 +0000
Subject: [New-bugs-announce] [issue8976] subprocess module causes
	segmentation fault
In-Reply-To: <1276284090.76.0.563218303469.issue8976@psf.upfronthosting.co.za>
Message-ID: <1276284090.76.0.563218303469.issue8976@psf.upfronthosting.co.za>


New submission from Chris Blazick <blazingvw at gmail.com>:

platform: Linux x86_64 (CentOS)
kernel: 2.6.18-128.1.10.el5.centos.plus
python version: 2.4.3
PyQt versin: 4.7.3

subprocess is generating a segmentation fault.

I am running a proprietary quicktime generating script inside my own (Qt) script using the subprocess module.  I am piping both stdout and stderr into my script.  I have tried reading these two with .communicate() and with the <Popen>.stdout / <Popen>.stderr properties.  Both end up generating the following error:

*** glibc detected *** /usr/bin/python: corrupted double-linked list: 0x00000000161c5c50 ***
Segmentation fault

running my script, and using os.system() to run the proprietary script works just fine

The (C++ compiled) proprietary script does not appear to have any problems crashing under normal circumstances, and I am assuming if there was a problem with the proprietary script, it wouldn't cascade to crashing my own script

----------
components: Extension Modules
messages: 107573
nosy: Chris.Blazick
priority: normal
severity: normal
status: open
title: subprocess module causes segmentation fault
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Fri Jun 11 22:26:40 2010
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 11 Jun 2010 20:26:40 +0000
Subject: [New-bugs-announce] [issue8977] Globalize lonely augmented
	assignment
In-Reply-To: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>
Message-ID: <1276288000.72.0.276261442461.issue8977@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

A=[1,2,3]
def f(x):
    A+=x,

This throws an error. The solution: state "global a". I find it odd that augmented assignment should be viewed the same as assignment in descerning local variables. This patch repairs such to maintain a as a variable of the global namespace

Some might find the following an issue

def f(x):
    if x:
        A+=4,
    else:
        A=[3]
    print("f",x,A)
def g(x):
    if not x:
        A=[3]
    else:
        A+=4,
    print("g",x,A)

In f, A is a global variable. In g, A is a local variable. Thus g(1) throws UnboundLocalError while f(1) appends 4 to A

----------
components: Interpreter Core
files: symtable.diff
keywords: patch
messages: 107581
nosy: serprex
priority: normal
severity: normal
status: open
title: Globalize lonely augmented assignment
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file17633/symtable.diff

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

From report at bugs.python.org  Fri Jun 11 23:48:53 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 11 Jun 2010 21:48:53 +0000
Subject: [New-bugs-announce] [issue8978] "tarfile.ReadError: file could not
	be opened	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>


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

When Python is compiled without zlib support, the error message is not very helpful when trying to untar an archive.

>>> tarfile.open('sample.tar.gz')
tarfile.ReadError: file could not be opened successfully

It happens when you run "python distribute_setup.py", for example.
 ( http://s3.pixane.com/pip_distribute.png )

----------
components: Extension Modules
messages: 107587
nosy: flox
priority: low
severity: normal
status: open
title: "tarfile.ReadError: file could not be opened successfully" if compiled without zlib
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jun 12 03:04:24 2010
From: report at bugs.python.org (Bryan Ward)
Date: Sat, 12 Jun 2010 01:04:24 +0000
Subject: [New-bugs-announce] [issue8979] OptParse __getitem__
In-Reply-To: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>
Message-ID: <1276304664.09.0.271886619191.issue8979@psf.upfronthosting.co.za>


New submission from Bryan Ward <bward1 at gmail.com>:

It would be convenient to be able to access the resultant options from optparse using the syntax

options['some_option']

instead of options.some_option

Or additionally it would be nice to have a way to produce a dictionary of the options.  This would be nice to have to do something to the effect of

dictOptions = options.to_dict()

obj = SomeObject(**dictOptions)

----------
components: Extension Modules
messages: 107620
nosy: bcward
priority: normal
severity: normal
status: open
title: OptParse __getitem__
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 12 05:31:28 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Jun 2010 03:31:28 +0000
Subject: [New-bugs-announce] [issue8980]
	distutils.tests.test_register.RegisterTestCase.test_strict	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>


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

$ python3.2 -m distutils.tests.test_register
.......E
======================================================================
ERROR: test_strict (__main__.RegisterTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/distutils/tests/test_register.py", line 227, in test_strict
    inputs = RawInputs('1', 'tarek', 'y')
NameError: global name 'RawInputs' is not defined

----------------------------------------------------------------------
Ran 8 tests in 0.242s

FAILED (errors=1)

After replacing RawInputs with Inputs:
$ python3.2 -m distutils.tests.test_register
.......E
======================================================================
ERROR: test_strict (__main__.RegisterTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/distutils/tests/test_register.py", line 231, in test_strict
    cmd.run()
  File "/usr/lib64/python3.2/distutils/command/register.py", line 53, in run
    self.run_command(cmd_name)
  File "/usr/lib64/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/usr/lib64/python3.2/distutils/dist.py", line 965, in run_command
    cmd_obj.run()
  File "/usr/lib64/python3.2/distutils/command/check.py", line 72, in run
    raise DistutilsSetupError('The docutils package is needed.')
distutils.errors.DistutilsSetupError: The docutils package is needed.

----------------------------------------------------------------------
Ran 8 tests in 0.245s

FAILED (errors=1)

After fixing import, the test interactively asks for username.

----------
assignee: tarek
components: Distutils, Tests
files: distutils.patch
keywords: patch
messages: 107623
nosy: Arfrever, tarek
priority: normal
severity: normal
status: open
title: distutils.tests.test_register.RegisterTestCase.test_strict fails
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17637/distutils.patch

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

From report at bugs.python.org  Sat Jun 12 06:48:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 04:48:46 +0000
Subject: [New-bugs-announce] [issue8981] _struct.__version__ should be
	string, not bytes
In-Reply-To: <1276318126.69.0.859042236864.issue8981@psf.upfronthosting.co.za>
Message-ID: <1276318126.69.0.859042236864.issue8981@psf.upfronthosting.co.za>


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

>>> import _struct
>>> _struct.__version__
b'0.3'

I would rather simply remove this since it is no longer exposed in struct.

Yes, it does cause problems in real life code: I have applications that keep track of versions of modules that they use and expect __version__ to be string if defined.

Same problem in _curses, but I have never used that module - just grepped the sources.

----------
components: Extension Modules
keywords: easy
messages: 107627
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
status: open
title: _struct.__version__ should be string, not bytes
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jun 12 15:44:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Jun 2010 13:44:29 +0000
Subject: [New-bugs-announce] [issue8982] argparse docs cross reference
	Namespace as a class but	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>


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

I wanted to find out if Namespace supported lookup by subscripting (args['someopt']), but the docs are silent on what Namespace is.  (The answer, by the way, appears to be "no"; there is a feature request for this in issue 8979).

----------
assignee: bethard
components: Documentation
messages: 107653
nosy: bethard, docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse docs cross reference Namespace as a class but the Namespace class is not documented
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jun 12 17:26:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:26:34 +0000
Subject: [New-bugs-announce] [issue8983] Docstrings should refer to
	help(name), not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>


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

Inspired by issue issue8973, I did


$ grep -in "see.*\.__doc__" Modules/*.c

Surprisingly, there were not as many results as I feared.

As I explained in the referenced issue,  "See name.__doc__", while technically correct, is not user friendly.  If you copy name.__doc__ to >>> prompt, you get an ugly repr of a multiline string.  I suggest s/name.__doc__/help(struct)/.

Here are the grep results

Modules/_threadmodule.c:904:Create a new lock object.  See LockType.__doc__ for information about locks.");
Modules/pwdmodule.c:103:See pwd.__doc__ for more on password database entries.");
Modules/pwdmodule.c:124:See pwd.__doc__ for more on password database entries.");
Modules/pwdmodule.c:155:See pwd.__doc__ for more on password database entries.");
Modules/spwdmodule.c:111:See spwd.__doc__ for more on shadow password database entries.");
Modules/spwdmodule.c:143:See spwd.__doc__ for more on shadow password database entries.");

----------
assignee: docs at python
components: Documentation
messages: 107661
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Docstrings should refer to help(name), not name.__doc__
type: feature request

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

From report at bugs.python.org  Sat Jun 12 22:10:23 2010
From: report at bugs.python.org (Sworddragon)
Date: Sat, 12 Jun 2010 20:10:23 +0000
Subject: [New-bugs-announce] [issue8984] Python 3 doesn't register script
	arguments
In-Reply-To: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>
Message-ID: <1276373423.06.0.827266888307.issue8984@psf.upfronthosting.co.za>


New submission from Sworddragon <sworddragon2 at aol.com>:

Python 3.1.2 hasn't any arguments except the file name in sys.argv[0]. For example: build.py test
sys.argv[1] will be empty. I tried even the first example from the documentation 15.4 (optparse) but the filename is None. In Python 2.6.5 all is working fine.

----------
components: Library (Lib)
messages: 107690
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Python 3 doesn't register script arguments
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun 12 22:14:01 2010
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_L=2E_Osella_Massa?=)
Date: Sat, 12 Jun 2010 20:14:01 +0000
Subject: [New-bugs-announce] [issue8985] String format() has problems
	parsing numeric indexes
In-Reply-To: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>
Message-ID: <1276373641.02.0.137473124387.issue8985@psf.upfronthosting.co.za>


New submission from Germ?n L. Osella Massa <gosella at gmail.com>:

The str.format() method allows index lookup on an object that supports __getitem__(). However, negative indexes are not supported.

Examples (using Python 2.6.5):

>>> "{0[0]}".format([0, 1, 2])
'0'

>>> "{0[-1]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

>>> u"{0[0]}".format([0, 1, 2])
u'0'
>>> u"{0[-1]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not unicode

Also notice that spaces matter:

>>> "{0[ 0 ]}".format([0, 1, 2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not str

(The same thing happens on Python 3.1.2)

The problem is that the function get_integer() on Objects/stringlib/string_format.h don't expect spaces or a '-' char, only digits. If the index is not a continuous sequence of digits, it assumes that it is a key for a dict and the index is treated as a string, and that's the cause of the TypeError exception.

This code is the same from 2.6.5 up to trunk.

get_integer() is not very robust to parsing numbers. I'm not familiar with CPython but perhaps the same code used in int(str) can be applied here to take advantage of the better parsing that int() has.

----------
components: Library (Lib), Unicode
messages: 107691
nosy: Germ?n.L..Osella.Massa
priority: normal
severity: normal
status: open
title: String format() has problems parsing numeric indexes
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jun 13 01:51:00 2010
From: report at bugs.python.org (geremy condra)
Date: Sat, 12 Jun 2010 23:51:00 +0000
Subject: [New-bugs-announce] [issue8986] math.erfc OverflowError
In-Reply-To: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>
Message-ID: <1276386660.2.0.0883413482543.issue8986@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

In Python3.2, calling math.erfc with a value in [-27.2, -30) raises
an OverflowError: math range error. This is inconsistent with the
erfc function from scipy (scipy.special.erfc) as well as with the C99
function by the same name, both of which return 2. I suspect that
this is the result of the cutoff for the use of the continuing fraction
approximation of erfc beginning when abs(x) > 30, but I'm not sure.

----------
components: Library (Lib)
messages: 107718
nosy: debatem1
priority: normal
severity: normal
status: open
title: math.erfc OverflowError
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 13 07:22:53 2010
From: report at bugs.python.org (Matt Giuca)
Date: Sun, 13 Jun 2010 05:22:53 +0000
Subject: [New-bugs-announce] [issue8987] Distutils doesn't quote Windows
	command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>


New submission from Matt Giuca <matt.giuca at gmail.com>:

I discovered this investigating a bug report that python-cjson doesn't compile properly on Windows (http://pypi.python.org/pypi/python-cjson). Cjson's setup.py asks distutils to compile with the flag '-DMODULE_VERSION="1.0.5"', but distutils.spawn._nt_quote_args is not escaping the quotes correctly.

Specifically, the current behaviour is:
>>> distutils.spawn._nt_quote_args(['-DMODULE_VERSION="1.0.5"'])
['-DMODULE_VERSION="1.0.5"']

I expect the following:
>>> distutils.spawn._nt_quote_args(['-DMODULE_VERSION="1.0.5"'])
['"-DMODULE_VERSION=""1.0.5"""']

Not surprising, since that function contains a big comment:
    # XXX this doesn't seem very robust to me -- but if the Windows guys
    # say it'll work, I guess I'll have to accept it.  (What if an arg
    # contains quotes?  What other magic characters, other than spaces,
    # have to be escaped?  Is there an escaping mechanism other than
    # quoting?)

It only escapes spaces, and that's it. I've proposed a patch which escapes the following characters properly: "&()<>^| (as far as I can tell, these are the "reserved" characters on Windows).

Note: I did not escape * or ?, the wildcard characters. As far as I can tell, these only have special meaning on the command-line itself, and not when supplied to a program.

Alternatively, it could call subprocess.list2cmdline (but there seem to be issues with that: http://bugs.python.org/issue8972).

----------
assignee: tarek
components: Distutils
files: spawn.patch
keywords: patch
messages: 107722
nosy: mgiuca, tarek
priority: normal
severity: normal
status: open
title: Distutils doesn't quote Windows command lines properly
versions: Python 2.6
Added file: http://bugs.python.org/file17653/spawn.patch

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

From report at bugs.python.org  Sun Jun 13 12:50:35 2010
From: report at bugs.python.org (gonegown)
Date: Sun, 13 Jun 2010 10:50:35 +0000
Subject: [New-bugs-announce] [issue8988] import + coding = failure
	(3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>


New submission from gonegown <nomedocac at gmail.com>:

I have python 3.1.2 fetched from the main site.

imagine two source files:

a.py:
-------
# coding: cp1251
import b;
print('A');
-------

b.py:
-------
print('B');
-------

Both reside in the same directory containing at least one non-ascii character (try 0xdb) in the _path_.

import will fail with an empty error!
#coding here works fine with utf-8 and fails using any other one

now tell me how the hell can file system encoding be related to file content encoding?!

I've attached the source

----------
components: None
files: pybug-import-coding.zip
messages: 107731
nosy: gonegown
priority: normal
severity: normal
status: open
title: import + coding = failure (3.1.2/win32)
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file17655/pybug-import-coding.zip

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

From report at bugs.python.org  Sun Jun 13 17:15:37 2010
From: report at bugs.python.org (Adrian von Bidder)
Date: Sun, 13 Jun 2010 15:15:37 +0000
Subject: [New-bugs-announce] [issue8989] email.utils.make_msgid: specify
	domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>


New submission from Adrian von Bidder <avbidder at fortytwo.ch>:

Using the hostname for the domain part of a Message-Id is probably the right thing usually but users may want to override this.

Please consider this rather trivial patch:

=====
--- utils.py.orig       2010-06-13 16:59:30.533861099 +0200
+++ utils.py    2010-06-13 17:02:18.650697979 +0200
@@ -173,13 +173,15 @@
 
 
 

-def make_msgid(idstring=None):
+def make_msgid(idstring=None, domain=None):
     """Returns a string suitable for RFC 2822 compliant Message-ID, e.g:
 
     <20020201195627.33539.96671 at nightshade.la.mastaler.com>
 
     Optional idstring if given is a string used to strengthen the
-    uniqueness of the message id.
+    uniqueness of the message id.  The domain part of the Message-ID
+    defaults to the locally defined hostname, but can be specified
+    explicitly.
     """
     timeval = time.time()
     utcdate = time.strftime('%Y%m%d%H%M%S', time.gmtime(timeval))
@@ -189,8 +191,9 @@
         idstring = ''
     else:
         idstring = '.' + idstring
-    idhost = socket.getfqdn()
-    msgid = '<%s.%s.%s%s@%s>' % (utcdate, pid, randint, idstring, idhost)
+    if domain is None:
+        domain = socket.getfqdn()
+    msgid = '<%s.%s.%s%s@%s>' % (utcdate, pid, randint, idstring, domain)
     return msgid
 
 
=====

thanks & greetings
-- vbi

----------
components: Library (Lib)
messages: 107734
nosy: avbidder at fortytwo.ch
priority: normal
severity: normal
status: open
title: email.utils.make_msgid: specify domain
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Sun Jun 13 21:42:54 2010
From: report at bugs.python.org (Thomas Jollans)
Date: Sun, 13 Jun 2010 19:42:54 +0000
Subject: [New-bugs-announce] [issue8990] array constructor and
	array.fromstring should accept	bytearray.
In-Reply-To: <1276458174.59.0.784735349158.issue8990@psf.upfronthosting.co.za>
Message-ID: <1276458174.59.0.784735349158.issue8990@psf.upfronthosting.co.za>


New submission from Thomas Jollans <thomas at jollans.com>:

Currently, the array constructor, if given a bytearray, detects this with PyByteArray_Check, and hands it on to array_fromstring, which does not support bytearray (by using "s#" with PyArg_ParseTuple) and raises TypeError.

>>> array('h', bytearray(b'xyxyxyxyxyxyxyxyxy'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be bytes or read-only buffer, not bytearray
>>>  


I see no reason to insist on read-only buffers. I'm attaching a patch that I think fixes this.

----------
components: Extension Modules, Library (Lib)
files: array.diff
keywords: patch
messages: 107744
nosy: tjollans
priority: normal
severity: normal
status: open
title: array constructor and array.fromstring should accept bytearray.
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17658/array.diff

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

From report at bugs.python.org  Sun Jun 13 22:37:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 20:37:37 +0000
Subject: [New-bugs-announce] [issue8991] PyArg_Parse*() functions: reject
	discontinious buffers
In-Reply-To: <1276461457.35.0.826008906861.issue8991@psf.upfronthosting.co.za>
Message-ID: <1276461457.35.0.826008906861.issue8991@psf.upfronthosting.co.za>


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

getbuffer() checks that the buffer is contiguous. "s#", "y", "z" formats use convertbuffer() which doesn't check that the buffer is contigious, as "w" and "w#" formats which call directly PyObject_GetBuffer() which extra check.

I don't think that the functions using these format support discontiguous buffers. I cannot check because I don't know how to create such buffer. It would be safer to reject discontigious buffer.

If a function would like to support discontigious buffer, it should use "O" format, call PyObject_GetBuffer() with the right option and do its own checks on the buffer object.

----------
components: Interpreter Core
messages: 107749
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*() functions: reject discontinious buffers
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 13 23:15:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Jun 2010 21:15:33 +0000
Subject: [New-bugs-announce] [issue8992] convertsimple() doesn't need to
	call converterr() if an	exception was already raised
In-Reply-To: <1276463733.12.0.346579334159.issue8992@psf.upfronthosting.co.za>
Message-ID: <1276463733.12.0.346579334159.issue8992@psf.upfronthosting.co.za>


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

If convertitem() result is not NULL, an error occured and seterror() is called (by the function calling convertitem()). seterror() does nothing if an exception was raised (if PyErr_Occurred() is non zero).

convertitem() doesn't need to call converterr() if an exception occurred because the string formatted by converterr() will be ignored. We just need to return a non NULL pointer: msgbuf.

Attached patch creates a RETURN_ERR_OCCURRED macro. convertsimple() should be a little bit faster and the code is more readable. Details:
 - addcleanup() now takes a boolean to indicate if it's a buffer or a pointer to simplify the API and have to raise a special error if the destructor is unknown
 - don't check that the result of PyUnicode_AsEncodedString() is a bytes object: PyUnicode_AsEncodedString() does already check that

----------
components: Interpreter Core
files: getarg_err_occurred.patch
keywords: patch
messages: 107753
nosy: haypo
priority: normal
severity: normal
status: open
title: convertsimple() doesn't need to call converterr() if an exception was already raised
versions: Python 3.2
Added file: http://bugs.python.org/file17662/getarg_err_occurred.patch

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

From report at bugs.python.org  Mon Jun 14 06:58:36 2010
From: report at bugs.python.org (flashk)
Date: Mon, 14 Jun 2010 04:58:36 +0000
Subject: [New-bugs-announce] [issue8993] Small typo in docs for PySys_SetArgv
In-Reply-To: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>
Message-ID: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

The docs for PySys_SetArgv say:

"This function works like PySys_SetArgv() with updatepath set to 1."

I believe it should be "PySys_SetArgvEx".

I've attached a patch.

----------
assignee: docs at python
components: Documentation
files: init.rst.patch
keywords: patch
messages: 107771
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Small typo in docs for PySys_SetArgv
versions: Python 2.7
Added file: http://bugs.python.org/file17665/init.rst.patch

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

From report at bugs.python.org  Mon Jun 14 11:13:56 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Mon, 14 Jun 2010 09:13:56 +0000
Subject: [New-bugs-announce] [issue8994] pydoc does not support non-ascii
	docstrings
In-Reply-To: <1276506836.98.0.338188119331.issue8994@psf.upfronthosting.co.za>
Message-ID: <1276506836.98.0.338188119331.issue8994@psf.upfronthosting.co.za>


New submission from Torsten Landschoff <t.landschoff at gmx.net>:

With the attached file doc.py I see the following behaviour:

torsten at ddhp3:~$ pydoc doc
Traceback (most recent call last):
  File "/usr/bin/pydoc", line 5, in <module>
    pydoc.cli()
  File "/usr/lib/python2.6/pydoc.py", line 2309, in cli
    help.help(arg)
  File "/usr/lib/python2.6/pydoc.py", line 1773, in help
    elif request: doc(request, 'Help on %s:')
  File "/usr/lib/python2.6/pydoc.py", line 1516, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/lib/python2.6/pydoc.py", line 1323, in pager
    pager(text)
  File "/usr/lib/python2.6/pydoc.py", line 1343, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/usr/lib/python2.6/pydoc.py", line 1364, in pipepager
    pipe.write(text)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 184-186: ordinal not in range(128)

With the terminal on sys.stdout I get "UTF-8" as the encoding (sys.stdout.encoding), therefore I would expect this to work. It would be helpful to have an option to set the encoding when running pydoc as well.

And, of course, accessing the documentation via a web browser (pydoc -p 8000, firefox http://localhost:8000) I get a blank screen for the doc.py example. And a backtrace on the terminal where I started pydoc.

----------
components: Unicode
files: doc.py
messages: 107774
nosy: torsten
priority: normal
severity: normal
status: open
title: pydoc does not support non-ascii docstrings
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17666/doc.py

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

From report at bugs.python.org  Mon Jun 14 11:53:32 2010
From: report at bugs.python.org (Bob)
Date: Mon, 14 Jun 2010 09:53:32 +0000
Subject: [New-bugs-announce] [issue8995] Performance issue with
	multiprocessing queue (3.1 VS 2.6)
In-Reply-To: <1276509212.88.0.604196007502.issue8995@psf.upfronthosting.co.za>
Message-ID: <1276509212.88.0.604196007502.issue8995@psf.upfronthosting.co.za>


New submission from Bob <for_elise03 at yahoo.fr>:

Hi,

I've found a strange performance issue when comparing queue.queue and multiprocessing.queue in python 2.6 and 3.1

My program creates a queue, and do 1 million put and get operations on either a small data or a "big" array.

My code: (This is the 3.1 version. Switch module name from queue to Queue to run on 2.6)

####################################################################
import multiprocessing
import queue

def with_queue(queuetype,datatype):
    if queuetype == 'multi':
        q = multiprocessing.Queue(1000)
    else:
        q = queue.Queue(1000)

    if datatype == 'small':
        data = 'some data'
    else:
        data = []
        for i in range(1000):
            data.append(i)
           
    for d in range(1000000):
        q.put(data)
        q.get()
       
if __name__=='__main__':
    from timeit import Timer
    t1 = Timer("with_queue('simple','small')","from __main__ import with_queue")
    t2 = Timer("with_queue('simple','big')","from __main__ import with_queue")
    t3 = Timer("with_queue('multi','small')","from __main__ import with_queue")
    t4 = Timer("with_queue('multi','big')","from __main__ import with_queue")
   
    print ('Using queue.Queue with small data            : ',t1.timeit(1))
    print ('Using queue.Queue with huge data             : ',t2.timeit(1))
    print ('Using multiprocessing.Queue with small data  : ',t3.timeit(1))
    print ('Using multiprocessing.Queue with huge  data  : ',t4.timeit(1))
#####################################################################

And the results (on my linux box:)

python2.6 read_write.py
    Using queue.Queue with small data            :  10.31s
    Using queue.Queue with huge data             :  10.39s
    Using multiprocessing.Queue with small data  :  33.85s
    Using multiprocessing.Queue with huge  data  :  155.38s

python3.1 read_write.py
    Using queue.Queue with small data            :  10.68s
    Using queue.Queue with huge data             :  10.61s
    Using multiprocessing.Queue with small data  :  50.27s
    Using multiprocessing.Queue with huge  data  :  472.49s


As you can see 3.1 is 50% slower than 2.6 in the third test; but 300 % slower in the 4th test.
If i go further with bigger data, 3.1 run for hours ... and i have to kill it before any result shows.
Am i doing something wrong or is there any known issue in 3.1 that can explain this ?

Thanks !

Bob

----------
components: Extension Modules
messages: 107775
nosy: bob
priority: normal
severity: normal
status: open
title: Performance issue with multiprocessing queue (3.1 VS 2.6)
type: performance
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Mon Jun 14 17:09:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 15:09:12 +0000
Subject: [New-bugs-announce] [issue8996] Add a default role to allow writing
	bare `len` instead of	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>


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

Following a discussion on IRC:

<birkenfeld> I would even prefer having more of just `object` instead of :func:`object` or :class:`object`

I think it would be feasible to write a reST role that would use inspect or pydoc to find the type. It would not violate ?In the face of ambiguity, refuse the temptation to guess? if it only resolves `somebuiltin` and `some.fully.qualified.name`.

Cons: People unfamiliar with reST might confuse ``code`` with `name`; interpreting the role may prove non-trivial (either requiring importing Python module to introspect them, or keeping a mapping of names?types in some file).

Thoughts?

----------
assignee: docs at python
components: Documentation
messages: 107790
nosy: docs at python, merwok
priority: normal
severity: normal
status: open
title: Add a default role to allow writing bare `len` instead of :func:`len`
type: feature request

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

From report at bugs.python.org  Mon Jun 14 21:18:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 14 Jun 2010 19:18:40 +0000
Subject: [New-bugs-announce] [issue8997] Write documentation for
	codecs.readbuffer_encode()
In-Reply-To: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>
Message-ID: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

See #8838 for details.

----------
assignee: lemburg
components: Documentation
messages: 107809
nosy: lemburg
priority: normal
severity: normal
status: open
title: Write documentation for codecs.readbuffer_encode()
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun 14 23:39:58 2010
From: report at bugs.python.org (geremy condra)
Date: Mon, 14 Jun 2010 21:39:58 +0000
Subject: [New-bugs-announce] [issue8998] add
	encryption/decryption/signature/verification routines	to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

Python's hashlib and ssl modules currently leverage OpenSSL to provide developers with access to cryptographic hash and TLS routines, but encryption/decryption and signature/verification support are still missing. I propose the addition of an easy-to-use crypto module modeled after Evpy[0] to remedy this.

----------
components: Library (Lib)
messages: 107813
nosy: debatem1
priority: normal
severity: normal
status: open
title: add encryption/decryption/signature/verification routines to stdlib
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 15 11:19:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 15 Jun 2010 09:19:32 +0000
Subject: [New-bugs-announce] [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>


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

I got bored of manually changing the svn status command to hg status when testing my patch for #8912, so I made a proper patch once and for all. (Did I already say yay for Mercurial Queues?)

----------
components: Demos and Tools
files: hg-support.diff
keywords: patch
messages: 107858
nosy: merwok
priority: low
severity: normal
stage: patch review
status: open
title: Add Mercurial support to patchcheck
type: feature request
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file17674/hg-support.diff

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

From report at bugs.python.org  Tue Jun 15 17:52:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Jun 2010 15:52:50 +0000
Subject: [New-bugs-announce] [issue9000] Provide parseable repr to
	datetime.timezone
In-Reply-To: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>
Message-ID: <1276617170.01.0.394704824446.issue9000@psf.upfronthosting.co.za>


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

Recently added datetime.timezone class does not have a custom repr, so one gets

>>> timezone.utc
<datetime.timezone object at 0x100681ef0>

instead of parseable

datetime.timezone(datetime.timedelta(0))

This is inconsistent with the way other classes in datetime module behave.

----------
assignee: belopolsky
keywords: easy
messages: 107876
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Provide parseable repr to datetime.timezone
type: feature request

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

From report at bugs.python.org  Tue Jun 15 18:22:05 2010
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 15 Jun 2010 16:22:05 +0000
Subject: [New-bugs-announce] [issue9001] PyFile_FromFd wrong documentation
In-Reply-To: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>
Message-ID: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

PyFile_FromFd has a wrong argument cound and, consequently, a wrong description in py3k docs. The "errors" is never mentioned.

----------
assignee: docs at python
components: Documentation
files: correct-py3k-c-api-doc.diff
keywords: patch
messages: 107879
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: PyFile_FromFd wrong documentation
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17677/correct-py3k-c-api-doc.diff

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

From report at bugs.python.org  Tue Jun 15 18:46:57 2010
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 15 Jun 2010 16:46:57 +0000
Subject: [New-bugs-announce] [issue9002] Add a pointer on where to find a
	better description of	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

Even though the "File Objects" section in py3k documentation makes it clear that the functions there listed are just wrappers over the io module, it took me a bit to find which function PyFile_FromFd was wrapping.

So, what about making it clear that PyFile_FromFd wraps io.open? The attached patch tries to do that. (It assumes that my previous patch, from issue #9001, will get accepted, as it builds on it.)

----------
assignee: docs at python
components: Documentation
files: py3k-pyfile-from-fd-io-module.diff
keywords: patch
messages: 107881
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Add a pointer on where to find a better description of PyFile_FromFd arguments
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17678/py3k-pyfile-from-fd-io-module.diff

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

From report at bugs.python.org  Wed Jun 16 03:04:37 2010
From: report at bugs.python.org (geremy condra)
Date: Wed, 16 Jun 2010 01:04:37 +0000
Subject: [New-bugs-announce] [issue9003] urllib about https behavior
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>


New submission from geremy condra <debatem1 at gmail.com>:

urllib currently blindly accepts bad certificates when passed an https address. This behavior, clearly not desirable for many users, is also not documented. I propose one of two changes:

1) add mechanisms for enforcing correct behavior to urllib, or
2) change the documentation for that module to include something akin to the following warning:

"Warning: urllib does not perform certificate checks if passed an HTTPS url! This permits remote machines to masquerade as your intended destination."

----------
components: Library (Lib)
messages: 107900
nosy: debatem1
priority: normal
severity: normal
status: open
title: urllib about https behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun 16 05:36:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 03:36:44 +0000
Subject: [New-bugs-announce] [issue9004] datetime.utctimetuple() should not
	set tm_isdst flag to 0
In-Reply-To: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>
Message-ID: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>


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

I find the following quite misleading:

>>> from datetime import datetime
>>> import time
>>> time.strftime('%c %z %Z', datetime.utcnow().utctimetuple())
'Wed Jun 16 03:26:26 2010 -0500 EST'

As far as I can tell, the only other function that uses the tm_isdst flag is time.mktime, but it expect a timetuple containing local time, not UTC time.

----------
assignee: belopolsky
components: Extension Modules
messages: 107906
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: datetime.utctimetuple() should not set tm_isdst flag to 0
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 16 05:57:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 03:57:07 +0000
Subject: [New-bugs-announce] [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>


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

Current datetime.timetuple() implementation goes out of its way to support edge cases that produce timetuples beyond the naive datetime range:

>>> t1 = datetime.min.replace(tzinfo=timezone.max)
>>> t2 = datetime.max.replace(tzinfo=timezone.min)
>>> print(t1.utctimetuple())
time.struct_time(tm_year=0, tm_mon=12, tm_mday=31, tm_hour=0, tm_min=1, tm_sec=0, tm_wday=6, tm_yday=366, tm_isdst=0)
>>> print(t2.utctimetuple())
time.struct_time(tm_year=10000, tm_mon=1, tm_mday=1, tm_hour=23, tm_min=58, tm_sec=59, tm_wday=5, tm_yday=1, tm_isdst=0)

The last result is particularly troublesome because it may crash time.asctime on POSIX compliant systems.  See Issue #6608.

tm_year is described in help(time) as 4-digit year suggesting range of [1000, 9999].  Most C libraries support even smaller ranges.

----------
assignee: belopolsky
components: Extension Modules
messages: 107907
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Year range in timetuple
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 16 11:20:36 2010
From: report at bugs.python.org (=?utf-8?q?Timoth=C3=A9e_CEZARD?=)
Date: Wed, 16 Jun 2010 09:20:36 +0000
Subject: [New-bugs-announce] [issue9006] xml-rpc Server object does not
	propagate the encoding to	Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>


New submission from Timoth?e CEZARD <tim.cezard at gmail.com>:

xmlrpc cleint  (Server class) default encoding is utf-8 it can be modified through the encoding keyword parameter. This parameter is not passed to the Unmarshaller that decode the bit flow causing the server to crash
attached is two script reproducing the issue

----------
components: XML
files: xmlrpc_bug.tar.gz
messages: 107910
nosy: Timoth?e.CEZARD
priority: normal
severity: normal
status: open
title: xml-rpc Server object does not propagate the encoding to Unmarshaller
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17682/xmlrpc_bug.tar.gz

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

From report at bugs.python.org  Wed Jun 16 12:12:22 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:12:22 +0000
Subject: [New-bugs-announce] [issue9007] CGIHTTPServer
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>


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

CGIHTTPServer only supports Python CGI scripts. That should be reflected in documentation.

----------
assignee: docs at python
components: Documentation
messages: 107911
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 16 12:13:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:13:44 +0000
Subject: [New-bugs-announce] [issue9008] CGIHTTPServer support for arbitrary
	CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>


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

CGIHTTPServer should support all CGI scripts, not only Python ones.

----------
components: Library (Lib)
messages: 107912
nosy: techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer support for arbitrary CGI scripts
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jun 16 16:00:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Jun 2010 14:00:48 +0000
Subject: [New-bugs-announce] [issue9009] Improve quality of Python/dtoa.c
In-Reply-To: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>
Message-ID: <1276696848.05.0.800225334902.issue9009@psf.upfronthosting.co.za>


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

I've opened this issue to track efforts to improve the quality of the Python/dtoa.c file, which provides Python's string-to-float and float-to-string conversions.

Particular issues in mind (non-exhaustive):

 - do a thorough review and test of _Py_dg_dtoa;  this has already
   been done for _Py_dg_strtod (issue 7632, issue 7743), and uncovered
   several problems, including a memory leak, some asserts that were
   triggered in debug mode, and many cases of wrong output.   

 - break out the parsing code from _Py_dg_strtod into a separate
   function, for clarity and maintainability (and possible re-use
   of the parsing code itself)

 - improve _Py_dg_strtod tests, by using contined-fractions to generate
   and test particularly difficult cases.

 - _Py_dg_strtod silently gives wrong results for huge inputs;  while
   not particular serious, this is easily avoidable.

 - improve API to rely on errno less.

 - some pieces of code are currently unused;  improve code coverage
   and tests to identify thoses pieces and remove them.

 - the current code is convoluted in places and hard to explain;
   at least some extra comments should be added.

 - try to make Python/dtoa.c as Python-agnostic as possible, so that
   the code can be reused in other projects where desired.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 107923
nosy: eric.smith, mark.dickinson
priority: normal
severity: normal
status: open
title: Improve quality of Python/dtoa.c
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 16 17:11:25 2010
From: report at bugs.python.org (Ruben Bakker)
Date: Wed, 16 Jun 2010 15:11:25 +0000
Subject: [New-bugs-announce] [issue9010] Infinite loop in imaplib.IMAP4_SSL
	when used with Gmail
In-Reply-To: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>
Message-ID: <1276701085.45.0.35769519286.issue9010@psf.upfronthosting.co.za>


New submission from Ruben Bakker <ruben.bakker1 at gmail.com>:

When using imaplib.IMAP4_SSL to open a Gmail mailbox, the readline method can go into a infinite loop. It happens after Gmail drops the connection, usually after some time/inactivity. The next imaplib request will cause the infinite loop inside the readline() method.

Steps to reproduce:
Perform this script (use python -i to get the prompt):

import imaplib

HOST="imap.gmail.com"
PORT=993
USERNAME="username at gmail.com"
PASSWORD="password"

server = imaplib.IMAP4_SSL(host=HOST, port=PORT)
server.login(USERNAME, PASSWORD)

def f():
	print server.select("INBOX")
	print server.uid("FETCH", "1:*", "(UID FLAGS BODY.PEEK[HEADER.FIELDS (Subject)])")

Call the f() function and then wait about about an hour. Call f() again and server.select() will not return but take all CPU.

Add this line in IMAP4_SSL
          if not char: raise self.abort('socket error: EOF')

complete method:
    def readline(self):
        """Read line from remote."""
        line = []
        while 1:
            char = self.sslobj.read(1)
            if not char: raise self.abort('socket error: EOF')
            line.append(char)
            if char == "\n": return ''.join(line)

----------
components: Library (Lib)
messages: 107925
nosy: Ruben.Bakker
priority: normal
severity: normal
status: open
title: Infinite loop in imaplib.IMAP4_SSL when used with Gmail
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 16 17:39:00 2010
From: report at bugs.python.org (Alex Samuel)
Date: Wed, 16 Jun 2010 15:39:00 +0000
Subject: [New-bugs-announce] [issue9011] ast_for_factor unary minus
	optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>


New submission from Alex Samuel <alex at alexsamuel.net>:

The unary negative optimization in ast_for_factor() seems to modify the ST in a way changes its meaning.

In Python 3.1.2, the ST is no longer compilable:

$ cat exprbug.py
import parser

st = parser.expr("-3")
print(st.totuple())
compiled = st.compile()
print(eval(compiled))
print(st.totuple())
print(eval(st.compile()))

$ ~/sw/Python-3.1.2/bin/python3 exprbug.py
(258, (326, (301, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (317, (15, '-'), (317, (318, (319, (2, '3')))))))))))))))))), (4, ''), (0, ''))
-3
(258, (326, (301, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (317, (15, '-'), (317, (318, (319, (2, '-3')))))))))))))))))), (4, ''), (0, ''))
Traceback (most recent call last):
  File "exprbug.py", line 8, in <module>
    print(eval(st.compile()))
ValueError: could not convert string to float: --3


In earlier versions of Python (I have confirmed 2.5 and 2.6), it is compiled to incorrect code and produces wrong results when evaluated:

$ ~/sw/Python-2.6.2/bin/python exprbug.py
(258, (327, (304, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (15, '-'), (316, (317, (318, (2, '3'))))))))))))))))), (4, ''), (0, ''))
-3
(258, (327, (304, (305, (306, (307, (308, (310, (311, (312, (313, (314, (315, (316, (15, '-'), (316, (317, (318, (2, '-3'))))))))))))))))), (4, ''), (0, ''))
-1.0


If I remove the big if statement from the front of ast_to_factor(), the code behaves correctly.  I think this is because STR(pnum) is changed in place and never restored to its previous value.

----------
components: Interpreter Core
messages: 107928
nosy: alexhsamuel
priority: normal
severity: normal
status: open
title: ast_for_factor unary minus optimization changes AST
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Jun 16 17:46:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 15:46:54 +0000
Subject: [New-bugs-announce] [issue9012] Separate compilation of time and
	datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>


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

Here is the history of the issue per Martin v. L?wis on python-dev:

"""

This was added with

------------------------------------------------------------------------
r36221 | bcannon | 2004-06-24 03:38:47 +0200 (Do, 24. Jun 2004) | 3 Zeilen

Add compilation of timemodule.c with datetimemodule.c to get
__PyTime_DoubleToTimet().

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

So it's clearly intentional. I doubt its desirable, though. If only
__PyTime_DoubleToTimet needs to be duplicated, I'd rather put that
function into a separate C file that gets included twice, instead of including the full timemodule.c into datetimemodule.c.
"""
-- "Sharing functions between C extension modules in stdlib", http://mail.python.org/pipermail/python-dev/2010-June/100587.html

I hope this is non-controversial, but I would like someone to comment on the choice of file name.  I chose _timefunc.c to make it more distinguishable from module file names.  Ideally, however I would like to see this in either _time.h/_time.c pair (both in Module dir like _math.{c,h}) or in pytime.h/pytime.c (like pymath.{c,h}).

Marking this as "resource usage" because the patch will result in smaller size of datetime module.

----------
assignee: belopolsky
messages: 107929
nosy: belopolsky, brett.cannon, loewis, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Separate compilation of time and datetime modules
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 16 19:58:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Jun 2010 17:58:31 +0000
Subject: [New-bugs-announce] [issue9013] Implement tzinfo.dst() method in
	timezone
In-Reply-To: <1276711111.49.0.476665122732.issue9013@psf.upfronthosting.co.za>
Message-ID: <1276711111.49.0.476665122732.issue9013@psf.upfronthosting.co.za>


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

This idea was brought in the original fixed offset timezone proposal (see issue 5094), but was met with some opposition.  See msg106914, point 2. As a result, the timezone implementation is in conflict with tzinfo documentation that says "If utcoffset() does not return None, dst() should not return None either." http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset


Note that dst() is not needed for time calculations involving fixed offset timezones because DST shift is included in utcoffset().  It is however needed for interoperability with timetuple time representation. See issue9004.

If the long term goal is to move users from using timetuples to to datetime objects, it is important for time objects to be able to store DST flag.

----------
assignee: belopolsky
components: Extension Modules
messages: 107940
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Implement tzinfo.dst() method in timezone
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 16 21:58:50 2010
From: report at bugs.python.org (Renato Cunha)
Date: Wed, 16 Jun 2010 19:58:50 +0000
Subject: [New-bugs-announce] [issue9014] Incorrect documentation of the
	PyObject_HEAD macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

PyObject_HEAD's documentation in py3k (http://docs.python.org/dev/py3k/c-api/structures.html#PyObject_HEAD) uses the same content used in the python 2.x's docs which is wrong, as there were some API changes.

PyObject_HEAD is actually defined as

#define PyObject_HEAD PyObject ob_base;

with PyObject defined as

typedef struct _object {
    _PyObject_HEAD_EXTRA
    Py_ssize_t ob_refcnt;
    struct _typeobject *ob_type;
} PyObject;

(The PyTRACE_REFS discussion is still valid, though.)

Additionally, it'd be nice to mention that the Py_REFCNT(ob) and Py_TYPE(ob) macros should be used to access the PyObject members.

----------
assignee: docs at python
components: Documentation
messages: 107953
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Incorrect documentation of the PyObject_HEAD macro
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 17 01:20:46 2010
From: report at bugs.python.org (Bill Steinmetz)
Date: Wed, 16 Jun 2010 23:20:46 +0000
Subject: [New-bugs-announce] [issue9015] array.array.tofile cannot write
	arrays of sizes > 4GB, even compiled for amd64
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>


New submission from Bill Steinmetz <bill.steinmetz at gmail.com>:

Here's my Python version info:
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32


Here's my code that won't return (Start with a file > 4GB "hugefile.bin"):

siz = (1<<32)

print "making array (%d) bytes" % siz
fin = open("hugefile.bin","rb")
a = array.array("B")
a.fromfile(fin, siz)
fin.close()

print "writing array (%d) bytes" % siz
fout = open("foo.bin","wb")
a.tofile(fout)
print "wrote 2^32 bytes with array.tofile"



I never get the third print statement :(

----------
components: Extension Modules
messages: 107964
nosy: Bill.Steinmetz
priority: normal
severity: normal
status: open
title: array.array.tofile cannot write arrays of sizes > 4GB, even compiled for amd64
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 17 06:05:36 2010
From: report at bugs.python.org (Jon Seger)
Date: Thu, 17 Jun 2010 04:05:36 +0000
Subject: [New-bugs-announce] [issue9016] IDLE won't launch (Win XP)
In-Reply-To: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>
Message-ID: <1276747536.03.0.234603288057.issue9016@psf.upfronthosting.co.za>


New submission from Jon Seger <seger at biology.utah.edu>:

I upgraded from 2.5.2 to 2.6.5 on a WinXP system.  Console interpreter worked fine, but IDLE would not launch (quit without displaying anything on screen).  Same with 2.6.4.  Finally tried 2.5.4, which works as expected (like the old 2.5.2).

----------
components: IDLE
messages: 107990
nosy: jonseger
priority: normal
severity: normal
status: open
title: IDLE won't launch (Win XP)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 17 14:42:13 2010
From: report at bugs.python.org (harobed)
Date: Thu, 17 Jun 2010 12:42:13 +0000
Subject: [New-bugs-announce] [issue9017] What do you think about an Option
	Flags to enable/disable	some chunk of doctest file ?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

Hi,

in some doctest, I need to stop doctest from a position because the following test is a draft, not implemented.

I dream something like this :

   >>> test_a()
   True

   >>> test_b()
   False

   #doctest: +DISABLE

   >>> test_c()
   True

   >>> test_d()
   False

   #doctest: +ENABLE

   >>> test_e()
   True

   >>> test_f()
   False

Here, test_c and test_d aren't executed.

What do you think about this idea ? If it is a good idea, I can implement it.

Thanks for your comments,
Stephane

----------
components: Tests
messages: 108008
nosy: harobed
priority: normal
severity: normal
status: open
title: What do you think about an Option Flags to enable/disable some chunk of doctest file ?

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

From report at bugs.python.org  Thu Jun 17 15:40:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Jun 2010 13:40:16 +0000
Subject: [New-bugs-announce] [issue9018] os.path.normcase(None) does not
	raise an error on linux	and should
In-Reply-To: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>
Message-ID: <1276782016.7.0.192519527211.issue9018@psf.upfronthosting.co.za>


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

os.path.normcase(None) raises an error on Windows but returns None on linux.  os.path.abspath(None) raises an error in both cases.  os.path.normcase(None) should raise an error on linux.

I've only marked this for 3.2 because I suspect there may be linux code out there that this will break, so the fix should probably only be applied to 3.2.  (I discovered this because a unit test someone else wrote passed on linux but failed on windows.)

----------
keywords: easy
messages: 108016
nosy: r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: os.path.normcase(None) does not raise an error on linux and should
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 17 20:34:17 2010
From: report at bugs.python.org (Marcel Hellkamp)
Date: Thu, 17 Jun 2010 18:34:17 +0000
Subject: [New-bugs-announce] [issue9019] wsgiref.headers.Header() does not
	update headers list it	was created with.
In-Reply-To: <1276799657.02.0.296941207361.issue9019@psf.upfronthosting.co.za>
Message-ID: <1276799657.02.0.296941207361.issue9019@psf.upfronthosting.co.za>


New submission from Marcel Hellkamp <defnull at gmail.com>:

The current (3.x) implementation of wsgiref.headers.Headers() does not match the documentation.

Documented behaviour:
"Any changes made to the new Headers object will directly update the headers list it was created with." (/Doc/library/wsgiref.rst)

Actual behaviour:
The initial headers list is not updated.

The error was introduced with revision 68205. See http://svn.python.org/view/python/branches/py3k/Lib/wsgiref/headers.py?view=diff&r1=68204&r2=68205

Revision 68204::
    >>> from wsgiref.headers import Headers
    >>> l = []
    >>> h = Headers(l)
    >>> h.add_header('Test','Test')
    >>> l
    [('Test', 'Test')]

Revision 68205::
    >>> from wsgiref.headers import Headers
    >>> l = []
    >>> h = Headers(l)
    >>> h.add_header('Test','Test')
    >>> l
    []

----------
components: Library (Lib)
messages: 108042
nosy: Marcel.Hellkamp
priority: normal
severity: normal
status: open
title: wsgiref.headers.Header() does not update headers list it was created with.
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 17 22:17:08 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 17 Jun 2010 20:17:08 +0000
Subject: [New-bugs-announce] [issue9020] 2.7: eval hangs on AIX
In-Reply-To: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>
Message-ID: <1276805828.97.0.635702088758.issue9020@psf.upfronthosting.co.za>


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

I first noticed this when `test_compare_function_objects` was taking forever to run. The culprit is that the following statement just hangs forever. Note that "eval(2)", for instance, runs fine, but when a builtin object is used (eg: None, True), it hangs.

  python -c "eval('None')"

This is reproducible on Python 2.7 (rc1 and latest trunk) and AIX 5.1.

This is regression, as it used to work on 2.6.

----------
components: Interpreter Core, Tests
messages: 108057
nosy: srid
priority: normal
severity: normal
status: open
title: 2.7: eval hangs on AIX
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 18 01:18:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 23:18:33 +0000
Subject: [New-bugs-announce] [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>


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

`copy` module covers very important aspect of Python programming. However its documentation doesn't provide any intro or overview of this problem starting right from details. When people meet `copy` construction in the code - the refer to module documentation and its doesn't completely answer two basic questions they have:

1. why copy module is needed (i.e. what's the problem with var assignment)
2. when and where it should be used

----------
assignee: docs at python
components: Documentation
messages: 108069
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: no copy.copy problem description
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun 18 02:25:47 2010
From: report at bugs.python.org (David)
Date: Fri, 18 Jun 2010 00:25:47 +0000
Subject: [New-bugs-announce] [issue9022] TypeError in wsgiref.handlers when
	using CGIHandler
In-Reply-To: <1276820747.2.0.467969862682.issue9022@psf.upfronthosting.co.za>
Message-ID: <1276820747.2.0.467969862682.issue9022@psf.upfronthosting.co.za>


New submission from David <toxicdav3 at gmail.com>:

The following code produces a type error, but from what I can tell it does comply with PEP333. This issue appeared using Python 3.1.1 and 3.1.2 on both Windows and Ubuntu. I have only tried the 32 bit versions. Works fine in Python 2.6.5.12 but I guess thats irrelevant.

-----
def application(environ, start_response):
	start_response('200 OK',[('Content-type','text/html')])
	return ['<html><body>Hello World!</body></html>']
	
from wsgiref.handlers import CGIHandler
CGIHandler().run(application)
-----
Traceback (most recent call last):
  File "C:\Python31\lib\wsgiref\handlers.py", line 75, in run
    self.finish_response()
  File "C:\Python31\lib\wsgiref\handlers.py", line 116, in finish_response
    self.write(data)
  File "C:\Python31\lib\wsgiref\handlers.py", line 210, in write
    self.send_headers()
  File "C:\Python31\lib\wsgiref\handlers.py", line 266, in send_headers
    self.send_preamble()
  File "C:\Python31\lib\wsgiref\handlers.py", line 196, in send_preamble
    self._write('Status: %s\r\n' % self.status)
  File "C:\Python31\lib\wsgiref\handlers.py", line 402, in _write
    self.stdout.write(data)
TypeError: must be str, not bytes
-----

----------
components: Library (Lib)
messages: 108073
nosy: toxicdav3
priority: normal
severity: normal
status: open
title: TypeError in wsgiref.handlers when using CGIHandler
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 18 10:47:31 2010
From: report at bugs.python.org (Greg Hazel)
Date: Fri, 18 Jun 2010 08:47:31 +0000
Subject: [New-bugs-announce] [issue9023] distutils relative path errors
In-Reply-To: <1276850851.53.0.471987336824.issue9023@psf.upfronthosting.co.za>
Message-ID: <1276850851.53.0.471987336824.issue9023@psf.upfronthosting.co.za>


New submission from Greg Hazel <ghazel at users.sourceforge.net>:

Probably applies to more versions, but I only tested on 2.5.2 and 2.6.5.

Distutils incorrectly constructs paths for the build/temp directory when relative paths are used in the "sources" list. This can result in failing to make the build/temp directory at all, and placing files in outside of the build/temp directory.

Consider the following example:

gah at duma:~$ mkdir libfoo
gah at duma:~$ cd libfoo
gah at duma:~/libfoo$ echo > foo.c
gah at duma:~/libfoo$ mkdir pyfoo
gah at duma:~/libfoo$ cd pyfoo
gah at duma:~/libfoo/pyfoo$ echo "from setuptools import setup, Library; setup(name='foo', ext_modules=[Library(name='foo',sources=['../foo.c'])])" > setup.py
gah at duma:~/libfoo/pyfoo$ python setup.py build
running build
running build_ext
building 'foo' extension
creating build
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.5 -c ../foo.c -o build/temp.linux-i686-2.5/../foo.o
Assembler messages:
Fatal error: can't create build/temp.linux-i686-2.5/../foo.o: No such file or directory
error: command 'gcc' failed with exit status 1


Using os.path.abspath('../foo.c') in the sources causes distutils to create build/temp.linux-i686-2.5/home/gah/libfoo/foo.o which is fine. However as a user, this situation is quite surprising, since distutils is responsible for managing the build and temp directories itself.

----------
assignee: tarek
components: Distutils
messages: 108085
nosy: ghazel, tarek
priority: normal
severity: normal
status: open
title: distutils relative path errors
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Jun 18 10:48:49 2010
From: report at bugs.python.org (Tim Golden)
Date: Fri, 18 Jun 2010 08:48:49 +0000
Subject: [New-bugs-announce] [issue9024] PyDateTime_IMPORT macro incorrectly
	marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <4C1B32EB.6020900@timgolden.me.uk>


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

The reference to PyDateTime_IMPORT in the C API datetime docs is marked 
up as cfunction, giving it a pair of brackets which render it invalid. 
There is also no indication of where in the code it should be invoked. 
Patch attached.

----------
files: pydatetime_import.patch
keywords: patch
messages: 108086
nosy: tim.golden
priority: normal
severity: normal
status: open
title: PyDateTime_IMPORT macro incorrectly marked up
Added file: http://bugs.python.org/file17703/pydatetime_import.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9024>
_______________________________________
-------------- next part --------------
Index: c-api/datetime.rst
===================================================================
--- c-api/datetime.rst	(revision 82013)
+++ c-api/datetime.rst	(working copy)
@@ -8,9 +8,9 @@
 Various date and time objects are supplied by the :mod:`datetime` module.
 Before using any of these functions, the header file :file:`datetime.h` must be
 included in your source (note that this is not included by :file:`Python.h`),
-and the macro :cfunc:`PyDateTime_IMPORT` must be invoked.  The macro puts a
-pointer to a C structure into a static variable,  ``PyDateTimeAPI``, that is
-used by the following macros.
+and the macro :cmacro:`PyDateTime_IMPORT` must be invoked, usually as part of
+the module initialisation function.  The macro puts a pointer to a C structure
+into a static variable,  ``PyDateTimeAPI``, that is used by the following macros.
 
 Type-check macros:
 

From report at bugs.python.org  Fri Jun 18 12:20:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jun 2010 10:20:52 +0000
Subject: [New-bugs-announce] [issue9025] Non-uniformity in randrange for
	large arguments.
In-Reply-To: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>
Message-ID: <1276856452.03.0.825027672834.issue9025@psf.upfronthosting.co.za>


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

Not a serious bug, but worth noting:

The result of randrange(n) is not even close to uniform for large n.  Witness the obvious skew in the following (this takes a minute or two to run, so you might want to reduce the range argument):

Python 3.2a0 (py3k:81980, Jun 14 2010, 11:23:36)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from random import randrange
>>> from collections import Counter
>>> Counter(randrange(6755399441055744) % 3 for _ in range(100000000))
Counter({1: 37508130, 0: 33323818, 2: 29168052})

(The actual probabilities here are, as you might guess from the above numbers:  {0: 1/3, 1: 3/8, 2: 7/24}.)

The cause:  for n < 2**53, randrange(n) is effectively computed as int(random() * n).  For small n, there's a tiny bias involved, but this is still an effective method.  However, as n increases towards 2**53, the bias increases significantly.  (For n >= 2**53, the random module uses a different strategy that *does* produce uniformly distributed results.)

A solution would be to lower the cutoff point where randrange() switches from using int(random() * n) to using the _randbelow method.

----------
components: Library (Lib)
messages: 108095
nosy: mark.dickinson, rhettinger
priority: low
severity: normal
status: open
title: Non-uniformity in randrange for large arguments.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 18 12:24:39 2010
From: report at bugs.python.org (Javier)
Date: Fri, 18 Jun 2010 10:24:39 +0000
Subject: [New-bugs-announce] [issue9026] [argparse] Subcommands not printed
	in the same order they	were added
In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>
Message-ID: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za>


New submission from Javier <javier.collado at gmail.com>:

What steps will reproduce the problem?
1. Run 'python subcommands.py -h' (attached file)
2. Check the ordering of the subcommands in the output:
----
subcommands:
  {a,c,b,e,d}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help
----

The ordering between brackets is different than the ordering in the one-line help for each command below. This could be a little confusing to the user.


What is the expected output? What do you see instead?
The expected output would be to use the same ordering in both places. In particular the same ordering that was used in the code when using the _SubParsersAction.add_parser method:
----
subcommands:
  {a,b,c,d,e}
    a          a subcommand help
    b          b subcommand help
    c          c subcommand help
    d          d subcommand help
    e          e subcommand help
----


What version of the product are you using? On what operating system?
OS: Ubuntu
Version: source code (rev. 87)
Python: 2.6.5

Please provide any additional information below.
Please have a look at the attached diff. It contains a patch that worked for me to preserve the ordering used in the code.

To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary).

----------
components: Library (Lib)
files: subcommands.py
messages: 108096
nosy: jcollado
priority: normal
severity: normal
status: open
title: [argparse] Subcommands not printed in the same order they were added
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17704/subcommands.py

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

From report at bugs.python.org  Fri Jun 18 14:20:15 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 12:20:15 +0000
Subject: [New-bugs-announce] [issue9027] add test_support.run_unittest
	command line options and	arguments
In-Reply-To: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>
Message-ID: <1276863615.44.0.266652400766.issue9027@psf.upfronthosting.co.za>


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

Need --help, --list options and TestSute.testcase args for test_support.run_unittest


User story:
I am covering CGIHTTPServer with tests according to http://www.rfc-editor.org/rfc/rfc3875.txt speccy and want to run a single test in a cycle. I am running test cases like:

> python test_httpservers.py

I want to get all available tests in file and execute only the one I need, but test_support.run_unittest doesn't accept any params.

> python test_httpservers.py --help

just runs the test.


I propose to:

1. add list option
-l, --list    list the names of test to be executed and exit
example:
> python test_httpservers.py --list
BaseHTTPServer::command
BaseHTTPServer::handler

I omit `test_` prefix and `TestCase` suffixes as they don't bear any value and just clutter the console. This is my idealistic view.

2. add arguments of test names with wildcards
> python test_httpservers.py --list BaseHTTP*
BaseHTTPServer::command
BaseHTTPServer::handler
> python test_httpservers.py --list *auth*
BaseHTTPServer::handler

----------
components: Tests
messages: 108100
nosy: techtonik
priority: normal
severity: normal
status: open
title: add test_support.run_unittest command line options and arguments
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun 18 15:03:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 18 Jun 2010 13:03:44 +0000
Subject: [New-bugs-announce] [issue9028] test_support.run_unittest cmdline
	options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>


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

Need --help, --list options and TestSute::testcase args for test_support.run_unittest


User story:
I am covering CGIHTTPServer with tests according to http://www.rfc-editor.org/rfc/rfc3875.txt speccy and want to run a single test in a cycle. I am running test cases like:

> python test_httpservers.py

I want to get all available tests in file and execute only the one, but test_support.run_unittest doesn't accept any params.

> python test_httpservers.py --help

just runs all the tests.


I propose to:

1. add list option
-l, --list    list the names of test to be executed and exit

> python test_httpservers.py --list
BaseHTTPServer::command
BaseHTTPServer::handler
CGIHTTPServerTestCase::authorization

I omit `test_` prefix and `TestCase` suffixes as they don't hold any value and just clutter the console. My idealistic vision thinks it is better this way.

2. add arguments of test names with wildcards
> python test_httpservers.py --list BaseHTTP*
BaseHTTPServer::command
BaseHTTPServer::handler
> python test_httpservers.py --list *auth*
CGIHTTPServerTestCase::authorization

3. The final goal is to be able to run single test as:
> python test_httpservers.py BaseHTTPServer::handler
CGIHTTPServer::url_collapse_path_split ... ok

This format will allow to copy/paste single test name for easy execution, which is impossible with current format:
test_url_collapse_path_split (__main__.CGIHTTPServerTestCase) ... ok


One step to make stdlib module debug more intuitive.

----------
components: Tests
messages: 108104
nosy: techtonik
priority: normal
severity: normal
status: open
title: test_support.run_unittest cmdline options and arguments
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun 18 21:43:49 2010
From: report at bugs.python.org (John Van Praag)
Date: Fri, 18 Jun 2010 19:43:49 +0000
Subject: [New-bugs-announce] [issue9029] errors='replace' works in IDLE,
	fails at Windows command line.
In-Reply-To: <1276890229.73.0.493277821026.issue9029@psf.upfronthosting.co.za>
Message-ID: <1276890229.73.0.493277821026.issue9029@psf.upfronthosting.co.za>


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

Platforms:
Windows Vista Ultimate 64 bit
Python v3.1.2

Goal is to read a tab-separated CSV file. Some records have garbage characters in them.

The following code fragment works when the program is run in IDLE, but fails when run from the Windows command line.

...
	fh_read = open(company_info, encoding='utf_8', errors='replace')
	fh_write = open(quotes_file, 'w')
	count = 0
	try:
		rdr = csv.reader(fh_read, delimiter='\t')
		wrt = csv.writer(fh_write, delimiter='\t', quotechar='"', lineterminator='\n')
		for row in rdr:
...

Within IDLE the code works with or without the encoding='utf_8' declaration; and it fails with or without the declaration when run from the Windows command line.

The error message from the Windows command line is as follows:

'charmap' codec can't encode character '\u2019' in position 207: character maps to <undefined>

----------
components: Windows
messages: 108130
nosy: jvanpraag
priority: normal
severity: normal
status: open
title: errors='replace' works in IDLE, fails at Windows command line.
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Jun 18 22:10:32 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Fri, 18 Jun 2010 20:10:32 +0000
Subject: [New-bugs-announce] [issue9030] ctypes variable limits
Message-ID: <1276891832.19.0.947205557485.issue9030@psf.upfronthosting.co.za>


Changes by Pauli Rikula <pauli.rikula at gmail.com>:


----------
assignee: theller
components: ctypes
nosy: kumma, theller
priority: normal
severity: normal
status: open
title: ctypes variable limits

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

From report at bugs.python.org  Fri Jun 18 22:12:32 2010
From: report at bugs.python.org (Matteo Vescovi)
Date: Fri, 18 Jun 2010 20:12:32 +0000
Subject: [New-bugs-announce] [issue9031] distutils uses invalid
	"-Wstrict-prototypes" flag when	compiling C++ extension module
In-Reply-To: <1276891952.43.0.0434978352487.issue9031@psf.upfronthosting.co.za>
Message-ID: <1276891952.43.0.0434978352487.issue9031@psf.upfronthosting.co.za>


New submission from Matteo Vescovi <matteo.vescovi at yahoo.co.uk>:

Hi,

It seems like distutils passes an invalid "-Wstrict-prototypes" flag when compiling a C++ extension module on Linux (tested on Debian lenny and sid).

running build
running build_py
creating build
creating build/lib.linux-i686-2.6
copying presage.py -> build/lib.linux-i686-2.6
running build_ext
building '_presage' extension
creating build/temp.linux-i686-2.6
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -g -Wall -O2 -fPIC -I../../src/lib -I/usr/include/python2.6 -c presage_wrap.cpp -o build/temp.linux-i686-2.6/presage_wrap.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/local/lib -Wl,--as-needed -g -O2 -g -Wall -O2 build/temp.linux-i686-2.6/presage_wrap.o -L../../src/lib/.libs -lpresage -o build/lib.linux-i686-2.6/_presage.so
running build_scripts
creating build/scripts-2.6
copying and adjusting presage_python_demo -> build/scripts-2.6
changing mode of build/scripts-2.6/presage_python_demo from 644 to 755

I did a bit of digging on this one. It looks like distutils reuses whatever flags python was built with.

matt at burrow:/usr/lib/python2.5/distutils$ python2.5
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var("CFLAGS")
'-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes'
>>>

In /usr/lib/python2.5/distutils/unixcompiler.py I found this comment:

# XXX Things not currently handled:
#   * optimization/debug/warning flags; we just use whatever's in Python's
#     Makefile and live with it.  Is this adequate?  If not, we might
#     have to have a bunch of subclasses GNUCCompiler, SGICCompiler,
#     SunCCompiler, and I suspect down that road lies madness.


It would be nice is distutils was smart enough to recognize that a c++ module was being built and to strip the unneeded flags.

Please consider this as a wishlist request, as this causes only a warning, not a failure.


Cheers,
- Matteo

----------
assignee: tarek
components: Distutils
messages: 108136
nosy: matteo.vescovi, tarek
priority: normal
severity: normal
status: open
title: distutils uses invalid "-Wstrict-prototypes" flag when compiling C++ extension module
type: feature request
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Sat Jun 19 00:32:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jun 2010 22:32:26 +0000
Subject: [New-bugs-announce] [issue9032] xmlrpc: Transport.request() should
	also catch	socket.error(EPIPE)
In-Reply-To: <1276900346.42.0.945858543799.issue9032@psf.upfronthosting.co.za>
Message-ID: <1276900346.42.0.945858543799.issue9032@psf.upfronthosting.co.za>


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

Since Python 2.7 / 3.2, httplib supports HTTP(S)/1.1 (keep-alive). This version of HTTP is much faster because the connection is kept between two requests. I'm using it with XML-RPC + SSL (M2Crypto). It works nice.

My problem is when the server closes the connection (eg. the server restarts). If I send a small (XML-RPC) request, sending the request works (I don't understand why, maybe because of a buffer somewhere), but getting the response raises a BadStatusLine because the response is empty (0 byte). If I send a big (XML-RPC) request, sending the request fails with a SSLError(EPIPE, '...') and Transport.request() doesn't retry with a new connection.

I patched my copy of M2Crypto to ensure that SSLError inherits from socket.error, but it's not enough: Transport.request() only catchs errno.ECONNRESET and errno.ECONNABORTED socket errors.

Attached patch catchs also errno.EPIPE. This error is received on sending to the socket whereas the server closed the socket.

----------
components: Library (Lib)
files: xmlrpc_request_epipe.patch
keywords: patch
messages: 108146
nosy: haypo
priority: normal
severity: normal
status: open
title: xmlrpc: Transport.request() should also catch socket.error(EPIPE)
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17715/xmlrpc_request_epipe.patch

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

From report at bugs.python.org  Sat Jun 19 17:10:16 2010
From: report at bugs.python.org (scott riccardelli)
Date: Sat, 19 Jun 2010 15:10:16 +0000
Subject: [New-bugs-announce] [issue9033] cmd module tab misbehavior
In-Reply-To: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>
Message-ID: <1276960216.2.0.17858038653.issue9033@psf.upfronthosting.co.za>


New submission from scott riccardelli <s.riccardelli at gmail.com>:

noticed that cmd module does not perform completion using TAB on a macintosh properly.  instead, the TAB key just places several blank spaces and moves the cursor forward.  what it should do is retrieve a list of possibilities for completing a command.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 108185
nosy: ronaldoussoren, slcott
priority: normal
severity: normal
status: open
title: cmd module tab misbehavior
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 20 03:44:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 20 Jun 2010 01:44:18 +0000
Subject: [New-bugs-announce] [issue9034] datetime module should use int32_t
	for date/time	components
In-Reply-To: <1276998258.21.0.743259532258.issue9034@psf.upfronthosting.co.za>
Message-ID: <1276998258.21.0.743259532258.issue9034@psf.upfronthosting.co.za>


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

"""
As an aside, I dislike the fact that the datetime module uses a C 'int' for date ordinals, and clearly assumes that it'll be at least 32 bits.  int could be as small as 16 bits on some systems (small embedded systems?).  But that's another issue.
""" -- Mark Dickinson 

A comment and an assertion at the top of the module suggest that this was deliberate.

/* We require that C int be at least 32 bits, and use int virtually                                                                                  
 * everywhere.  In just a few cases we use a temp long, where a Python                                                                               
 * API returns a C long.  In such cases, we have to ensure that the                                                                                  
 * final result fits in a C int (this can be an issue on 64-bit boxes).                                                                              
 */
#if SIZEOF_INT < 4
#       error "datetime.c requires that C int have at least 32 bits"
#endif

However, since ranges of all integers are well defined in this module, there is little to be gained from the uncertainty about sizes of int and long. (For example, the allowed range of dates will not magically increase on a platform with 64 bit ints.)

I propose using explicitly sized C99 types int32_t and int64_t or rather their blessed for use in python equivalents PY_INTXX_T) throughout the module.

----------
assignee: belopolsky
components: Extension Modules
messages: 108222
nosy: belopolsky, mark.dickinson
priority: low
severity: normal
stage: needs patch
status: open
title: datetime module should use int32_t for date/time components
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 20 10:49:11 2010
From: report at bugs.python.org (Oren Held)
Date: Sun, 20 Jun 2010 08:49:11 +0000
Subject: [New-bugs-announce] [issue9035] os.path.ismount on windows doesn't
	support windows mount	points
In-Reply-To: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>
Message-ID: <1277023751.91.0.438330382261.issue9035@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

On unices, ismount checks whether the given path is a mount point.
On windows, it only checks whether it's a drive letter.

Long story short, Python simply returns False when doing ismount(r"c:\mount1"), while c:\mount1 is a real mount point.

This is relevant for all modern windows versions.

-- 

I'm using win32file.GetVolumePathName() for overcoming this, but I'm not sure if the os python package should be importing win32file, maybe there is a better way to check whether a path is a mount point..

----------
components: Windows
messages: 108225
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: os.path.ismount on windows doesn't support windows mount points
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Jun 20 15:12:08 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 20 Jun 2010 13:12:08 +0000
Subject: [New-bugs-announce] [issue9036] Simplify Py_CHARMASK
In-Reply-To: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>
Message-ID: <1277039528.15.0.539020018856.issue9036@psf.upfronthosting.co.za>


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

This feature request is extracted from issue 9020, where Py_CHARMASK(c)
was used on EOF, producing different results depending on whether __CHAR_UNSIGNED__ is defined or not.

The preferred fix for issue 9020 is to check for EOF before using
Py_CHARMASK, so this is only loosely related.


I've looked through the source tree to determine how Py_CHARMASK
is meant to be used. It seems that it is only used in situations
where one would actually want to cast a char to an unsigned char,
like isspace((unsigned char)c).


Simplifications:

1) Python.h already enforces that an unsigned char is 8 bit wide. Thus,
   ((unsigned char)((c) & 0xff)) and ((unsigned char)(c)) should produce
   the same results.

2) There is no reason not to do the cast when __CHAR_UNSIGNED__ is
   defined (it will be a no-op).

----------
components: Interpreter Core
files: py_charmask.patch
keywords: needs review, patch
messages: 108234
nosy: eric.smith, loewis, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify Py_CHARMASK
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17724/py_charmask.patch

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

From report at bugs.python.org  Sun Jun 20 18:55:06 2010
From: report at bugs.python.org (Jonathan G. Underwood)
Date: Sun, 20 Jun 2010 16:55:06 +0000
Subject: [New-bugs-announce] [issue9037] Add explanation as to how to raise
	a custom exception in	the extending python intermezzo on exceptions
In-Reply-To: <1277052906.52.0.842872873757.issue9037@psf.upfronthosting.co.za>
Message-ID: <1277052906.52.0.842872873757.issue9037@psf.upfronthosting.co.za>


New submission from Jonathan G. Underwood <jonathan.underwood at gmail.com>:

In the documentation section on Extending Python with C or C++ there is an Intermezzo on Errors and Exceptions which shows how to create a custom exception in an extension module. I was just following these instructions for the first time and got to the end and was left wondering how to actually raise the custom exception in my new module, and it wasn't immediately obvious, so I propose to add a brief explanation to the end of that section explaining how. Patch attached.

----------
assignee: docs at python
components: Documentation
files: extending_how_to_raise_exception.patch
keywords: patch
messages: 108239
nosy: docs at python, jonathan.underwood
priority: normal
severity: normal
status: open
title: Add explanation as to how to raise a custom exception in the extending python intermezzo on exceptions
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17725/extending_how_to_raise_exception.patch

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

From report at bugs.python.org  Sun Jun 20 22:48:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jun 2010 20:48:21 +0000
Subject: [New-bugs-announce] [issue9038] test_distutils failure
In-Reply-To: <1277066901.58.0.116708897563.issue9038@psf.upfronthosting.co.za>
Message-ID: <1277066901.58.0.116708897563.issue9038@psf.upfronthosting.co.za>


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

test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/ssl-8524/Lib/distutils/tests/support.py", line 16, in _capture_warnings
    return func(*args, **kw)
  File "/home/antoine/py3k/ssl-8524/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
    self.assertTrue(os.path.isdir(inc_dir), inc_dir)
AssertionError: /home/antoine/py3k/ssl-8524/build/test_python_15977/Include

----------
assignee: tarek
components: Distutils, Tests
messages: 108247
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: test_distutils failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 21 00:44:13 2010
From: report at bugs.python.org (Yoda_Uchiha)
Date: Sun, 20 Jun 2010 22:44:13 +0000
Subject: [New-bugs-announce] [issue9039] IDLE and module Doc
In-Reply-To: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>
Message-ID: <1277073853.62.0.33861554581.issue9039@psf.upfronthosting.co.za>


New submission from Yoda_Uchiha <MMPyro55 at gmail.com>:

I recently installed python 3.1 on a Windows XP computer. I cannot open IDLE nor module Docs. When I click on them, nothing happens. I am wondering if there is anyway on opening either of those too files. I do know how to IDLE through the workaround listed below but i have to put that in everytime to open IDLE. I am wondering if there was a permanent fix so i can just open if from my desktop. 
C:\>set TCL_LIBRARY= 
C:\>set TK_LIBRARY= 
C:\>C:\Python31\python.exe C:\Python31\Lib\idlelib\idle.py

----------
components: IDLE
messages: 108251
nosy: Yoda_Uchiha
priority: normal
severity: normal
status: open
title: IDLE and module Doc
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 21 10:20:29 2010
From: report at bugs.python.org (Enrico Sartori)
Date: Mon, 21 Jun 2010 08:20:29 +0000
Subject: [New-bugs-announce] [issue9040] using MIMEApplication to attach a
	PDF raises a TypeError	exception
In-Reply-To: <1277108429.25.0.109783634019.issue9040@psf.upfronthosting.co.za>
Message-ID: <1277108429.25.0.109783634019.issue9040@psf.upfronthosting.co.za>


New submission from Enrico Sartori <enrypif at gmail.com>:

To send an email with a PDF attachment the following code should work:

msg = MIMEMultipart()
msg['From'] = from
msg['To'] = to
msg['Subject'] = 'test'
fp = open('/path/to/file.pdf', 'rb')
attach = MIMEApplication(fp.read(), 'pdf')
fp.close()
attach.add_header('Content-Disposition', 'attachment', filename = 'file.pdf')
msg.attach(attach)
server = smtplib.SMTP('smtp.example.com')
server.login('username', 'password')
server.sendmail(from, to, msg.as_string())
server.quit()

But an exception is raised:

TypeError: string payload expected: <class 'bytes'>

To work around the problem the code above can be rewritten as follows:

msg = MIMEMultipart()
msg['From'] = from
msg['To'] = to
msg['Subject'] = 'test'
fp = open('/path/to/file.pdf', 'rb')
attach = MIMENonMultipart('application', 'pdf')
payload = base64.b64encode(fp.read()).decode('ascii')
attach.set_payload(payload)
attach['Content-Transfer-Encoding'] = 'base64'
fp.close()
attach.add_header('Content-Disposition', 'attachment', filename = 'file.pdf')
msg.attach(attach)
server = smtplib.SMTP('smtp.example.com')
server.login('username', 'password')
server.sendmail(from, to, msg.as_string())
server.quit()

This works, but explicit encoding should not be necessary.

----------
components: Library (Lib)
messages: 108256
nosy: Enrico.Sartori
priority: normal
severity: normal
status: open
title: using MIMEApplication to attach a PDF raises a TypeError exception
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 21 14:23:33 2010
From: report at bugs.python.org (Pauli Rikula)
Date: Mon, 21 Jun 2010 12:23:33 +0000
Subject: [New-bugs-announce] [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>


New submission from Pauli Rikula <pauli.rikula at gmail.com>:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.c_double(-10L)
c_double(-10.0)
>>> ctypes.c_double(-16158503035655503650357438344334975980222051334857742016065172713762327569433945446598600705761456731844358980460949009747059779575245460547544076193224141560315438683650498045875098875194826053398028819192033784138396109321309878080919047169238085235290822926018152521443787945770532904303776199561965192761047051351577287005728952652821735984108986866610276357675617870244379434256980638641483535093292326373531858799166625357628570460558031263448272521936380684506350754039141397287742159767011772534248723062567540713722795836229745796676103584020939467516975660579180998612463422664938089473950280866877864444041L)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError:  float expected instead of long instance

.. vs:

>>> float(-16158503035655503650357438344334975980222051334857742016065172713762327569433945446598600705761456731844358980460949009747059779575245460547544076193224141560315438683650498045875098875194826053398028819192033784138396109321309878080919047169238085235290822926018152521443787945770532904303776199561965192761047051351577287005728952652821735984108986866610276357675617870244379434256980638641483535093292326373531858799166625357628570460558031263448272521936380684506350754039141397287742159767011772534248723062567540713722795836229745796676103584020939467516975660579180998612463422664938089473950280866877864444041L)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

----------
assignee: theller
components: ctypes
messages: 108265
nosy: kumma, theller
priority: normal
severity: normal
status: open
title: raised exception is misleading
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 21 15:23:39 2010
From: report at bugs.python.org (v_peter)
Date: Mon, 21 Jun 2010 13:23:39 +0000
Subject: [New-bugs-announce] [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>


New submission from v_peter <leanmeandonothingmachine at gmail.com>:

If you pass gettext.translation a class_ but the mo file you are trying to open already exists in the _translations cache the instance that is returned is an instance of whatever was in the cache and not the class that you requested.

I think that if a class is requested it should return that class. If others agree then I'd be happy to work on a patch.

----------
components: Library (Lib)
messages: 108270
nosy: v_peter
priority: normal
severity: normal
status: open
title: Gettext cache and classes
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 21 16:46:15 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Mon, 21 Jun 2010 14:46:15 +0000
Subject: [New-bugs-announce] [issue9043] 2to3 doesn't handle byte comparison
	well
In-Reply-To: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>
Message-ID: <1277131575.09.0.876680898489.issue9043@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

If we run 2to3 on the following code:

s = b' '
print s[0] == s

we end up with this:

s = b' '
print(s[0] == s)

However, the first code, under python2 prints True while the converted code, under python3 prints False.

Shouldn't 2to3 convert this code to:

s = b' '
print s[0:1] == s

instead?

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 108272
nosy: vdupras
priority: normal
severity: normal
status: open
title: 2to3 doesn't handle byte comparison well
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 21 18:05:31 2010
From: report at bugs.python.org (Krzysztof Szawala)
Date: Mon, 21 Jun 2010 16:05:31 +0000
Subject: [New-bugs-announce] [issue9044] [optparse] confusion over an option
	and its value without	any space in between
In-Reply-To: <1277136331.24.0.0452022727538.issue9044@psf.upfronthosting.co.za>
Message-ID: <1277136331.24.0.0452022727538.issue9044@psf.upfronthosting.co.za>


New submission from Krzysztof Szawala <kszawala at slb.com>:

Currently optparse library supports the following option definitions:
-e value,
-e=value,
-e:value,
-evalue.

Having said that let's consider the following option definition:
-e <string_value>.

Based on the above syntax the following statement will be correct:
-exclusive
and will be parsed into -e xclusive.
The fact that no caracter is required in between the option itself and its value leads to confusion.

My suggestion is to restrict the syntax to the following:
-e value,
-e=value,
-e:value.

Thanks,
Krzysztof

----------
components: Library (Lib)
messages: 108280
nosy: kszawala
priority: normal
severity: normal
status: open
title: [optparse] confusion over an option and its value without any space in between
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 21 20:02:21 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Jun 2010 18:02:21 +0000
Subject: [New-bugs-announce] [issue9045] 2.7rc1: 64-bit OSX installer is not
	built with 64-bit	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>


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

It appears that we are building 64-bit mac installer starting 2.7. For http://python.org/ftp/python/2.7/python-2.7rc1-macosx10.5-2010-06-07.dmg

$ file /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: Mach-O universal binary with 2 architectures
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so (for architecture ppc7400):     Mach-O bundle ppc
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so (for architecture i386):        Mach-O bundle i386

$ python2.7 -c "import _tkinter"
Traceback (most recent call last):
  File "<string>", line 1, in<module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so, 2): no suitable image found.  Did find:
        /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so: no matching architecture in universal wrapper
$

----------
assignee: ronaldoussoren
components: IDLE, Macintosh, Tkinter
messages: 108292
nosy: ronaldoussoren, srid
priority: normal
severity: normal
status: open
title: 2.7rc1: 64-bit OSX installer is not built with 64-bit tkinter
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 21 20:35:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 18:35:56 +0000
Subject: [New-bugs-announce] [issue9046] Python 2.7rc2 doesn't build on Mac
	OS X 10.3
In-Reply-To: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>
Message-ID: <1277145356.65.0.792770780459.issue9046@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

The RC2 builds fine on Mac OS X 10.6 (Snow Leopard), but fails to build any of the required extension modules on 10.3:

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             gdbm               linuxaudiodev
ossaudiodev        readline           spwd
sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_AE                _AH                _App
_bisect            _CarbonEvt         _CF
_CG                _Cm                _codecs_cn
_codecs_hk         _codecs_iso2022    _codecs_jp
_codecs_kr         _codecs_tw         _collections
_csv               _Ctl               _ctypes
_ctypes_test       _curses            _curses_panel
_Dlg               _Drag              _elementtree
_Evt               _File              _Fm
_Folder            _functools         _hashlib
_heapq             _Help              _hotshot
_IBCarbon          _Icn               _io
_json              _Launch            _List
_locale            _lsprof            _Menu
_Mlte              _multibytecodec    _multiprocessing
_OSA               _Qd                _Qdoffs
_Qt                _random            _Res
_Scrap             _sha256            _sha512
_Snd               _socket            _sqlite3
_ssl               _struct            _TE
_testcapi          _tkinter           _weakref
_Win               array              audioop
autoGIL            binascii           bsddb185
bz2                cmath              ColorPicker
cPickle            crypt              cStringIO
datetime           dbm                dl
fcntl              future_builtins    gestalt
grp                icglue             imageop
itertools          MacOS              math
mmap               Nav                nis
operator           OSATerminology     parser
pyexpat            resource           select
strop              syslog             termios
time               unicodedata        zlib

Example:

building '_struct' extension
gcc-4.0 -fno-strict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Mac/Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2/Include -I/usr/local/src/egenix-build-environment/Python-2.7rc2-ucs2 -c _struct.c -o build/temp.macosx-10.4-fat-2.7/_struct.o
powerpc-apple-darwin8-gcc-4.0.1: _struct.c: No such file or directory
powerpc-apple-darwin8-gcc-4.0.1: no input files
i686-apple-darwin8-gcc-4.0.1: _struct.c: No such file or directory
i686-apple-darwin8-gcc-4.0.1: no input files
lipo: can't figure out the architecture type of: /var/tmp//cckP7ZEq.out
...

These were the used configure options:

./configure  --prefix=/usr/local/python-2.7-ucs2 --enable-unicode=ucs2 --enable-universalsdk MACOSX_DEPLOYMENT_TARGET=10.4

----------
assignee: ronaldoussoren
components: Build
messages: 108294
nosy: lemburg, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 2.7rc2 doesn't build on Mac OS X 10.3
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 21 20:38:13 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 21 Jun 2010 18:38:13 +0000
Subject: [New-bugs-announce] [issue9047] Python 2.7rc2 includes -isysroot
	twice on each gcc	command line
In-Reply-To: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>
Message-ID: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

A typical build line looks like this:

gcc-4.0 -c -fno-strict-aliasing -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include -isysroot /Developer/SDKs/MacOSX10.4u.sdk   -DPy_BUILD_CORE -o Python/codecs.o Python/codecs.c

With older Xcode releases, the above is known not to work at all: gcc simply gives up and raises an error. With the latest Xcode available for 10.3 (last release + all patches), gcc accepts the extra options, but it's not clear whether the resulting code will work... mostly due to #9046: Python 2.7rc2 doesn't build on Mac OS X 10.3.

The two issues could also be connected.

----------
assignee: ronaldoussoren
components: Build
messages: 108295
nosy: lemburg, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 2.7rc2 includes -isysroot twice on each gcc command line
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 21 21:25:42 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 21 Jun 2010 19:25:42 +0000
Subject: [New-bugs-announce] [issue9048] no OS X buildbots in the stable list
In-Reply-To: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>
Message-ID: <1277148342.98.0.18086046529.issue9048@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

Considering the number of OS X machines running Python programs, it would be good idea to get this platform into the "stable" list of buildbots so that releases are checked against it.

----------
messages: 108302
nosy: janssen
priority: normal
severity: normal
status: open
title: no OS X buildbots in the stable list
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 21 21:46:39 2010
From: report at bugs.python.org (Andreas Hofmeister)
Date: Mon, 21 Jun 2010 19:46:39 +0000
Subject: [New-bugs-announce] [issue9049] UnboundLocalError in nested function
In-Reply-To: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>
Message-ID: <1277149599.18.0.763779339646.issue9049@psf.upfronthosting.co.za>


New submission from Andreas Hofmeister <andreas.hofmeister at yahoo.de>:

Description:
An unexpected UnboundLocalError is produced when assigning a value to a variable inside a nested function. The first assignment to the variable is in the enclosing function.

Example:
def x():
     a = False
     def y():
         print a
         a = True
     return y

Calling x()() produces an UnboundLocalError on the 'print a' line.
If the 'a = True' line is removed, no error occurs.

Tested with:
  - 2.5.1
  - 2.6.5

Keywords: 
Nested function, UnboundLocalError, variable assignment

Thank you for your attention

----------
components: Interpreter Core
messages: 108306
nosy: Andreas Hofmeister
priority: normal
severity: normal
status: open
title: UnboundLocalError in nested function
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Jun 21 21:46:41 2010
From: report at bugs.python.org (Andreas Hofmeister)
Date: Mon, 21 Jun 2010 19:46:41 +0000
Subject: [New-bugs-announce] [issue9050] UnboundLocalError in nested function
In-Reply-To: <1277149601.0.0.820188048763.issue9050@psf.upfronthosting.co.za>
Message-ID: <1277149601.0.0.820188048763.issue9050@psf.upfronthosting.co.za>


New submission from Andreas Hofmeister <andreas.hofmeister at yahoo.de>:

Description:
An unexpected UnboundLocalError is produced when assigning a value to a variable inside a nested function. The first assignment to the variable is in the enclosing function.

Example:
def x():
     a = False
     def y():
         print a
         a = True
     return y

Calling x()() produces an UnboundLocalError on the 'print a' line.
If the 'a = True' line is removed, no error occurs.

Tested with:
  - 2.5.1
  - 2.6.5

Keywords: 
Nested function, UnboundLocalError, variable assignment

Thank you for your attention

----------
components: Interpreter Core
messages: 108307
nosy: Andreas Hofmeister
priority: normal
severity: normal
status: open
title: UnboundLocalError in nested function
type: behavior
versions: Python 2.5, Python 2.6

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

From report at bugs.python.org  Mon Jun 21 22:15:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Jun 2010 20:15:08 +0000
Subject: [New-bugs-announce] [issue9051] Cannot pickle timezone instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>


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

>>> s = pickle.dumps(timezone.utc)
>>> pickle.loads(s)
Traceback (most recent call last):
 ..
TypeError: ("Required argument 'offset' (pos 1) not found", <class 'datetime.timezone'>, ())

----------
assignee: belopolsky
messages: 108313
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: Cannot pickle timezone instances
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 21 22:34:38 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 21 Jun 2010 20:34:38 +0000
Subject: [New-bugs-announce] [issue9052] 2.7rc2 fails test_urllib_localnet
	tests on OS X
In-Reply-To: <1277152478.13.0.221509017711.issue9052@psf.upfronthosting.co.za>
Message-ID: <1277152478.13.0.221509017711.issue9052@psf.upfronthosting.co.za>


New submission from Bill Janssen <bill.janssen at gmail.com>:

% ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_urllib2_localnet
== CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)]
==   Darwin-9.8.0-i386-32bit little-endian
==   /private/tmp/Python-2.7rc2/build/test_python_58063
test_urllib2_localnet
test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL
test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... FAIL
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

======================================================================
FAIL: test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 264, in test_proxy_with_bad_password_raises_httperror
    self.URL)
AssertionError: HTTPError not raised

======================================================================
FAIL: test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 270, in test_proxy_with_no_password_raises_httperror
    self.URL)
AssertionError: HTTPError not raised

----------------------------------------------------------------------
Ran 13 tests in 9.050s

FAILED (failures=2)
test test_urllib2_localnet failed -- multiple errors occurred
1 test failed:
    test_urllib2_localnet
/tmp/Python-2.7rc2 397 %

----------
messages: 108314
nosy: janssen
priority: high
severity: normal
stage: needs patch
status: open
title: 2.7rc2 fails test_urllib_localnet tests on OS X
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 22 00:03:31 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 21 Jun 2010 22:03:31 +0000
Subject: [New-bugs-announce] [issue9053] distutils compiles extensions so
	that Python.h cannot be	found
In-Reply-To: <1277157811.25.0.502780750068.issue9053@psf.upfronthosting.co.za>
Message-ID: <1277157811.25.0.502780750068.issue9053@psf.upfronthosting.co.za>


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

With a checkout of the py3k branch, building an extension module using distutils fails:

  error: Python.h: No such file or directory

This is clearly because the wrong -I option is being supplied:

  gcc -pthread -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/exarkun/Projects/python-signalfd/trunk/Include -I/home/exarkun/Projects/python/branches/py3k -c signalfd/_signalfd.c -o build/temp.linux-i686-3.2/signalfd/_signalfd.o

Building the extension with Python 3.1 all the way back through Python 2.3 does work, though.

----------
assignee: tarek
components: Distutils
messages: 108321
nosy: exarkun, tarek
priority: critical
severity: normal
status: open
title: distutils compiles extensions so that Python.h cannot be found
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun 22 00:12:50 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 21 Jun 2010 22:12:50 +0000
Subject: [New-bugs-announce] [issue9054] pyexpat configured with
	"--with-system-expat" is	incompatible with expat 2.0.1
In-Reply-To: <1277158370.27.0.787157062055.issue9054@psf.upfronthosting.co.za>
Message-ID: <1277158370.27.0.787157062055.issue9054@psf.upfronthosting.co.za>


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

pyexpat configured with "--with-system-expat" segfaults in one selftest when built against expat 2.0.1

SVN trunk:
$ ./configure --with-system-expat
(with expat-2.0.1)
$ make
$ ./python Lib/test/test_pyexpat.py
[snip]
test_parse_only_xml_data (__main__.sf1296433Test) ... Segmentation fault (core dumped)

The issue occurs when an exception happens within a character handler.

When a Python exception is raised inside pyexpat.c:call_character_handler(), it invokes pyexpat.c:flag_error() which clears the pyexpat object's handlers, and it then sets the expat structure's handler to a no-op handler:
        XML_SetCharacterDataHandler(self->itself,
                                    noop_character_data_handler);

The reason why appears to be that python's copy of that code in xmlparse.c:doContent() looks like this:
            characterDataHandler(handlerArg, dataBuf,
                                 (int)(dataPtr - (ICHAR *)dataBuf));

(see
http://svn.python.org/view/python/trunk/Modules/expat/xmlparse.c?annotate=77680&pathrev=77680#l2544
)

i.e. using:
  #define characterDataHandler (parser->m_characterDataHandler)
to look up the handler each time, thus picking up on the newly installed noop handler, whereas the corresponding code in expat 2.0.1 looks like this:

        XML_CharacterDataHandler charDataHandler = characterDataHandler;
        if (charDataHandler) {
            ...
            for (;;) {
              ...
=>            charDataHandler(handlerArg, dataBuf,
                              (int)(dataPtr - (ICHAR *)dataBuf));
              ...
            }
          }

i.e. keeping the old function pointer cached

(gdb) p self->itself->m_characterDataHandler 
$30 = (XML_CharacterDataHandler) 0xf8b370 <noop_character_data_handler>

(gdb) p charDataHandler
$31 = (XML_CharacterDataHandler) 0xf8daf0 <my_CharacterDataHandler>

So when the exception is raised and the handler is changed, the local in the loop doesn't change, and we're calling the old handler which doesn't allow for being in the error-recovery state, and self->handlers[3] is NULL, leading to an eventual segfault.

This is with expat-2.0.1-10.fc13.i686 on a Fedora 13 box.

expat's xmlparse.c's caching of the character handler appears to be this
change:
http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmlparse.c?r1=1.157&r2=1.158

> Revision 1.158 - (view) (download) (annotate) - [select for diffs] 
> Mon Jul 10 18:59:52 2006 UTC (3 years, 10 months ago) by kwaclaw 
> Branch: MAIN 
> Changes since 1.157: +39 -37 lines 
> Diff to previous 1.157
> Improved fix for issues # 1515266 and # 1515600. Will now preserve the
> "failover to default handler" logic. Note: clearing the character data handler
> does not take effect immediately anymore.

which is almost 4 years old (2006-07-10)

For reference the issues referred to above are:
http://sourceforge.net/tracker/?func=detail&aid=1515266&group_id=10127&atid=110127
http://sourceforge.net/tracker/?func=detail&aid=1515600&group_id=10127&atid=110127

expat CVS R_2_0_0 has xmlparse.c r1.151 from 2005-12-23
expat CVS R_2_0_1 has xmlparse.c r1.161 from 2007-05-08

So it appears that this "clearing the character data handler does not take
effect immediately anymore." is in expat 2.0.1 onwards, but not in 2.0.0

Running:
$ diff -rup ~/coding/python-svn/trunk-clean/Modules/expat
/usr/src/debug/expat-2.0.1/lib/|less
to show the difference between system expat and latest python SVN code
indicates that we're using 2.0.1 as the system copy, and latest Python SVN code
is using a copy of 2.0.0

Looking at http://bugs.python.org/issue1296433 (as per the test name), this was fixed in r47191 (see http://svn.python.org/view?view=rev&revision=47191 ) on 2006-07-01, adding a termination clause to the loop within its copy of xmlparse.c but this was followed five days later (2006-07-06) with:
http://svn.python.org/view?view=rev&revision=47253
which had the log:
> - back out Expat change; the final fix to Expat will be different
> - change the pyexpat wrapper to not be so sensitive to this detail of the
>  Expat implementation (the ex-crasher test still passes)

though this change happened before the change in expat on 2006-07-10

So, _if_ I'm reading this right, it appears that Python's pyexpat.c module is incompatible with expat 2.0.1: pyexpat expects that when it sets:
    XML_SetCharacterDataHandler(self->itself,
                                noop_character_data_handler);
that my_CharacterDataHandler will no longer be called, but it is, and it segfaults during the test.

Working around it appears trivial; I will attach a patch.

----------
components: XML
messages: 108323
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: pyexpat configured with "--with-system-expat" is incompatible with expat 2.0.1

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

From report at bugs.python.org  Tue Jun 22 00:39:29 2010
From: report at bugs.python.org (Paul Moore)
Date: Mon, 21 Jun 2010 22:39:29 +0000
Subject: [New-bugs-announce] [issue9055] test_issue_8959_b fails when run
	from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>


New submission from Paul Moore <p.f.moore at gmail.com>:

test_issue_8959_b fails when run from a service (in this case, from a buildslave running as a service).

It appears to count the number of open windows, expecting a non-zero value. But when run as a service, it looks like the return count is (correctly) zero.

FAIL: test_issue_8959_b (ctypes.test.test_callbacks.SampleCallbacksTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "C:\buildslave\trunk.moore-windows\build\lib\ctypes\test\test_callbacks.py",
line 208, in test_issue_8959_b
   self.assertFalse(windowCount == 0)
AssertionError: True is not False

----------
assignee: theller
components: ctypes
keywords: buildbot
messages: 108328
nosy: pmoore, theller
priority: normal
severity: normal
status: open
title: test_issue_8959_b fails when run from a service
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 22 05:00:37 2010
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 22 Jun 2010 03:00:37 +0000
Subject: [New-bugs-announce] [issue9056] Adding additional level of
	bookmarks and section numbers	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>


New submission from pengyu.ut <pengyu.ut at gmail.com>:

Current pdf version of python documents don't have bookmarks for
sussubsection. For example, there is no bookmark for the following
section in python_2.6.5_reference.pdf. Also the bookmarks don't have
section numbers in them. I suggest to include the section numbers.
Could these features be added in future release of python document.

3.4.1 Basic customization

----------
assignee: docs at python
components: Documentation
messages: 108334
nosy: docs at python, pengyu.ut
priority: normal
severity: normal
status: open
title: Adding additional level of bookmarks and section numbers in python pdf documents.
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 22 16:58:06 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 22 Jun 2010 14:58:06 +0000
Subject: [New-bugs-announce] [issue9057] Needs a home page
In-Reply-To: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>
Message-ID: <1277218686.54.0.776970165473.issue9057@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

This project needs a home page. I want to link to it from Ryppl docs, but anyone following a link to, e.g. the bitbucket wiki would think this project was weak at best.

----------
assignee: tarek
components: Distutils2
messages: 108390
nosy: dabrahams, tarek
priority: normal
severity: normal
status: open
title: Needs a home page

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

From report at bugs.python.org  Tue Jun 22 20:08:45 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 22 Jun 2010 18:08:45 +0000
Subject: [New-bugs-announce] [issue9058] PyUnicodeDecodeError_Create asserts
	that various	arguments are less than INT_MAX
In-Reply-To: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>
Message-ID: <1277230125.41.0.418580473823.issue9058@psf.upfronthosting.co.za>


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

Running this code (seen via http://bugs.python.org/file10013/python-2.5.2-unicode_resize-utf16.py for issue 2620):
>>> msg = 'A'*2147483647 ; msg.decode('utf16')
leads to the python process exiting with an assertion failure:
python: Objects/exceptions.c:1787: PyUnicodeDecodeError_Create: Assertion `length < 2147483647' failed.

The reaason is that PyUnicodeDecodeError_Create contains this code:
PyObject *
PyUnicodeDecodeError_Create(
    const char *encoding, const char *object, Py_ssize_t length,
    Py_ssize_t start, Py_ssize_t end, const char *reason)
{
    assert(length < INT_MAX);
    assert(start < INT_MAX);
    assert(end < INT_MAX);
    return PyObject_CallFunction(PyExc_UnicodeDecodeError, "ss#nns",
                                 encoding, object, length, start, end, reason);
}

In the example above, we're creating a buffer containing a very large but odd-numbered of bytes, and trying to UTF-16 decode it, which requires an even number of bytes.

This leads to a UnicodeDecodeError with a very large value for each of length, start, and end, and although they fit in Py_ssize_t on 64-bit, they don't fit in an int.  

It seems that this will affect any other decoding errors for buffers that are >= INT_MAX in size: unicode decode errors will cause the python process to bail out with an assert failure.

It appears that throughout the UnicodeDecodeError representation that length, start and size are to be of size Py_ssize_t, rather than int: they are stored in fields of type Py_ssize_t, they are printed using format "%zd", which is indeed a Py_ssize_t (see http://docs.python.org/c-api/string.html#PyString_FromFormat ).

In PyUnicodeDecodeError_Create, "ss#nns" is:
  - "s" (string) [char *]: "encoding"
  - "s#" (string) [char *, int]:"object", "length"

  - "n" (int) [Py_ssize_t]: "start"
  - "n" (int) [Py_ssize_t]: "end"
  - "s" (string) [char *]: "reason"

See Python/modsupport.c: do_mkvalue: "s#" uses this logic:
				if (flags & FLAG_SIZE_T)
					n = va_arg(*p_va, Py_ssize_t);
				else
					n = va_arg(*p_va, int);
where FLAG_SIZE_T is set by _Py_BuildValue_SizeT, but not by Py_BuildValue.  The latter is what's called by PyObject_CallFunction.

Hence, as written, "length" must fit within an "int", but "start" and "end" don't have to.

"s#" calls PyString_FromStringAndSize(str, n) upon the data, which takes a Py_ssize_t.  It's going to be big, but may well fit in RAM (but might not).

The invoked function leads to a call to: UnicodeError_init, which calls:
    if (!PyArg_ParseTuple(args, "O!O!nnO!",
        &PyString_Type, &self->encoding,
        objecttype, &self->object,
        &self->start,
        &self->end,
        &PyString_Type, &self->reason)) {

"O!": (object) [typeobject, PyObject *]: &PyString_Type, &self->encoding,
"O!": (object) [typeobject, PyObject *]: objecttype, &self->object  (objecttype is passed as &PyString_Type)
"n": (integer) [Py_ssize_t]: &self->start,
"n": (integer) [Py_ssize_t]: &self->end,
"O!": (object) [typeobject, PyObject *]: &PyString_Type, &self->reason,

So it looks like the only place in construction where we actually restrict to "int" is in that "s#" in PyUnicodeDecodeError_Create, which looks fixable.

After construction:  various calls to PyString_FromFormat for start and end using format "%zd", which is indeed a Py_ssize_t (see http://docs.python.org/c-api/string.html#PyString_FromFormat )

So it looks like the only issue here is the restriction to "int" in PyUnicodeDecodeError_Create due to the use of "s#" in the call to PyObject_CallFunction; apart from that, it looks like the assertions can be removed.  

I'll attach a patch which removes this restriction.

(for my reference, I'm tracking this as https://bugzilla.redhat.com/show_bug.cgi?id=540518 )

----------
components: Unicode
messages: 108404
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: PyUnicodeDecodeError_Create asserts that various arguments are less than INT_MAX
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 23 11:51:13 2010
From: report at bugs.python.org (Raven Demeyer)
Date: Wed, 23 Jun 2010 09:51:13 +0000
Subject: [New-bugs-announce] [issue9059] Backwards compatibility
In-Reply-To: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>
Message-ID: <1277286673.12.0.243169003813.issue9059@psf.upfronthosting.co.za>


New submission from Raven Demeyer <raven.demeyer at gmail.com>:

Python 3 is not backwards compatible with Python 2.

Example:
Python 2: print 'foo'
Python 3: print(bar)

Problem:
Code written for Python during version 2 cannot be used/compiled in version 3

Solution:
Just like any decent self-respecting programming language, add backwards compatibility.

----------
components: Regular Expressions
messages: 108444
nosy: Raven
priority: normal
severity: normal
status: open
title: Backwards compatibility
type: compile error
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun 23 11:51:32 2010
From: report at bugs.python.org (Torne Wuff)
Date: Wed, 23 Jun 2010 09:51:32 +0000
Subject: [New-bugs-announce] [issue9060] Python/dup2.c doesn't compile on
	(at least) newlib
In-Reply-To: <1277286692.98.0.844862215955.issue9060@psf.upfronthosting.co.za>
Message-ID: <1277286692.98.0.844862215955.issue9060@psf.upfronthosting.co.za>


New submission from Torne Wuff <torne-pythonbugs at wolfpuppy.org.uk>:

On systems without dup2(), Python tries to compile its own from Python/dup2.c, but this file refers to close() without including unistd.h. This causes it to not compile with newlib (and possibly other C libraries, presumably it was relying on fcntl.h indirectly including it?).

This is probably true of all older versions as well, but Python 2.x doesn't appear to actually bother to compile dup2.c even if the system lacks dup2, so it doesn't actually cause a build error there.

(building python for a semi-freestanding environment is "fun")

----------
components: Interpreter Core
files: fix_dup2.patch
keywords: patch
messages: 108445
nosy: torne
priority: normal
severity: normal
status: open
title: Python/dup2.c doesn't compile on (at least) newlib
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file17753/fix_dup2.patch

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

From report at bugs.python.org  Wed Jun 23 17:46:35 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 15:46:35 +0000
Subject: [New-bugs-announce] [issue9061] cgi.escape Can Lead To XSS
	Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>


New submission from Craig Younkins <cyounkins at gmail.com>:

The method in question: http://docs.python.org/library/cgi.html#cgi.escape
http://svn.python.org/view/python/tags/r265/Lib/cgi.py?view=markup   # at the bottom
http://code.python.org/hg/trunk/file/3be6ff1eebac/Lib/cgi.py#l1031

"Convert the characters '&', '<' and '>' in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the quotation mark character ('"') is also translated; this helps for inclusion in an HTML attribute value, as in <A HREF="...">. If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead."

cgi.escape never escapes single quote characters, which can easily lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be known by many, but a quick search reveals many are using cgi.escape for HTML attribute escaping.

The intended use of this method is unclear to me. Up to and including Mako 0.3.3, this method was the HTML escaping method. Used in this manner, single-quoted attributes with user-supplied data are easily susceptible to cross-site scripting vulnerabilities.

While the documentation says "if the value to be quoted might include single- or double-quote characters... [use the] xml.sax.saxutils module instead," it also implies that this method will make input safe for HTML. Because this method escapes 4 of the 5 key XML characters, it is reasonable to expect some will use it for HTML escaping.

I suggest rewording the documentation for the method making it more clear what it should and should not be used for. I would like to see the method changed to properly escape single-quotes, but if it is not changed, the documentation should explicitly say this method does not make input safe for inclusion in HTML.

This is definitely affecting the security of some Python web applications. I already mentioned Mako, but I've found this type of bug in other frameworks and engines because the creators either called cgi.escape directly or modeled their own after it.

Craig Younkins

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 108457
nosy: Craig.Younkins, docs at python
priority: normal
severity: normal
status: open
title: cgi.escape Can Lead To XSS Vulnerabilities
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 23 18:15:00 2010
From: report at bugs.python.org (Olivier Berten)
Date: Wed, 23 Jun 2010 16:15:00 +0000
Subject: [New-bugs-announce] [issue9062] urllib.urlopen crashes when
	launched from a thread
In-Reply-To: <1277309700.12.0.0164704754681.issue9062@psf.upfronthosting.co.za>
Message-ID: <1277309700.12.0.0164704754681.issue9062@psf.upfronthosting.co.za>


New submission from Olivier Berten <olivier.berten at gmail.com>:

I'm writing SwatchBooker <https://launchpad.net/swatchbooker>, an app that's (among other things) reading some data from the web. When urllib.urlopen is called first from within a secondary thread, the app crashes (or freezes). If it's been called first from the main thread, there's no problem.

You can reproduce that by downloading http://launchpad.net/swatchbooker/trunk/0.7/+download/SwatchBooker-0.7.noinstall.zip

1. Launch swatchbooker.pyw
2. Open from web
3. Select ICI Dulux, Pantone or RAL
4. Cancel
5. Close the program
6. Relaunch swatchbooker.pyw
7. Open from web
8. Choose any swatch from ICI Dulux, Pantone or RAL (Don't click ColorCharts.org or Digital Colour Atlas!)
9. OK
10. Crash

For ColorCharts.org and Digital Colour Atlas, the list itself is loaded through urllib.urlopen from the main thread so it makes the rest go smoothly...

----------
components: None
messages: 108458
nosy: olivier-berten
priority: normal
severity: normal
status: open
title: urllib.urlopen crashes when launched from a thread
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 23 19:14:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 17:14:47 +0000
Subject: [New-bugs-announce] [issue9063] TZ examples in datetime.rst are
	incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>


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

With python started at the root of the source tree and TZ=US/Eastern in the environment,

>>> exec(open('Doc/includes/tzinfo-examples.py').read())
>>> import os
>>> os.environ['TZ']
'US/Eastern'
>>> from datetime import *
>>> x = datetime(2010, 11, 7, 5, tzinfo=timezone.utc)
>>> print(x, x.astimezone(Local), x.astimezone(Eastern))
2010-11-07 05:00:00+00:00 2010-11-07 01:00:00-04:00 2010-11-07 01:00:00-05:00
>>> x.astimezone(Local).dst() == x.astimezone(Eastern).dst() 
False

Note that according to my understanding of the long comment at the end of datetimemodule.c, zone conversion from UTC is a well defined operation unless there is a bug in tzinfo subclass implementation.

----------
assignee: docs at python
components: Documentation
messages: 108462
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: TZ examples in datetime.rst are incorrect
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jun 23 21:21:26 2010
From: report at bugs.python.org (Andrew Valencia)
Date: Wed, 23 Jun 2010 19:21:26 +0000
Subject: [New-bugs-announce] [issue9064] pdb enhancement up/down traversals
In-Reply-To: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>
Message-ID: <1277320886.89.0.906554449905.issue9064@psf.upfronthosting.co.za>


New submission from Andrew Valencia <ajv-611-065-2175 at vsta.org>:

In very deep stack traces (like runaway recursion) it can be a pain to get up to the top of the stack to see what kicked it off.  I've enhanced up/down to take a numeric argument for the number of positions to traverse, or -1 to go to the top/bottom.  Sample patch included.

----------
components: Demos and Tools
files: pdb_up.pat
messages: 108476
nosy: vandyswa
priority: normal
severity: normal
status: open
title: pdb enhancement up/down traversals
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file17754/pdb_up.pat

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

From report at bugs.python.org  Thu Jun 24 00:27:37 2010
From: report at bugs.python.org (Justin Bronder)
Date: Wed, 23 Jun 2010 22:27:37 +0000
Subject: [New-bugs-announce] [issue9065] tarfile: default root:root
	ownership is incorrect.
In-Reply-To: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>
Message-ID: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>


New submission from Justin Bronder <jsbronder at gentoo.org>:

According to the tar spec [1], uname/gname should only be filled
when they have successfully been resolved from the uid/gid.  The
tarfile module incorrectly defaults to root:root in this case.

A patch against svn trunk r82183 is included.  All tarfile unit
tests still pass with this patch.  I did not include a new unit
test as chown() is required.

Example using tarfile:
$ ls -l tarfile_user
-rw-r--r-- 1 65533 jbronder 0 2010-06-23 17:44 tarfile_user
$ python -c "import tarfile;a = tarfile.open('bleh.tar', 'w:');a.add('tarfile_user');a.list()"
-rw-r--r-- root/jbronder          0 2010-06-23 17:44:55 tarfile_user

Example using GNU tarball:
$ tar -cf bleh.tar tarfile_user
$ python -c "import tarfile;a = tarfile.open('bleh.tar').list()"
-rw-r--r-- 65533/jbronder          0 2010-06-23 17:44:55 tarfile_user

1. http://www.gnu.org/software/tar/manual/tar.html#SEC170

----------
files: python-2.7-tarfile-uid-gid.patch
keywords: patch
messages: 108493
nosy: jsbronder
priority: normal
severity: normal
status: open
title: tarfile:  default root:root ownership is incorrect.
versions: Python 2.5, Python 2.7
Added file: http://bugs.python.org/file17756/python-2.7-tarfile-uid-gid.patch

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

From report at bugs.python.org  Thu Jun 24 06:58:30 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 24 Jun 2010 04:58:30 +0000
Subject: [New-bugs-announce] [issue9066] Standard type codes for array.array,
	same as struct
In-Reply-To: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za>
Message-ID: <1277355510.37.0.62223618655.issue9066@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

The type codes for array.array are platform-dependent.

The type codes are similar to those for the struct module. It would be helpful for array.array to adopt the struct module's "=" format specifier prefix, to specify "standard" sizes. E.g.

    array_object = array.array("=L")  # 4-byte elements on all platforms

----------
components: Library (Lib)
messages: 108501
nosy: cmcqueen1975
priority: normal
severity: normal
status: open
title: Standard type codes for array.array, same as struct
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 24 12:46:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Jun 2010 10:46:41 +0000
Subject: [New-bugs-announce] [issue9067] Use macros from pyctype.h
In-Reply-To: <1277376401.69.0.151009302074.issue9067@psf.upfronthosting.co.za>
Message-ID: <1277376401.69.0.151009302074.issue9067@psf.upfronthosting.co.za>


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

While investigating issue 9020, I noticed that there are several places
where the pyctype.h macros could/should be used.

----------
messages: 108505
nosy: eric.smith, skrah
priority: normal
severity: normal
status: open
title: Use macros from pyctype.h
type: feature request

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

From report at bugs.python.org  Thu Jun 24 13:46:44 2010
From: report at bugs.python.org (Haoyu Bai)
Date: Thu, 24 Jun 2010 11:46:44 +0000
Subject: [New-bugs-announce] [issue9068] "from . import *"
In-Reply-To: <1277380004.45.0.44974456995.issue9068@psf.upfronthosting.co.za>
Message-ID: <1277380004.45.0.44974456995.issue9068@psf.upfronthosting.co.za>


New submission from Haoyu Bai <divinekid at gmail.com>:

"from . import *" is valid syntax in CPython (both 2.6 and py3k) but in the language reference it is not allowed:

http://docs.python.org/dev/py3k/reference/simple_stmts.html#the-import-statement

----------
components: Interpreter Core
messages: 108507
nosy: bhy
priority: normal
severity: normal
status: open
title: "from . import *"
type: behavior

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

From report at bugs.python.org  Thu Jun 24 19:10:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jun 2010 17:10:47 +0000
Subject: [New-bugs-announce] [issue9069] test_float failure on Solaris
In-Reply-To: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>
Message-ID: <1277399447.31.0.438855107716.issue9069@psf.upfronthosting.co.za>


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

Comment from David Kirkby in issue 8265;  moved here because it looks like a separate problem.

I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. 

See 

http://trac.sagemath.org/sage_trac/ticket/9297
http://trac.sagemath.org/sage_trac/ticket/9299

Note, Solaris supports both a 32 and 64-bit ABI. Not  sure if that is relevant, but I see "ABI" in the title, so perhaps it might be.

----------
assignee: mark.dickinson
components: Extension Modules
messages: 108532
nosy: drkirkby, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: test_float failure on Solaris
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 24 20:02:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Jun 2010 18:02:07 +0000
Subject: [New-bugs-announce] [issue9070] Timestamps are rounded differently
	in py3k and trunk
In-Reply-To: <1277402527.75.0.74418180311.issue9070@psf.upfronthosting.co.za>
Message-ID: <1277402527.75.0.74418180311.issue9070@psf.upfronthosting.co.za>


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

In the trunk:

>>> datetime.utcfromtimestamp(0.9999994)
datetime.datetime(1970, 1, 1, 0, 0, 1)

In py3k:

>>> datetime.utcfromtimestamp(0.9999994)
datetime.datetime(1970, 1, 1, 0, 0, 0, 999999)


See issue1478429 - it appears that rounding up was intentional, but I am adding 2.7 because py3k behavior seems to be more natural.

----------
assignee: belopolsky
components: Extension Modules
messages: 108536
nosy: belopolsky, georg.brandl, mark.dickinson, tim_one
priority: normal
severity: normal
stage: unit test needed
status: open
title: Timestamps are rounded differently in py3k and trunk
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jun 24 20:11:02 2010
From: report at bugs.python.org (Free Ekanayaka)
Date: Thu, 24 Jun 2010 18:11:02 +0000
Subject: [New-bugs-announce] [issue9071] TarFile doesn't support member
	files with a leading "./"
In-Reply-To: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>
Message-ID: <1277403062.33.0.252734901258.issue9071@psf.upfronthosting.co.za>


New submission from Free Ekanayaka <free at 64studio.com>:

The tar format allows to have memeber files whose path has a leading "./":

$ echo > foo
$ tar cf bar.tar ./foo
$ tar tf bar.tar 
./foo

However the tarfile module doesn't allow this:

>>> from StringIO import StringIO
>>> from tarfile import TarInfo, TarFile
>>> info = TarInfo("./foo")
>>> fd = open("bar.tar", "w")
>>> tar = TarFile.open(fileobj=fd, mode="w")
>>> tar.addfile(info, "")
>>> tar.close()

then:

$ tar tf bar.tar 
foo

So in practice the tarfile module forces the removal of leading "./"'s.

In particular this is a problem when creating .deb files (dpkg) programmatically as these contains tar files with members with a leading "./".

----------
components: Library (Lib)
messages: 108537
nosy: free.ekanayaka
priority: normal
severity: normal
status: open
title: TarFile doesn't support member files with a leading "./"
type: behavior

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

From report at bugs.python.org  Thu Jun 24 21:32:49 2010
From: report at bugs.python.org (Slava)
Date: Thu, 24 Jun 2010 19:32:49 +0000
Subject: [New-bugs-announce] [issue9072] Unloading modules - memleaks?
In-Reply-To: <1277407969.42.0.292267385985.issue9072@psf.upfronthosting.co.za>
Message-ID: <1277407969.42.0.292267385985.issue9072@psf.upfronthosting.co.za>


New submission from Slava <bomboze at gmail.com>:

I don't know whether this is a bug, but my exhaustive search led me to "Python can't really unload modules" from every direction, which I find hard to believe, I don't know where else to go with this.

The problem:

  import gc, sys
  print len(gc.get_objects()) # 4073
  # starting with 4073 objects in memory

  import httplib
  del sys.modules["httplib"]
  del httplib

  # httplib should be unloaded 
  # and garbage collected as it is unreachable

  gc.collect()
  print len(gc.get_objects()) # 6745 
  # 6745 objects in memory (2000+ stray objects)

This applies to almost any module. 
Is this a bug or somehow correctable?

----------
components: None
messages: 108545
nosy: yappie
priority: normal
severity: normal
status: open
title: Unloading modules - memleaks?
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 24 22:03:07 2010
From: report at bugs.python.org (Roland Johnson)
Date: Thu, 24 Jun 2010 20:03:07 +0000
Subject: [New-bugs-announce] [issue9073] Tkinter module missing from install
	on OS X 10.6.4
In-Reply-To: <1277409787.07.0.389158105025.issue9073@psf.upfronthosting.co.za>
Message-ID: <1277409787.07.0.389158105025.issue9073@psf.upfronthosting.co.za>


New submission from Roland Johnson <rolandjohnson at acm.org>:

Tkinter no where to be found in the 3.1 install. No lib-tk folder either. There is a Tkinter folder but this conatains very few modules and none of the standard ones

----------
messages: 108547
nosy: RolandJ
priority: normal
severity: normal
status: open
title: Tkinter module missing from install on OS X 10.6.4
versions: Python 3.1

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

From report at bugs.python.org  Thu Jun 24 22:12:16 2010
From: report at bugs.python.org (Keith Rarick)
Date: Thu, 24 Jun 2010 20:12:16 +0000
Subject: [New-bugs-announce] [issue9074] [includes patch] subprocess module
	closes standard file	descriptors when it should not
In-Reply-To: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>
Message-ID: <1277410336.39.0.223644435027.issue9074@psf.upfronthosting.co.za>


New submission from Keith Rarick <kr at xph.us>:

Transcript to reproduce in Python 2.6.5:

>>> import subprocess, sys
>>> subprocess.call(('echo', 'foo'), stderr=sys.stdout)
echo: write: Bad file descriptor
1
>>> 

Expected behavior:

>>> import subprocess, sys
>>> subprocess.call(('echo', 'foo'), stderr=sys.stdout)
foo
0
>>> 

This happens because we've asked the child's stderr to be redirected, but not its stdout. So in _execute_child, errwrite is 1 while c2pwrite is None. So fd 1 (errwrite) correctly gets duped to 2. But then, since errwrite is not None and it's not in (p2cread, c2pwrite, 2), the child closes fd 1.

The equivalent thing happens if you supply stdout=sys.stderr and the child attempts to write to its stderr.

I've attached a patch to fix this. It simply adds 2 and 2 to the list of fds not to close for c2pwrite and errwrite, respectively.

This patch is against the 2.6.5 release.

There is also a workaround, in case anyone else is affected by this bug before a fix has been released:

>>> import os, subprocess, sys
>>> subprocess.call(('echo', 'foo'), stderr=os.dup(sys.stdout.fileno()))
foo
0
>>> 

(There could be a similar bug relating to the child's stdin, but I haven't investigated that.)

----------
components: IO
files: fd-close.patch
keywords: patch
messages: 108548
nosy: kr
priority: normal
severity: normal
status: open
title: [includes patch] subprocess module closes standard file descriptors when it should not
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17762/fd-close.patch

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

From report at bugs.python.org  Fri Jun 25 01:03:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Jun 2010 23:03:15 +0000
Subject: [New-bugs-announce] [issue9075] ssl module sets "debug" flag on SSL
	struct
In-Reply-To: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>
Message-ID: <1277420595.3.0.797937330193.issue9075@psf.upfronthosting.co.za>


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

The ssl module sets a "debug" flag on the OpenSSL SSL struct at the end of PySSL_SSLdo_handshake():

    self->ssl->debug = 1;

The OpenSSL header files have this to say about this flag:

        /* set this flag to 1 and a sleep(1) is put into all SSL_read()
         * and SSL_write() calls, good for nbio debuging :-) */
        int debug;      

Some uses of it in the OpenSSL source are actually guarded by a macro (#ifdef PKT_DEBUG), but some are not. Bill, do you remember why you put that call? I would find it strongly preferrable to remove that assignment (doing so doesn't seem to break anything in the test suite).

----------
components: Library (Lib)
messages: 108561
nosy: exarkun, giampaolo.rodola, janssen, pitrou
priority: high
severity: normal
status: open
title: ssl module sets "debug" flag on SSL struct
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jun 25 01:28:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:28:51 +0000
Subject: [New-bugs-announce] [issue9076] Remove
	PyUnicode_AsDecodedObject/Unicode
	and	PyUnicode_AsEncodedObject/Unicode?
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>


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

The following 4 functions are public but not documented and not used in Python3:
 - PyUnicode_AsDecodedObject(), PyUnicode_AsEncodedObject()
 - PyUnicode_AsDecodedUnicode(), PyUnicode_AsEncodedUnicode()

In Python2, PyUnicode_AsDecodedObject() was used by unicode.decode() method, but Python3 has no more str.decode() method (see the recent discussion on python-dev mailing list about .transform() / .untransform()).

In Python2, unicode.encode() uses PyUnicode_AsEncodedObject(), but in Python3 str.encode() uses PyUnicode_AsEncodedString() which ensures that the result type is bytes.

PyUnicode_AsDecodedUnicode() and PyUnicode_AsEncodedUnicode() were added by Marc-Andre Lemburg in r63986. These functions may be used for .transform() / .untranform() proposition, but this proposition is not yet accepted and the functions are now unused.

If you decide to keep one of these functions, the function have to be documented.

----------
components: Unicode
files: remove_unicode_codec.patch
keywords: patch
messages: 108565
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: Remove PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode?
versions: Python 3.2
Added file: http://bugs.python.org/file17763/remove_unicode_codec.patch

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

From report at bugs.python.org  Fri Jun 25 01:34:58 2010
From: report at bugs.python.org (Domen)
Date: Thu, 24 Jun 2010 23:34:58 +0000
Subject: [New-bugs-announce] [issue9077] argparse does not handle arguments
	correctly after --
In-Reply-To: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>
Message-ID: <1277422498.3.0.635108415577.issue9077@psf.upfronthosting.co.za>


New submission from Domen <ielectric at gmail.com>:

Sample code:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-v', action='store_true')
>>> parser.add_argument('foo')
>>> parser.parse_args(['-v', '--', '--foo'])
Namespace(foo='--foo', v=True)

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-v', action='store_true')
>>> parser.parse_args(['--', '-f'])
usage: [-h] [-v]
: error: unrecognized arguments: -- -f

----------
components: Library (Lib)
messages: 108567
nosy: iElectric
priority: normal
severity: normal
status: open
title: argparse does not handle arguments correctly after --
type: security
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 25 01:35:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:35:13 +0000
Subject: [New-bugs-announce] [issue9078] Fix C API documentation of unicode
Message-ID: <1277422513.82.0.685887790927.issue9078@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
assignee: docs at python
components: Documentation, Unicode
files: unicode_doc.patch
keywords: patch
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Fix C API documentation of unicode
versions: Python 3.2
Added file: http://bugs.python.org/file17765/unicode_doc.patch

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

From report at bugs.python.org  Fri Jun 25 02:52:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Jun 2010 00:52:34 +0000
Subject: [New-bugs-announce] [issue9079] Make gettimeofday available in
	datetime module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>


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

Attached patch moves cross-platform logic of obtaining current time to _time.c which is shared between time and datetime modules.  This simplifies both modules and reduces the datetime module dependency on the time module.

----------
assignee: belopolsky
components: Extension Modules
files: gettimeofday.diff
keywords: needs review, patch
messages: 108575
nosy: belopolsky, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Make gettimeofday available in datetime module
versions: Python 3.2
Added file: http://bugs.python.org/file17766/gettimeofday.diff

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

From report at bugs.python.org  Fri Jun 25 14:00:49 2010
From: report at bugs.python.org (Andy Buckley)
Date: Fri, 25 Jun 2010 12:00:49 +0000
Subject: [New-bugs-announce] [issue9080] Provide list prepend method (even
	though it's not	efficient)
In-Reply-To: <1277467249.03.0.329544397504.issue9080@psf.upfronthosting.co.za>
Message-ID: <1277467249.03.0.329544397504.issue9080@psf.upfronthosting.co.za>


New submission from Andy Buckley <andy at insectnation.org>:

I know that Python lists aren't designed for efficient prepending, but sometimes when working with small lists it's exactly what needs to be done (search path lists being a common example). For a programmer aware of the performance issue and having convinced themself that it's not a problem for their use-case, it's a niggle that there is no prepend()  function for lists by direct analogy to the commonly-used append(). 

Writing l = ["foo"] + l, or something mucky based on l.insert(0, ...) or reverse/append/reverse is annoyingly asymmetric and no more performant. So I suggest that l.append(x) be added to the list interface, with a prominent warning in the documentation that it's not an efficient operation on that type (possibly mention the complexity scaling with list length). I think the role of the interface is to make simple things simple, not to make it difficult to do simple-but-inefficient things that people will do anyway ;)

----------
components: Library (Lib)
messages: 108587
nosy: andybuckley
priority: normal
severity: normal
status: open
title: Provide list prepend method (even though it's not efficient)
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Fri Jun 25 18:23:03 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Jun 2010 16:23:03 +0000
Subject: [New-bugs-announce] [issue9081] test_sysconfig failure
In-Reply-To: <1277482983.46.0.622536161926.issue9081@psf.upfronthosting.co.za>
Message-ID: <1277482983.46.0.622536161926.issue9081@psf.upfronthosting.co.za>


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

When I do a *full test run* of py3k I get a distutils test failure. It doesn't happen if I run test_distutils on its own:

bigmac:py3k michael$ ./python.exe -m test.regrtest -j12
== CPython 3.2a0 (py3k:82215, Jun 25 2010, 13:59:00) [GCC 4.2.1 (Apple Inc. build 5659)]
==   Darwin-10.4.0-i386-64bit
==   /compile/py3k/build/test_python_53586

... lots of results skipped

test test_distutils failed -- Traceback (most recent call last):
  File "/compile/py3k/Lib/distutils/tests/support.py", line 16, in _capture_warnings
    return func(*args, **kw)
  File "/compile/py3k/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
    self.assertTrue(os.path.isdir(inc_dir), inc_dir)
AssertionError: /compile/py3k/build/test_python_53586/Include

----------
assignee: tarek
components: Distutils
messages: 108609
nosy: michael.foord, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_sysconfig failure
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 25 23:00:12 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Jun 2010 21:00:12 +0000
Subject: [New-bugs-announce] [issue9082] warnings.filterwarnings doesn't
	work with -O
In-Reply-To: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>
Message-ID: <1277499612.9.0.672509574553.issue9082@psf.upfronthosting.co.za>


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

warnings.filterwarnings is mostly a bunch of asserts, so it doesn't work when Python is run with -O or -OO. This also means that a bunch of tests fail when run with -O or -OO.

Two options are skip the tests or fix filterwarnings.

----------
components: Library (Lib)
messages: 108628
nosy: michael.foord
priority: normal
severity: normal
status: open
title: warnings.filterwarnings doesn't work with -O
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jun 26 00:38:44 2010
From: report at bugs.python.org (Steve Holden)
Date: Fri, 25 Jun 2010 22:38:44 +0000
Subject: [New-bugs-announce] [issue9083] At least some Tools utilities are
	still Python 2
In-Reply-To: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>
Message-ID: <1277505524.04.0.87838503944.issue9083@psf.upfronthosting.co.za>


New submission from Steve Holden <steve at holdenweb.com>:

C:\Users\sholden>\python31\python \python31\Tools\webchecker\wcgui.py
Traceback (most recent call last):
  File "\python31\Tools\webchecker\wcgui.py", line 63, in <module>
    from Tkinter import *
ImportError: No module named Tkinter

This makes is seem pretty clear that not even minimal effort has been expended to ensure that this Tools is functional. It's not a priority, so that's understandable. Maybe I am the only person who ever tried to use this under Python 3.

Perhaps we need a test that will fail if these things don't at least run to completion (and no, I don't know how I would test wcgui, but I'd be interested in discussing test strategies)?

----------
assignee: holdenweb
components: 2to3 (2.x to 3.0 conversion tool), Demos and Tools
messages: 108641
nosy: holdenweb
priority: high
severity: normal
stage: unit test needed
status: open
title: At least some Tools utilities are still Python 2
type: feature request
versions: Python 3.1

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

From report at bugs.python.org  Sat Jun 26 04:43:13 2010
From: report at bugs.python.org (daniel hahler)
Date: Sat, 26 Jun 2010 02:43:13 +0000
Subject: [New-bugs-announce] [issue9084] vimrc: use matchall() instead of
	":match" to allow	multiple matches
In-Reply-To: <1277520193.82.0.447342355027.issue9084@psf.upfronthosting.co.za>
Message-ID: <1277520193.82.0.447342355027.issue9084@psf.upfronthosting.co.za>


New submission from daniel hahler <python-bugs at thequod.de>:

This patch fixes the vimrc example file to use matchadd() instead of ":match", so that the second "match" does not overwrite the first one.

This resulted in leading tabs not highlighted as BadWhitespace.

----------
components: Demos and Tools
messages: 108683
nosy: blueyed
priority: normal
severity: normal
status: open
title: vimrc: use matchall() instead of ":match" to allow multiple matches

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

From report at bugs.python.org  Sat Jun 26 09:27:55 2010
From: report at bugs.python.org (Tokio Kikuchi)
Date: Sat, 26 Jun 2010 07:27:55 +0000
Subject: [New-bugs-announce] [issue9085] Version number inconsistency in
	email package
In-Reply-To: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>
Message-ID: <1277537275.59.0.8947906135.issue9085@psf.upfronthosting.co.za>


New submission from Tokio Kikuchi <tkikuchi at users.sourceforge.net>:

Python 2.6 email version number is 4.0.1 while that of py2.5 is 4.0.2.
Clearly, py2.6 email is newer and should have higher number.

----------
components: Library (Lib)
messages: 108688
nosy: tkikuchi
priority: normal
severity: normal
status: open
title: Version number inconsistency in email package
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 26 12:05:39 2010
From: report at bugs.python.org (John Miller)
Date: Sat, 26 Jun 2010 10:05:39 +0000
Subject: [New-bugs-announce] [issue9086] Wrong linking terminology in
	windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>


New submission from John Miller <gyuval at gmail.com>:

The 'How can I embed Python' section in the 'Python on Windows FAQ' (http://docs.python.org/faq/windows.html) uses wrong terms:
What the FAQ calls static linking and dynamic linking are actally two forms of dynamic linking - load-time dynamic linking and run-time dynamic linking, respectively.
Static linking means something else entirely - linking with a library that itself contains the implementation, i.e. there will be no usage of the DLL at all. Since the FAQ states that pythonNN.lib is just an import lib, static linking isn't really an option with this library.

Also the FAQ states that 'The drawback to dynamic linking is that your app won?t run if pythonNN.dll does not exist on your system'. This is misleading for two reasons:
- If the application uses the DLL, it won't run as expected if the DLL doesn't exist, regardless of how it loads the DLL. 
- Of the two linking options, load-time dynamic linking (what the FAQ refers to as static linking) is actually the one that handles the missing DLL more badly: The app will crash upon loading. If run-time dynamic linking is used, loading of the DLL happens in the application code, and it can handle it however it chooses to - it can inform the user, disable the feature that needs the DLL, etc.

----------
assignee: docs at python
components: Documentation
messages: 108700
nosy: docs at python, john.miller
priority: normal
severity: normal
status: open
title: Wrong linking terminology in windows FAQ
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 26 20:04:33 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jun 2010 18:04:33 +0000
Subject: [New-bugs-announce] [issue9087] json docstrings on 3.x still use
	'unicode' and 'str'
In-Reply-To: <1277575473.27.0.695567265942.issue9087@psf.upfronthosting.co.za>
Message-ID: <1277575473.27.0.695567265942.issue9087@psf.upfronthosting.co.za>


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

In the json package there are still lot of docstrings that refer to 'unicode' and 'str' instead of 'str' and 'bytes' (AFAIU 'bytes' are not even allowed anymore in several places, so there should probably be only 'str' there).
A few examples:
* in json/__init__.py:
  If ``skipkeys`` is true then ``dict`` keys that are not basic types (``str``, ``unicode``, ``int``, ``float``, ``bool``, ``None``) will be skipped instead of raising a ``TypeError``.
  If ``ensure_ascii`` is false, then the some chunks written to ``fp`` may be ``unicode`` instances, subject to normal Python ``str`` to ``unicode`` coercion rules.

* in json/decoder.py:
  Decode a JSON document from ``s`` (a ``str`` or ``unicode`` beginning with a JSON document) and return a 2-tuple of the Python representation and the index in ``s`` where the document ended.

* in json/encoder.py:
  If ensure_ascii is true, the output is guaranteed to be str objects with all incoming unicode characters escaped.  If ensure_ascii is false, the output will be unicode object.


Note that the documentation (Doc/library/json.rst) seems already updated, so update the docstrings should be enough.

----------
assignee: bob.ippolito
components: Documentation, Library (Lib)
messages: 108738
nosy: bob.ippolito, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: json docstrings on 3.x still use 'unicode' and 'str'
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jun 27 01:08:02 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 26 Jun 2010 23:08:02 +0000
Subject: [New-bugs-announce] [issue9088] revert distutils so it's like in 3.1
In-Reply-To: <1277593682.01.0.850281070845.issue9088@psf.upfronthosting.co.za>
Message-ID: <1277593682.01.0.850281070845.issue9088@psf.upfronthosting.co.za>


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

distutils is going back to its 3.1 state, as planned at the summit (done in 2.7/trunk already). Should be done over the week end

----------
assignee: tarek
messages: 108757
nosy: tarek
priority: release blocker
severity: normal
status: open
title: revert distutils so it's like in 3.1
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 27 02:53:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 00:53:48 +0000
Subject: [New-bugs-announce] [issue9089] PyNumber_Int is still mentioned in
	number protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>


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

See http://docs.python.org/dev/py3k/c-api/number.html#PyNumber_Int

I also noticed some left-over references to intobject in the comments in the py3k tree:

Include/longobject.h:61:/* For use by intobject.c only */
Modules/xxmodule.c:13:   intobject.h for an example. */
Objects/floatobject.c:24:/* Special free list -- see comments for same code in intobject.c. */
Objects/frameobject.c:394:   integers are allocated in a special way -- see intobject.c).  When
PCbuild/pythoncore.vcproj:758:				RelativePath="..\Include\intobject.h"

----------
assignee: docs at python
components: Documentation
messages: 108766
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: PyNumber_Int is still mentioned in number protocol docs
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 27 03:38:47 2010
From: report at bugs.python.org (Eric Hohenstein)
Date: Sun, 27 Jun 2010 01:38:47 +0000
Subject: [New-bugs-announce] [issue9090] Error code 10035 calling
	socket.recv() on a socket with a	timeout (WSAEWOULDBLOCK - A
	non-blocking socket operation could	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>


New submission from Eric Hohenstein <ehohenstein at imvu.com>:

This error is unfortunately difficult to reproduce. I've only seen it happen on Windows XP running on a dual core VMWare VM. I haven't been able to reproduce it on a non-VM system running Windows 7. The only way I've been able to reproduce it is to run the following unit test repeatedly on the XP VM repeatedly until it fails:

import unittest
import urllib2

class DownloadUrlTest(unittest.TestCase):
    def testDownloadUrl(self):
        opener = urllib2.build_opener()
        handle = opener.open('http://localhost/', timeout=60)
        handle.info()
        data = handle.read()
        self.assertNotEqual(data, '')

if __name__ == "__main__":
    unittest.main()

This unit test obviously depends on a web server running on localhost. In the test environment where I was able to reproduce this problem the web server is Win32 Apache 2.0.54 with mod_php. When the test fails, it fails with Windows error code 10035 (WSAEWOULDBLOCK) being generated by the call to the recv() method rougly once every 50-100 times the test is run. The following is a the final entry in the stack when the error occurs:

  File "c:\slave\h05b15\build\Ext\Python26\lib\socket.py", line 353, in read (self=<socket._fileobject ...03B78170>, size=1027091)
    data = self._sock.recv(left)

The thing to note is that the socket is being created with a timeout of 60. The implementation of the socket.recv() method in socketmodule.c in the _socket import module is to use select() to wait for a socket to become readable for socket objects with a timeout and then to call recv() on the socket only if select() did not return indicating that the timeout period elapsed without the socket becoming readable. The fact that Windows error code 10035 (WSAEWOULDBLOCK) is being generated in the sock_recv_guts() method in socketmodule.c indicates that select() returned without timing out which means that Windows must have indicated that the socket is readable when in fact it wasn't. It appears that there is a known issue with Windows sockets where this type of problem may occur with non-blocking sockets. It is described in the msdn documentation for WSAAsyncSelect() (http://msdn.microsoft.com/en-us/library/ms741540%28VS.85%29.aspx). The code for socketmodule.c doesn't seem to handle this type of situation correctly. The patch I've included with this issue report retries the select() if the recv() call fails with WSAWOULDBLOCK (only if MS_WINDOWS is defined). With the patch in place the test ran approximately 23000 times without failure on the system where it was failing without the patch.

----------
components: IO, Windows
files: sock_recv.patch
keywords: patch
messages: 108770
nosy: ehohenstein
priority: normal
severity: normal
status: open
title: Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17780/sock_recv.patch

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

From report at bugs.python.org  Sun Jun 27 05:34:04 2010
From: report at bugs.python.org (Esteban Feldman)
Date: Sun, 27 Jun 2010 03:34:04 +0000
Subject: [New-bugs-announce] [issue9091] str.capitalize() should not lower
	the rest of the string
In-Reply-To: <1277609644.85.0.417350742268.issue9091@psf.upfronthosting.co.za>
Message-ID: <1277609644.85.0.417350742268.issue9091@psf.upfronthosting.co.za>


New submission from Esteban Feldman <esteban.feldman at gmail.com>:

As per documentation:
I doesn't say anything on lower the rest of the string.
Is this the expected behavior?

**
str.capitalize()?
Return a copy of the string with only its first character capitalized.

For 8-bit strings, this method is locale-dependent.
**

Example:

Python 2.6.5 (r265:79063, May 24 2010, 14:03:08) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 'this is a TEST'
>>> a.capitalize()
'This is a test'

----------
components: Library (Lib)
messages: 108772
nosy: eka
priority: normal
severity: normal
status: open
title: str.capitalize() should not lower the rest of the string
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Jun 27 16:27:52 2010
From: report at bugs.python.org (Konstantin)
Date: Sun, 27 Jun 2010 14:27:52 +0000
Subject: [New-bugs-announce] [issue9092] static behavior of local variables
In-Reply-To: <1277648872.55.0.144754321131.issue9092@psf.upfronthosting.co.za>
Message-ID: <1277648872.55.0.144754321131.issue9092@psf.upfronthosting.co.za>


New submission from Konstantin <kaslanidi at yahoo.com>:

In [12]: def func(x=[]) :
   ....:     L=x
   ....:     L.append('a')
   ....:     return L
   ....:

In [13]: func()
Out[13]: ['a']

In [14]: func()
Out[14]: ['a', 'a']

In [15]: func()
Out[15]: ['a', 'a', 'a']

In [16]: func()
Out[16]: ['a', 'a', 'a', 'a']

In [17]: x
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

C:\Users\konstantin\<ipython console> in <module>()

NameError: name 'x' is not defined

In [18]:

In [19]: L
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)

C:\Users\konstantin\<ipython console> in <module>()

NameError: name 'L' is not defined

----------
components: None
messages: 108789
nosy: Aslanidi
priority: normal
severity: normal
status: open
title: static behavior of local variables
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Jun 27 19:08:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 17:08:15 +0000
Subject: [New-bugs-announce] [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>


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

Here is the list of subdirectories in Tools.  Here is the diff between directory listing and readme ('-' means no readme entry, '+' - no tool):

-buildbot
-ccbench
+audiopy
+compiler
 faqwiz
-framer
 freeze
 gdb
 i18n
-iobench
-msi
-pybench
 pynche
 scripts
-ssl
 unicode
 versioncheck
+webchecker
 world

----------
assignee: docs at python
components: Documentation
messages: 108797
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/README is out of date
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun 28 01:12:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 23:12:15 +0000
Subject: [New-bugs-announce] [issue9094] Make python-m pickletools do
	something useful
In-Reply-To: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>
Message-ID: <1277680335.26.0.237686854485.issue9094@psf.upfronthosting.co.za>


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

Attached patch makes python -m pickletools <picklefile> print symbolic disassembly of a pickle to stdout.  If the idea is well received, I will add help option, usage string and possibly -o option to redirect output to a file.

I am not sure that current "run doctest" behavior is worth preserving given that one can always do python -m doctest Lib/pickletools.py instead.

----------
assignee: belopolsky
components: Library (Lib)
files: pickletools.diff
keywords: easy, patch
messages: 108807
nosy: alexandre.vassalotti, belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Make python-m pickletools do something useful
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17783/pickletools.diff

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

From report at bugs.python.org  Mon Jun 28 01:59:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Jun 2010 23:59:48 +0000
Subject: [New-bugs-announce] [issue9095] patchcheck should handle extraneous
	whitespace in .rst	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Tools/scripts/reindent-rst.py already exists, so this should be simple to add.

----------
components: Demos and Tools
keywords: easy
messages: 108808
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: patchcheck should handle extraneous whitespace in .rst files
type: feature request

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

From report at bugs.python.org  Mon Jun 28 02:28:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Jun 2010 00:28:20 +0000
Subject: [New-bugs-announce] [issue9096] importlib doesn't handle valid
	marshalled data with	invalid semantics
In-Reply-To: <1277684900.43.0.0388442576736.issue9096@psf.upfronthosting.co.za>
Message-ID: <1277684900.43.0.0388442576736.issue9096@psf.upfronthosting.co.za>


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

get_code() returns marshal.loads(self.get_data()). If get_data() returns valid marhsal data that is not a code object, get_code() will explode when it tries to exec it with a TypeError not the expected ValueError.

----------
assignee: brett.cannon
messages: 108810
nosy: benjamin.peterson, brett.cannon
priority: normal
severity: normal
status: open
title: importlib doesn't handle valid marshalled data with invalid semantics

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

From report at bugs.python.org  Mon Jun 28 13:43:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 11:43:29 +0000
Subject: [New-bugs-announce] [issue9097] os.chdir(path) to return current dir
In-Reply-To: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>
Message-ID: <1277725409.82.0.324179081421.issue9097@psf.upfronthosting.co.za>


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

os.chdir(path) is often used with os.getcwd() call and doesn't return anything. It can return the name of the directory before the change.

prev = os.chdir(path)
...
os.chdir(prev)

Maybe it will also be possible to implement 'with' construct:

with os.chdir(path):
  ...

----------
messages: 108822
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.chdir(path) to return current dir
type: feature request

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

From report at bugs.python.org  Mon Jun 28 14:43:51 2010
From: report at bugs.python.org (Martin Ellison)
Date: Mon, 28 Jun 2010 12:43:51 +0000
Subject: [New-bugs-announce] [issue9098] MSYS build fails with `S_IXGRP'
	undeclared
In-Reply-To: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>
Message-ID: <1277729031.36.0.263470334817.issue9098@psf.upfronthosting.co.za>


New submission from Martin Ellison <martin.ellison at gmail.com>:

Python 2.6.5 build fails on MSYS with the following messages

martin at EDWARD /c/Downloads/Python-2.6.5
$ make
gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -
I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/import.o Python/import.c
Python/import.c: In function `write_compiled_module':
Python/import.c:882: error: `S_IXGRP' undeclared (first use in this function)
Python/import.c:882: error: (Each undeclared identifier is reported only once
Python/import.c:882: error: for each function it appears in.)
Python/import.c:882: error: `S_IXOTH' undeclared (first use in this function)
Python/import.c: In function `PyImport_ImportModuleNoBlock':
Python/import.c:2063: warning: unused variable `me'
make: *** [Python/import.o] Error 1

----------
components: Build
messages: 108823
nosy: Martin.Ellison
priority: normal
severity: normal
status: open
title: MSYS build fails with `S_IXGRP' undeclared
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 28 14:55:00 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Mon, 28 Jun 2010 12:55:00 +0000
Subject: [New-bugs-announce] [issue9099] multiprocessing/win32:
In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>
Message-ID: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

I am using Python 2.6.5/win32, and working with multiprocessing module, doing that with Python interpreter embedded using Cython (if that may be related to the problem).

While creating a subprocess and a Pipe to communicate with it, I've got the following traceback (particulaly on the line "parent_conn, child_conn = Pipe()"):

Traceback (most recent call last):
  File "test_fork.py", line 24, in init test_fork (test_fork.c:810)
    vasia.main()
  File "Z:\multiprocessing_cython_w32\vasia.py", line 15, in main
    parent_conn, child_conn = Pipe()
  File "Z:\python-win32\2.6.5\Lib\multiprocessing\__init__.py", line 106, in Pipe
    return Pipe(duplex)
  File "Z:\python-win32\2.6.5\Lib\multiprocessing\connection.py", line 202, in Pipe
    h2, win32.PIPE_READMODE_MESSAGE, None, None
WindowsError: [Error 0] Success

Lines 202-204 in multiprocessing/connection.py contain the following: 

        win32.SetNamedPipeHandleState(                                                                                             
            h2, win32.PIPE_READMODE_MESSAGE, None, None                                                                            
            ) 

It seems to me that for some reason SetNamedPipeHandleState might be returning 0 even while it didn't fail actually; a quick check confirmed that it could be fixed by changing the above lines to the following:

        try:                                                                                                                       
            win32.SetNamedPipeHandleState(                                                                                         
                h2, win32.PIPE_READMODE_MESSAGE, None, None                                                                        
                )                                                                                                                  
        except WindowsError, e:                                                                                                    
(win32)                                                                                                       
            if e.args[0] != 0: # 0 is error code for SUCCESS                                                                       
                raise

----------
components: Extension Modules, Windows
messages: 108824
nosy: honeyman
priority: normal
severity: normal
status: open
title: multiprocessing/win32:
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jun 28 15:27:43 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 28 Jun 2010 13:27:43 +0000
Subject: [New-bugs-announce] [issue9100] test_sysconfig fails
	(test_user_similar)
In-Reply-To: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>
Message-ID: <1277731663.45.0.56366593786.issue9100@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

Python 2.7rc2

test_user_similar test in test_sysconfig fails for me. I think it's because I have different --exec-prefix and --prefix specified. The test assumes that get_config_var('base') is the part of the global_path = get_path('platstdlib', 'posix_prefix') which is not necessarily true.

I've attached the pdb output containing the variable names.

----------
components: Tests
files: pdb_test_user_similar.txt
messages: 108828
nosy: csernazs
priority: normal
severity: normal
status: open
title: test_sysconfig fails (test_user_similar)
versions: Python 2.7
Added file: http://bugs.python.org/file17789/pdb_test_user_similar.txt

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

From report at bugs.python.org  Mon Jun 28 17:37:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 15:37:23 +0000
Subject: [New-bugs-announce] [issue9101] reference json format in file
	formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>


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

Quite often people use .json files for storing configuration. Having a reference to json module from chapter "14. File Formats" would be a good pointer for those looking to .ini alternatives.

----------
assignee: docs at python
components: Documentation
messages: 108833
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: reference json format in file formats chapter
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 17:42:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 15:42:02 +0000
Subject: [New-bugs-announce] [issue9102] pybench: Cannot compare 2.x and 3.x
	benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>


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

There are several issues that prevent

$ python3 Tools/pybench/pybench.py -s 27.bench -c 32.bench

from working.

1. There is a bug in _pickle that prevents 2.x pickles that contain classic class instances from loading in 3.x.  This is addressed in issue5180.

2. Once _pickle issue is addresses, 2.7 benchmark files still cannot be loaded because they contain references to the Unicode tests and Unicode.py is not loadable in python3.

3. Once Unicode.py gets 2to3 treatment, we are still left with 

* Benchmark versions differ: cannot compare this benchmark to "32.bench" !


The last issue is probably the simplest.  Version number was bumped up in r69411, and a log entry says that the intent was to keep pybench 2.1 compatible with 2.x.  Indeed, pybench 2.1 from py3k runs under trunk python and resulting benchmark file can be compared with 3.x generated benchmark once issues 1 and 2 above are resolved.  It may, however be worth consideration to synchronize pybench versions shipped with 27 and 32.  I understand that this is likely to be too late for 2.7, but I am checking 2.7 version in case this is considered appropriate for 2.7.1.

The Unicode.py issue was discussed under issue5180 in msg108819 and msg108821.  I like MAL's suggestion of Strings3 module, but I think it would be useful to be able to compare 2.x str performance to both 3.x str and 3.x bytes.  Similarly, I think String3 should have from __future__ import unicode_literals and be loadable in 2.7/2.6 and server as means to compare 2.x and 3.x unicode performance.

For the _pickle issue, I am about to attach a patch to issue5180.

----------
components: Demos and Tools
messages: 108834
nosy: belopolsky, lemburg, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pybench: Cannot compare 2.x and 3.x benchmarks
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 18:09:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 16:09:41 +0000
Subject: [New-bugs-announce] [issue9103] API keyword
In-Reply-To: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>
Message-ID: <AANLkTil4-Bf0gK-zXTGP7vWbWpFQ9uvON6wK_2ZGBies@mail.gmail.com>


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

Need API keyword to filter refused API proposals.
-- 
anatoly t.

----------
messages: 108836
nosy: techtonik
priority: normal
severity: normal
status: open
title: API keyword

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

From report at bugs.python.org  Mon Jun 28 18:18:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 16:18:12 +0000
Subject: [New-bugs-announce] [issue9104] test_exceptions does not test
	pickling with pickle.py
In-Reply-To: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>
Message-ID: <1277741892.3.0.0849773844587.issue9104@psf.upfronthosting.co.za>


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

This is probably one example of many where pickling is only tested with _pickle module if it is available rather than separately with C and Python implementation.  I am attaching a patch which implements one possible testing strategy.  If this is acceptable, I think the machinery of retrieving multiple module implementations should be moved to test.support and reused in other test modules.

----------
components: Library (Lib)
files: test_exceptions.diff
keywords: patch
messages: 108840
nosy: alexandre.vassalotti, belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: test_exceptions does not test pickling with pickle.py
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17791/test_exceptions.diff

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

From report at bugs.python.org  Mon Jun 28 19:25:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 17:25:56 +0000
Subject: [New-bugs-announce] [issue9105] pickle security note should be more
	prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>


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

Pickle warning about insecurity is located only at the second page near the bottom of "Relationship to other Python modules" chapter. For me the proper place for it is the first page of documentation.

----------
assignee: docs at python
components: Documentation
messages: 108847
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: pickle security note should be more prominent
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 20:28:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 18:28:24 +0000
Subject: [New-bugs-announce] [issue9106] remove numbers from 3-.. level
	entries in docs toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>


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

It seems that left side ToC menu will be more clear without numeric prefixes from chapter on 3-.. nesting levels. How about to remove them?

For example - the ToC menu now starting from root level:

15.6. logging ? Logging facility for Python
    * 15.6.1. Logging tutorial
          o 15.6.1.1. Simple examples
          o 15.6.1.2. Loggers
          o 15.6.1.3. Handlers
          o 15.6.1.4. Formatters
          o 15.6.1.5. Configuring Logging
          o 15.6.1.6. Configuring Logging for a Library
    * 15.6.2. Logging Levels
    * 15.6.3. Useful Handlers
...

will look like:

15.6. logging ? Logging facility for Python
    * 1. Logging tutorial
          o 1.1. Simple examples
          o 1.2. Loggers
          o 1.3. Handlers
          o 1.4. Formatters
          o 1.5. Configuring Logging
          o 1.6. Configuring Logging for a Library
    * 2. Logging Levels
    * 3. Useful Handlers
...

----------
assignee: docs at python
components: Documentation
messages: 108850
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: remove numbers from 3-.. level entries in docs toc
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 21:30:57 2010
From: report at bugs.python.org (Krauzi)
Date: Mon, 28 Jun 2010 19:30:57 +0000
Subject: [New-bugs-announce] [issue9107] PyModule_Create not working properly
In-Reply-To: <1277753457.53.0.646916927225.issue9107@psf.upfronthosting.co.za>
Message-ID: <1277753457.53.0.646916927225.issue9107@psf.upfronthosting.co.za>


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

Hi guys i have a big problem with my code:
PyModule_Create doesnt add any methods to the module (all methods are correctly added to the PyMethodDef structure respective the PyModuleDef).
With python 2.6.5 everything works well (Py_InitModule used instead of PyModule_Create [+ PyImport_AddModule]).
I looked into the source but everything seems correct there.

The code worked neither Visual Studio 2010 nor on 2008.

----------
components: None
messages: 108855
nosy: Krauzi
priority: normal
severity: normal
status: open
title: PyModule_Create not working properly
versions: Python 3.1

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

From report at bugs.python.org  Mon Jun 28 23:34:59 2010
From: report at bugs.python.org (muzuiget)
Date: Mon, 28 Jun 2010 21:34:59 +0000
Subject: [New-bugs-announce] [issue9108] list object variable assign with
	multiplication sign
In-Reply-To: <1277760899.63.0.253038665786.issue9108@psf.upfronthosting.co.za>
Message-ID: <1277760899.63.0.253038665786.issue9108@psf.upfronthosting.co.za>


New submission from muzuiget <muzuiget at gmail.com>:

platform: ubuntu 10.04 amd64, python 2.6.5 r265:79063

run below code 

a = [{}, {}, {}]
b = [{}] + [{}] + [{}]
c = [{}] * 3
print a, len(a), type(a)
print b, len(b), type(b)
print c, len(c), type(c)
a[1]["test"] = 1234
b[1]["test"] = 1234
c[1]["test"] = 1234
print a
print b
print c

the output is 

[{}, {}, {}] 3 <type 'list'>
[{}, {}, {}] 3 <type 'list'>
[{}, {}, {}] 3 <type 'list'>
[{}, {'test': 1234}, {}]
[{}, {'test': 1234}, {}]
[{'test': 1234}, {'test': 1234}, {'test': 1234}]

each dict key in variable c seen to assign with the same value.

----------
components: None
messages: 108872
nosy: muzuiget
priority: normal
severity: normal
status: open
title: list object variable assign with multiplication sign
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 29 00:24:23 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 28 Jun 2010 22:24:23 +0000
Subject: [New-bugs-announce] [issue9109] absolute import cleanups for Python
	3
In-Reply-To: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>
Message-ID: <1277763863.2.0.681054558963.issue9109@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-pythonbugs at arctrix.com>:

It looks like there is a bunch of legacy relative import cruft kicking around in Python 3.  The first thing I noticed is that __import__.__doc__ claims that level=-1 is the default (i.e. use the Python 2 behavior).  A little testing shows that the docs don't lie and __import__ in Python 3 defaults trying a relative import first.

What is the status of implicit relative imports in Python 3?  Can the level=-1 code be removed?

----------
components: Interpreter Core
messages: 108874
nosy: nas
priority: normal
severity: normal
status: open
title: absolute import cleanups for Python 3
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 29 00:58:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 28 Jun 2010 22:58:18 +0000
Subject: [New-bugs-announce] [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>


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

Patch to add a ContextDecorator class to contextlib. This allows context managers that inherit from ContextDecorator (including using it as a mixin) to be used as decorators as well as context managers.

Context managers inheriting from ContextDecorator still have to implement __enter__ and __exit__ as normal. As the decorator behaviour is implemented using a with statement __exit__ retains its optional exception handling even when used as a decorator.

In addition contextlib.GeneratorContextManager, used to implement contextlib.contextmanager, inherits from ContextDecorator. Context managers created with contextlib.contextmanager can therefore be used as decorators too.

----------
assignee: michael.foord
components: Library (Lib)
files: contextdecorator.patch
keywords: patch
messages: 108877
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: contextlib.ContextDecorator
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file17795/contextdecorator.patch

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

From report at bugs.python.org  Tue Jun 29 02:31:10 2010
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 29 Jun 2010 00:31:10 +0000
Subject: [New-bugs-announce] [issue9111] cmd.do_help documentation should
	mention docstrings
In-Reply-To: <1277771470.94.0.943327236295.issue9111@psf.upfronthosting.co.za>
Message-ID: <1277771470.94.0.943327236295.issue9111@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

cmd.Cmd looks for help either by searching for help_XXX method or by the
docstring of do_XXX. The latter is not mentioned in the docs.

----------
components: Library (Lib)
messages: 108883
nosy: tebeka
priority: normal
severity: normal
status: open
title: cmd.do_help documentation should mention docstrings
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun 29 10:06:50 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 29 Jun 2010 08:06:50 +0000
Subject: [New-bugs-announce] [issue9112] argparse missing documentation for
	error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>


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

The argparse module's ArgumentParser class has an error() method that appears to have the same behavior as the optparse error() method, but this method is not mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 108896
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: argparse missing documentation for error() method
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 13:04:51 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 29 Jun 2010 11:04:51 +0000
Subject: [New-bugs-announce] [issue9113] Tools/msi still uses string
	exceptions
In-Reply-To: <1277809491.49.0.571731039318.issue9113@psf.upfronthosting.co.za>
Message-ID: <1277809491.49.0.571731039318.issue9113@psf.upfronthosting.co.za>


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

string exceptions still used in a couple of places:

Tools/msi/msi.py:354
Tools/msi/msi.py:368
Tools/msi/msilib.py:238

----------
components: Demos and Tools
messages: 108900
nosy: doko
priority: normal
severity: normal
status: open
title: Tools/msi still uses string exceptions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 14:25:00 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 29 Jun 2010 12:25:00 +0000
Subject: [New-bugs-announce] [issue9114] br"" string literals don't appear
	to be documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>


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

It appears that br"" (raw bytes) isn't documented, at least not along with string and bytes literals:
http://docs.python.org/py3k/reference/lexical_analysis.html#literals

Yet they are supported:
http://mail.python.org/pipermail/python-ideas/2010-June/007529.html

----------
assignee: docs at python
components: Documentation
messages: 108902
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: br"" string literals don't appear to be documented
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 16:27:58 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Tue, 29 Jun 2010 14:27:58 +0000
Subject: [New-bugs-announce] [issue9115] test_site: support for systems
	without unsetenv
In-Reply-To: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>
Message-ID: <1277821678.96.0.414728435775.issue9115@psf.upfronthosting.co.za>


New submission from Zsolt Cserna <zsolt.cserna at morganstanley.com>:

On systems where there's no unsetenv function (for example solaris 8), test_site fails because the PYTHONUSERBASE environment variable remains set to "xoxo" (set in the previous tests).

This results a failed test_s_option test.

----------
components: Tests
files: test_site.py.diff
keywords: patch
messages: 108910
nosy: csernazs
priority: normal
severity: normal
status: open
title: test_site: support for systems without unsetenv
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file17799/test_site.py.diff

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

From report at bugs.python.org  Tue Jun 29 17:58:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 29 Jun 2010 15:58:27 +0000
Subject: [New-bugs-announce] [issue9116]
	test_capi.test_no_FatalError_infinite_loop crash on	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>


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

Debug and Release builds of py3k both throw up a Visual Studio debugger prompt when running this test on Windows. I don't have much time at the moment to investigate, but I find it odd that this isn't occurring on the two Windows py3k buildbots.



Output of the release build after selecting not to debug:

C:\python-dev\py3k>PCbuild\amd64\python.exe -m test.regrtest test_capi
test_capi
test test_capi failed -- Traceback (most recent call last):
  File "C:\python-dev\py3k\lib\test\test_capi.py", line 50, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\r\n\r
\nThis application has requested the Runtime to terminate it in an unusual way.\
nPlease contact the application's support team for more information." != b'Fatal
 Python error: PyThreadState_Get: no current thread'

1 test failed:
    test_capi

----------
components: Interpreter Core, Tests
messages: 108914
nosy: brian.curtin
priority: normal
severity: normal
status: open
title: test_capi.test_no_FatalError_infinite_loop crash on Windows
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun 29 18:52:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 16:52:40 +0000
Subject: [New-bugs-announce] [issue9117] class syntax not fully documented
	in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>


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

Looking at:

http://docs.python.org/dev/py3k/reference/compound_stmts.html#class-definitions

I see:

classdef    ::=  [decorators] "class" classname [inheritance] ":" suite
inheritance ::=  "(" [expression_list] ")"
classname   ::=  identifier

this seems to be missing the keyword arguments that are now possible in a classdef (e.g. for specifying a metaclass).  I believe that *args and **kwargs are now also syntactically accepted in a class definition.

----------
assignee: docs at python
components: Documentation
messages: 108917
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: class syntax not fully documented in reference manual
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 20:32:49 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 29 Jun 2010 18:32:49 +0000
Subject: [New-bugs-announce] [issue9118] help() on a property descriptor
	launches interactive help
In-Reply-To: <1277836369.81.0.859952586368.issue9118@psf.upfronthosting.co.za>
Message-ID: <1277836369.81.0.859952586368.issue9118@psf.upfronthosting.co.za>


New submission from Jack Diederich <jackdied at gmail.com>:

ython 2.7b2+ (trunk:81337, May 19 2010, 12:16:22) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class X(object):
...   @property
...   def foo(self): pass
... 
>>> help(X.foo.fset)

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> ^D
You are now leaving help and returning to the Python interpreter.
If you want to ask for help on a particular object directly from the
interpreter, you can type "help(object)".  Executing "help('string')"
has the same effect as typing a particular string at the help> prompt.
>>>

----------
components: Library (Lib)
messages: 108928
nosy: jackdied
priority: low
severity: normal
stage: needs patch
status: open
title: help() on a property descriptor launches interactive help
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun 29 20:37:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:37:38 +0000
Subject: [New-bugs-announce] [issue9119] Python download page needs to
	mention crypto code in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

This needs to be done to protect our users (importing crypto code or using it may be illegal in their home country, see http://rechten.uvt.nl/koops/cryptolaw/ for a survey) and to satisfy an attribution requirement in the OpenSSL license and code base:

"""
This product includes cryptographic software written by Eric Young (eay at cryptsoft.com). This product includes software written by Tim Hudson (tjh at cryptsoft.com). This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
"""

----------
assignee: docs at python
components: Build, Documentation
messages: 108929
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: Python download page needs to mention crypto code in Windows installer
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 29 21:28:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 19:28:40 +0000
Subject: [New-bugs-announce] [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>


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

Empty sets are pickled as set([]).  The pickle contains serialization of an empty list that is passed to set constructor during unpickling:

>>> dis(dumps(set()))
    0: \x80 PROTO      3
    2: c    GLOBAL     'builtins set'
   16: q    BINPUT     0
   18: ]    EMPTY_LIST
   19: q    BINPUT     1
   21: \x85 TUPLE1
   22: q    BINPUT     2
   24: R    REDUCE
   25: q    BINPUT     3
   27: .    STOP

The proposed patch pickles empty set as set() instead:


>>> dis(dumps(set()))
    0: \x80 PROTO      3
    2: c    GLOBAL     'builtins set'
   16: q    BINPUT     0
   18: )    EMPTY_TUPLE
   19: R    REDUCE
   20: q    BINPUT     1
   22: .    STOP

----------
components: Interpreter Core
files: empty-set-pickle.diff
keywords: patch
messages: 108937
nosy: alexandre.vassalotti, belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Reduce pickle size for an empty set
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17804/empty-set-pickle.diff

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

From report at bugs.python.org  Tue Jun 29 22:41:59 2010
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Jun 2010 20:41:59 +0000
Subject: [New-bugs-announce] [issue9121] Glossary entry for nested scope
	incorrect
In-Reply-To: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>
Message-ID: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>


New submission from Ethan Furman <ethan at stoneleaf.us>:

It currently states "Note that nested scopes work only for reference and not for assignment which will always write to the innermost scope."

This should be updated to read, e.g. "Note that unless the new nonlocal keyword is used nested scopes work only for reference and not for assignment which will otherwise write to the innermost scope."

----------
assignee: docs at python
components: Documentation
messages: 108949
nosy: docs at python, stoneleaf
priority: normal
severity: normal
status: open
title: Glossary entry for nested scope incorrect
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun 29 23:34:42 2010
From: report at bugs.python.org (Alexander Myodov)
Date: Tue, 29 Jun 2010 21:34:42 +0000
Subject: [New-bugs-announce] [issue9122] Problems with multiprocessing,
	Python embedding and Windows
In-Reply-To: <1277847282.9.0.57284514454.issue9122@psf.upfronthosting.co.za>
Message-ID: <1277847282.9.0.57284514454.issue9122@psf.upfronthosting.co.za>


New submission from Alexander Myodov <amyodov at gmail.com>:

Hello,

I am using Python 2.6.5 and Cython (to embed the Python interpreter) to create a simple launcher.exe launcher which then imports and uses the remaining logic from the other modules, conveniently stored in a single modules.zip file (i.e. importing from inside zip file). Such setup causes some issues when it comes to the multiprocessing.

First of all, the __main__ module is built as a binary (via Cython->mingw), but the stuff like freeze is not used. In multiprocessing/forking.py, when it comes to determination of the primary path, there is a WINEXE variable which affects the further processing. In its assignment, getattr(sys, 'frozen', False) obviously results in False, causing the WINEXE variable be False too (though in my case it is obviously wrong, the stuff like imp.is_builtin("__main__") shows that the main module is indeed builtin). This is the first problem which probably could be solved by adding an additional check for something like imp.is_builtin("__main__") to WINEXE assignment.
Further, as the WINEXE is wrongly False, it causes the "if not WINEXE:" branch to be processed, and adds the 'main_path' to the data, containing the name of the .exe file. 
On the forked side, d['main_path'] is received and parsed, and the name of the .exe file is split out of its extension, and such name is attempted to be imported, using imp.find_module/imp.load_module. The import fails, as there is indeed no such files wildly lying around in the installation; on the other hand, to get a quick fix of the problem, I thought of adding the appropriate launcher.py(.pyo/.pyc) files into the modules.zip, so that they still could be externally imported by the "launcher" name, even though it is already builtin under the __main__ name; but the second problem is that the imp.find_module/imp.load_module functions do not find the module inside the zip files, like the import statement does.

----------
components: Extension Modules, Windows
messages: 108953
nosy: honeyman
priority: normal
severity: normal
status: open
title: Problems with multiprocessing, Python embedding and Windows
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 30 05:48:35 2010
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 30 Jun 2010 03:48:35 +0000
Subject: [New-bugs-announce] [issue9123] insecure os.urandom on VMS
In-Reply-To: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>
Message-ID: <1277869715.19.0.305414138773.issue9123@psf.upfronthosting.co.za>


New submission from Zooko O'Whielacronx <zooko at zooko.com>:

os.urandom() on VMS invokes OpenSSL's RAND_pseudo_bytes(). That is documented on:

http://www.openssl.org/docs/crypto/RAND_bytes.html

as being predictable and therefore unsuitable for many cryptographic purposes. This is inconsistent with the documentation of os.urandom():

"""
urandom(n) -> str\n\n\
Return a string of n random bytes suitable for cryptographic use.
"""

This probably means that users of Python on VMS are vulnerable to attack based on the predictability of the results they get from os.urandom().

Honestly, I would have guessed that there *were* no users of Python on VMS when I started this bug report, but look--apparently there are:

http://www.vmspython.org

To fix this, change the call from RAND_pseudo_bytes() to RAND_bytes(). It has the same type signature and actually does what os.urandom() needs.

----------
messages: 108963
nosy: zooko
priority: normal
severity: normal
status: open
title: insecure os.urandom on VMS

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

From report at bugs.python.org  Wed Jun 30 14:28:23 2010
From: report at bugs.python.org (Steve Holden)
Date: Wed, 30 Jun 2010 12:28:23 +0000
Subject: [New-bugs-announce] [issue9124] Mailbox module demonstrates
	infeasibly slow performance
In-Reply-To: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>
Message-ID: <1277900903.38.0.556015912714.issue9124@psf.upfronthosting.co.za>


New submission from Steve Holden <steve at holdenweb.com>:

The attached program completes in less than half a second under Python 2.5. Under Python 3 it takes almost three minutes on the same system. The issue appears to be heavy use of decoding, at least in a Windows system, during creation of the mailbox toc. The disparity may be less remarkable when not profiling.

Further attachments will include a test data file (a Thunderbird mailbox taken from the same host system) and profiler outputs from the 2.5 and 3.1 runs of this program.

----------
components: Library (Lib)
files: test_thunderbird_mailbox.py
messages: 108978
nosy: holdenweb
priority: normal
severity: normal
stage: unit test needed
status: open
title: Mailbox module demonstrates infeasibly slow performance
type: performance
versions: Python 3.1
Added file: http://bugs.python.org/file17809/test_thunderbird_mailbox.py

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

From report at bugs.python.org  Wed Jun 30 16:36:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 14:36:34 +0000
Subject: [New-bugs-announce] [issue9125] parser module doesn't like
	except-as syntax.
In-Reply-To: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>
Message-ID: <1277908594.27.0.526273796473.issue9125@psf.upfronthosting.co.za>


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

There seems to be a parser module bug for the except-as syntax in Python 2.7.  After applying the attached patch (which adds a test to test_parser), and running test_parser, I get:


======================================================================
FAIL: test_try_stmt (__main__.RoundtripLegalSyntaxTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_parser.py", line 237, in test_try_stmt
    self.check_suite("try: pass\nexcept A as e: pass\n")
  File "Lib/test/test_parser.py", line 38, in check_suite
    self.roundtrip(parser.suite, s)
  File "Lib/test/test_parser.py", line 20, in roundtrip
    self.fail("could not roundtrip %r: %s" % (s, why))
AssertionError: could not roundtrip 'try: pass\nexcept A as e: pass\n': Expected node type 12, got 1.

----------
files: parser_except_as_bug.patch
keywords: patch
messages: 108984
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: parser module doesn't like except-as syntax.
versions: Python 2.7
Added file: http://bugs.python.org/file17814/parser_except_as_bug.patch

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

From report at bugs.python.org  Wed Jun 30 17:22:46 2010
From: report at bugs.python.org (John Van Praag)
Date: Wed, 30 Jun 2010 15:22:46 +0000
Subject: [New-bugs-announce] [issue9126] errors='replace' does not work at
	Windows command line
In-Reply-To: <1277911366.4.0.473449546724.issue9126@psf.upfronthosting.co.za>
Message-ID: <1277911366.4.0.473449546724.issue9126@psf.upfronthosting.co.za>


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

The declaration errors='replace' works from within IDLE but not at the Windows command line. I am attaching a program and text file that demonstrate the problem. The error shows up at the Windows command line as follows:

C:\Users\John\Documents\Python\bug_reports\001>python -m read_my_file
aaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaaa aaaaaaaaa

bbbbbbbbbbb bbbbbbbbbbbb bbbbbbbbbbbbbbbbbbb bbbbbbbbbbbb

Traceback (most recent call last):
  File "C:\Python31\lib\runpy.py", line 128, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python31\lib\runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "C:\Users\John\Documents\Python\bug_reports\001\read_my_file.py", line 20, in <module>
    readf()
  File "C:\Users\John\Documents\Python\bug_reports\001\read_my_file.py", line 17, in readf
    print(line)
  File "C:\Python31\lib\encodings\cp437.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 10-11: character maps to <undefined>


NOTE: It appears I can only attach 1 file to this report. So I am copying the program here. The text file to read is attached.

'''
read_my_file.py:
Reads lines from faulty file.
Hangs at line 3 when run from Windows command line.
Platforms:
Windows Vista Ultimate 64-bit
Python 3.1.2
'''
#The file to read.
my_file = 'junk.txt'

def readf():
	#The declaration "errors='replace'" is suppposed replace characters the reader does not recognize with a dummy character such as a question mark.
	#This fix works in the interpreter, but not from the Windows command line.
	fh_read = open(my_file, errors='replace')
	for line in fh_read:
		print(line)

#Run.
readf()

----------
components: Windows
files: junk.txt
messages: 108987
nosy: jvanpraag
priority: normal
severity: normal
status: open
title: errors='replace' does not work at Windows command line
versions: Python 3.1
Added file: http://bugs.python.org/file17816/junk.txt

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

From report at bugs.python.org  Wed Jun 30 17:54:57 2010
From: report at bugs.python.org (Benjamin Ryzman)
Date: Wed, 30 Jun 2010 15:54:57 +0000
Subject: [New-bugs-announce] [issue9127] subprocess.Popen.communicate() and
	SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>


New submission from Benjamin Ryzman <benjamin+python at ryzman.fr>:

http://pastie.org/1025197

Is it deemed acceptable that setting up one's own SIGCHLD handler breaks communicate()?

I did not find it in the documentation.

With the above workaround one can mix communicate() processes with processes spawned in the background that one's too lazy to wait for.

----------
messages: 108990
nosy: zarkdav
priority: normal
severity: normal
status: open
title: subprocess.Popen.communicate() and SIGCHLD handlers
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 30 20:11:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 18:11:42 +0000
Subject: [New-bugs-announce] [issue9128] Parser module fails to validate
	class decorators	correctly.
In-Reply-To: <1277921502.31.0.321329745458.issue9128@psf.upfronthosting.co.za>
Message-ID: <1277921502.31.0.321329745458.issue9128@psf.upfronthosting.co.za>


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

Python 2.7rc2+ (trunk:82399M, Jun 30 2010, 17:10:13) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
[35303 refs]
>>> parser.sequence2st(parser.suite("@deco\nclass A(): pass").totuple())
<parser.st object at 0x10045d310>
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: Expected node type 262, got 330.
[35347 refs]

Patch attached.

----------
components: Extension Modules
files: parser_class_decorator.patch
keywords: patch
messages: 109002
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Parser module fails to validate class decorators correctly.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17820/parser_class_decorator.patch

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

From report at bugs.python.org  Wed Jun 30 20:44:27 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Jun 2010 18:44:27 +0000
Subject: [New-bugs-announce] [issue9129] DoS smtpd module vulnerability
In-Reply-To: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>
Message-ID: <1277923467.7.0.260357628044.issue9129@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Steps to reproduce the issue:

- in one shell run: "python -m smtpd -n"
- in another one run: "for i in {1..1000};do nmap -sT -p 8025 localhost;done"

The server will print out the following output and just quit (DoS):

giampaolo at ubuntu:~/svn/python-2.7$ ./python -m smtpd -n 
error: uncaptured python exception, closing channel <__main__.PureProxy listening localhost:8025 at 0xb74b0f4c> (<class 'socket.error'>:[Errno 107] Transport endpoint is not connected [/home/giampaolo/svn/python-2.7/Lib/asyncore.py|read|79] [/home/giampaolo/svn/python-2.7/Lib/asyncore.py|handle_read_event|430] [/home/giampaolo/svn/python-2.7/Lib/smtpd.py|handle_accept|296] [/home/giampaolo/svn/python-2.7/Lib/smtpd.py|__init__|124] [/home/giampaolo/svn/python-2.7/Lib/socket.py|meth|222])
giampaolo at ubuntu:~/svn/python-2.7$ 

This is due to issue 6706.

----------
components: Library (Lib)
messages: 109003
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: DoS smtpd module vulnerability
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun 30 21:31:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Jun 2010 19:31:06 +0000
Subject: [New-bugs-announce] [issue9130] Parser module fails on short
	relative imports
In-Reply-To: <1277926266.72.0.295877621023.issue9130@psf.upfronthosting.co.za>
Message-ID: <1277926266.72.0.295877621023.issue9130@psf.upfronthosting.co.za>


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

Python 2.7rc2+ (trunk:82399M, Jun 30 2010, 17:10:13) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
[35303 refs]
>>> parser.sequence2st(parser.suite("from . import me").totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: VALIDATION FAILURE: report this to the maintainer!
[35341 refs]

Patch attached.

----------
assignee: mark.dickinson
components: Extension Modules
files: parser_relative_imports.patch
keywords: patch
messages: 109006
nosy: mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Parser module fails on short relative imports
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17821/parser_relative_imports.patch

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

From report at bugs.python.org  Wed Jun 30 21:48:00 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:48:00 +0000
Subject: [New-bugs-announce] [issue9131] test_set_reprs in test_pprint is
	fragile
In-Reply-To: <1277927280.23.0.76585633164.issue9131@psf.upfronthosting.co.za>
Message-ID: <1277927280.23.0.76585633164.issue9131@psf.upfronthosting.co.za>


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

test_set_reprs in test_pprint creates a complex arrangement of frozensets and tests the pretty-printed repr against a string hard-coded in the test.  The hard-coded repr depends on the sort order of frozensets.  

However, "Since sets only define partial ordering (subset relationships), the output of the list.sort() method is undefined for lists of sets." (quoting http://docs.python.org/release/3.1/library/stdtypes.html#set-types-set-frozenset)

In a nutshell, the test assumes frozenset({0}) will always sort before frozenset({1}), but:

>>> frozenset({0}) < frozenset({1})
False
>>> frozenset({1}) < frozenset({0})
False

Consequently, this test is fragile.  Small changes to Python's sort algorithm cause the test to fail when it should pass.

I ran into this while playing with optimizations to the sort function, but I imagine other Python implementations will also run into trouble with this test.

----------
assignee: stutzbach
components: Tests
messages: 109008
nosy: stutzbach
priority: low
severity: normal
stage: needs patch
status: open
title: test_set_reprs in test_pprint is fragile
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 30 21:59:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:59:11 +0000
Subject: [New-bugs-announce] [issue9132] Documentation for comparing
	dictionaries is out of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>


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

reference/expressions.html#notin reads:

"Mappings (dictionaries) compare equal if and only if their sorted (key, value) lists compare equal. [4] Outcomes other than equality are resolved consistently, but are not otherwise defined. [5]"

However, the last sentence is no longer true.  I suggest changing the last sentence to:

"Comparisons other than equality testing raise a TypeError."

I think the footnote [5] is sufficiently historical that it could be removed as well.  Alternately, it could be updated to read, "In older versions of Python, outcomes other than equality were resolved consistently but were not otherwise defined."

----------
assignee: docs at python
components: Documentation
messages: 109009
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Documentation for comparing dictionaries is out of date
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun 30 22:02:54 2010
From: report at bugs.python.org (Mike Lewis)
Date: Wed, 30 Jun 2010 20:02:54 +0000
Subject: [New-bugs-announce] [issue9133] Invalid UTF8 Byte sequence not
	raising exception/being	substituted
In-Reply-To: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>
Message-ID: <1277928174.53.0.503418777966.issue9133@psf.upfronthosting.co.za>


New submission from Mike Lewis <mikelikespie at gmail.com>:

When I do
codecs.encode(codecs.decode('\xed\xbc\xad', 'utf8'), 'utf8')

its not throwing an exception.  '\xed\xbc\xad' is an invalid UTF8 byte sequence.

It maps to the value U+DF2D which is a "surrogate pair" it seems.

http://tools.ietf.org/html/rfc3629#section-4

explains:

      However, pairs of
      UCS-2 values between D800 and DFFF (surrogate pairs in Unicode
      parlance), being actually UCS-4 characters transformed through
      UTF-16, need special treatment: the UTF-16 transformation must be
      undone, yielding a UCS-4 character that is then transformed as
      above.

which would suggest that it is invalid.

However, I think wikipedia's explanation is a bit clearer:

UTF-8 may only legally be used to encode valid Unicode scalar values. According to the Unicode standard the high and low surrogate halves used by UTF-16 (U+D800 through U+DFFF) and values above U+10FFFF are not legal Unicode values, and the UTF-8 encoding of them is an invalid byte sequence and should be treated as described above.


Thanks,
Mike

----------
components: Unicode
messages: 109010
nosy: Mike.Lewis
priority: normal
severity: normal
status: open
title: Invalid UTF8 Byte sequence not raising exception/being substituted
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 30 23:18:58 2010
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 30 Jun 2010 21:18:58 +0000
Subject: [New-bugs-announce] [issue9134] sre bug: lastmark_save/restore
In-Reply-To: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>
Message-ID: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

The re module is buggy is rare cases; see attached example script.

The bug is caused by the macros LASTMARK_SAVE and LASTMARK_RESTORE which are sometimes used without the extra code that does if (state->repeat) {mark_save()/mark_restore()}.

The bug appears by mis-reporting the position of groups within a repeated match (with * or +), notably the position of some groups that matched in older repetitions but (after some backtracking) not in newer ones.

----------
components: Extension Modules
files: x.py
messages: 109019
nosy: arigo
priority: normal
severity: normal
status: open
title: sre bug: lastmark_save/restore
versions: Python 2.7
Added file: http://bugs.python.org/file17822/x.py

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

From report at bugs.python.org  Wed Jun 30 23:57:19 2010
From: report at bugs.python.org (Delaney Gillilan)
Date: Wed, 30 Jun 2010 21:57:19 +0000
Subject: [New-bugs-announce] [issue9135] XMLRPC documentation binary file
	example does not execute.
In-Reply-To: <1277935039.2.0.645963756108.issue9135@psf.upfronthosting.co.za>
Message-ID: <1277935039.2.0.645963756108.issue9135@psf.upfronthosting.co.za>


New submission from Delaney Gillilan <delaneygillilan at gmail.com>:

Documentation available at http://docs.python.org/release/3.0.1/library/xmlrpc.client.html#binary-objects produced incorrect results ...

Traceback (most recent call last):
  File "test_server.py", line 28, in <module>
    print(handle.read().format('utf-8'))
  File "C:\python31\lib\io.py", line 1728, in read
    decoder.decode(self.buffer.read(), final=True))
  File "C:\python31\lib\io.py", line 1299, in decode
    output = self.decoder.decode(input, final=final)
  File "C:\python31\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 252: character maps to <undefined>

However a quick change (new to Python3 so this may need work) gives desired results.

Server:
from xmlrpc.server import SimpleXMLRPCServer
import xmlrpc.client
def python_logo():
     handle = open("python_logo.jpg", "rb") <-- needed "rb"
     return xmlrpc.client.Binary(handle.read())
     handle.close()
server = SimpleXMLRPCServer(("localhost", 8000))
print("Listening on port 8000...")
server.register_function(python_logo, 'python_logo')
server.serve_forever()

Client:
import xmlrpc.client
proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
handle = open("fetched_python_logo.jpg", "wb") <-- needed "wb"
handle.write(proxy.python_logo().data)
handle.close()

Please update the documentation.  Thanks!

----------
components: Library (Lib)
messages: 109021
nosy: Delaney.Gillilan
priority: normal
severity: normal
status: open
title: XMLRPC documentation binary file example does not execute.
type: crash
versions: Python 3.1

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