From report at bugs.python.org  Mon Oct  1 02:50:09 2007
From: report at bugs.python.org (Richie Ward)
Date: Mon, 01 Oct 2007 00:50:09 -0000
Subject: [New-bugs-announce] [issue1223] httplib does not handle ssl end of
	file properly
Message-ID: <1191199809.02.0.233978380017.issue1223@psf.upfronthosting.co.za>


New submission from Richie Ward:

I was using httplib to power my xml rpc script.

I had problems when I wanted to use SSL and I got this error:
 File "/usr/lib/python2.5/httplib.py", line 1109, in recv
   return self._ssl.read(len)
socket.sslerror: (8, 'EOF occurred in violation of protocol')

I figured out this was because of poor error handling in python.

May I suggest this as a fix to this bug:
$ diff /usr/lib/python2.5/httplib.py /usr/lib/python2.5/httplib.py~
1109,1112c1109
<         try:
<             return self._ssl.read(len)
<         except socket.sslerror:
<             return
---
>         return self._ssl.read(len)

Just a note. I am by no means a python expert, just good enough to get
my work done.
I use Ubuntu gutsy.

----------
components: Library (Lib)
messages: 56203
nosy: Richie
severity: major
status: open
title: httplib does not handle ssl end of file properly
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  1 13:20:26 2007
From: report at bugs.python.org (philfr)
Date: Mon, 01 Oct 2007 11:20:26 -0000
Subject: [New-bugs-announce] [issue1224] SimpleHTTPServer doesn't understand
	// at beginning of path anymore
Message-ID: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za>


New submission from philfr:

The fix to issue 1394565 introduces a nasty side-effect:
"GET http://server//file" (with two /s) does not work anymore. It
returns the directory index instead.

This is because urlparse is not applied to an URL, but to its right-hand
part starting at the path.

urlparse.urlparse("http://server//foo")[2] correctly returns //foo, but 
urlparse.urlparse("//foo")[2] (as used in this library) returns an empty
string.

----------
components: Library (Lib)
messages: 56205
nosy: philfr
severity: normal
status: open
title: SimpleHTTPServer doesn't understand // at beginning of path anymore
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Mon Oct  1 22:18:00 2007
From: report at bugs.python.org (Tal Einat)
Date: Mon, 01 Oct 2007 20:18:00 -0000
Subject: [New-bugs-announce] [issue1225] IDLE - Fix: pressing Ctrl+C while
	printing exception -> stuck
Message-ID: <1191269880.22.0.587814437498.issue1225@psf.upfronthosting.co.za>


New submission from Tal Einat:

Patch run.py, adding a global 'interruptable' flag which is set only
when executing code. This avoids interrupting the main thread while it
is printing an exception, which would cause IDLE to freeze up.

Reworked patch from IDLE-Spoon.

----------
components: IDLE
files: IDLE_Interrupt.071001.patch
messages: 56209
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Fix: pressing Ctrl+C while printing exception -> stuck
type: crash
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_Interrupt.071001.patch
Type: application/octet-stream
Size: 1348 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071001/5d319720/attachment.obj 

From report at bugs.python.org  Tue Oct  2 00:12:59 2007
From: report at bugs.python.org (lorph)
Date: Mon, 01 Oct 2007 22:12:59 -0000
Subject: [New-bugs-announce] [issue1226] lib/sched.py superfluous code for
	removal
Message-ID: <1191276779.49.0.11926162245.issue1226@psf.upfronthosting.co.za>


New submission from lorph:

Line 114 of lib/sched.py:

It has a superfluous variable assignment which I deleted.
"void ="

----------
components: Library (Lib)
files: sched.py
messages: 56210
nosy: lorph
severity: normal
status: open
title: lib/sched.py superfluous code for removal
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1226>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sched.py
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071001/05cd9445/attachment.txt 

From report at bugs.python.org  Tue Oct  2 06:00:57 2007
From: report at bugs.python.org (Dean Elzinga)
Date: Tue, 02 Oct 2007 04:00:57 -0000
Subject: [New-bugs-announce] [issue1227] csv docs say 'excel_tab';
	code says 'excel-tab'
Message-ID: <1191297657.28.0.047850025382.issue1227@psf.upfronthosting.co.za>


New submission from Dean Elzinga:

I was trying out 'csv module' and noticed that it wouldn't accept a
dialect of 'excel_tab' as documented.

Then I noticed that csv.list_dialects() gave 'excel-tab' instead of
'excel_tab' as documented.

I'm not sure which one it's supposed to be, but I guess when in doubt
the docs are wrong. I leave these issues to the higher gods.

Thanks for the work on this module. I'm enjoying it!

----------
components: Library (Lib)
messages: 56211
nosy: dcelzinga
severity: normal
status: open
title: csv docs say 'excel_tab'; code says 'excel-tab'
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct  2 13:06:01 2007
From: report at bugs.python.org (Peter Harris)
Date: Tue, 02 Oct 2007 11:06:01 -0000
Subject: [New-bugs-announce] [issue1228] 3.0 tutorial/datastructures.rst
	patch
Message-ID: <1191323161.32.0.788798026537.issue1228@psf.upfronthosting.co.za>


New submission from Peter Harris:

Describe 3.0 comparison behaviour (but not in much detail)

----------
components: Documentation
files: datastructures.diff
messages: 56212
nosy: scav
severity: normal
status: open
title: 3.0 tutorial/datastructures.rst patch
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1228>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datastructures.diff
Type: application/octet-stream
Size: 1157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071002/3bc13b37/attachment.obj 

From report at bugs.python.org  Tue Oct  2 13:12:04 2007
From: report at bugs.python.org (Peter Harris)
Date: Tue, 02 Oct 2007 11:12:04 -0000
Subject: [New-bugs-announce] [issue1229] 3.0 library/stdtypes.rst
Message-ID: <1191323524.35.0.925963615426.issue1229@psf.upfronthosting.co.za>


New submission from Peter Harris:

line 221 'loating point' -> 'Floating point'.

Also, maybe double-check that __cmp__ method still has special meaning
in 3.0.  My last patch took out mention of it because 3.0a1 seems not to
support comparisons using __cmp__ method, but I could be missing something.

----------
components: Documentation
messages: 56213
nosy: scav
severity: minor
status: open
title: 3.0 library/stdtypes.rst
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct  3 16:47:32 2007
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 03 Oct 2007 14:47:32 -0000
Subject: [New-bugs-announce] [issue1231] PEPs 344 and 3134 contain incorrect
	hyperlinks.
Message-ID: <1191422851.65.0.253135139161.issue1231@psf.upfronthosting.co.za>


New submission from Raghuram Devarakonda:

http://www.python.org/dev/peps/pep-0344/
http://www.python.org/dev/peps/pep-3134/

Check both the PEPs and grep for the first occurrence of "RFC 88" which
is a link. The target of the link is http://www.faqs.org/rfcs/rfc88.html
which is wrong. The correct value is indicated in footnote [9].

----------
components: Documentation
messages: 56217
nosy: draghuram
severity: minor
status: open
title: PEPs 344 and 3134 contain incorrect hyperlinks.

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

From report at bugs.python.org  Wed Oct  3 18:36:05 2007
From: report at bugs.python.org (Kevin McKiou)
Date: Wed, 03 Oct 2007 16:36:05 -0000
Subject: [New-bugs-announce] [issue1232] %f prints the wrong 6 decimal places
Message-ID: <1191429364.71.0.660375750345.issue1232@psf.upfronthosting.co.za>


New submission from Kevin McKiou:

>>> print "price is: %f" % 5.1234567
price is: 5.123457
 
I was testing the statement about "prints to 6 decimal places".  Sure 
enough, it printed only 6 decimal places, but it skipped over the 6th 
decimal place and printed the 7th.
 
I am using Python version 2.5.1 and IDLE version 1.2.1

----------
components: Interpreter Core
messages: 56218
nosy: kmckiou
severity: major
status: open
title: %f prints the wrong 6 decimal places
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct  3 18:45:21 2007
From: report at bugs.python.org (Steven Vereecken)
Date: Wed, 03 Oct 2007 16:45:21 -0000
Subject: [New-bugs-announce] [issue1233] bsddb.dbshelve.DbShelf.append
	doesn't work
Message-ID: <1191429921.84.0.632330951206.issue1233@psf.upfronthosting.co.za>


New submission from Steven Vereecken:

The check for DB_RECNO seems to do the opposite of what it's supposed to do:

    def append(self, value, txn=None):
        if self.get_type() != db.DB_RECNO:
            self.append = self.__append
            return self.append(value, txn=txn)
        raise db.DBError, "append() only supported when dbshelve opened
with filetype=dbshelve.db.DB_RECNO"

----------
components: Library (Lib)
messages: 56219
nosy: polaar
severity: normal
status: open
title: bsddb.dbshelve.DbShelf.append doesn't work
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct  4 11:18:15 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09S=C3=A9bastien_Sabl=C3=A9=0A=09=09=09=09?=)
Date: Thu, 04 Oct 2007 09:18:15 -0000
Subject: [New-bugs-announce] [issue1234] semaphore errors on AIX 5.2
Message-ID: <1191489495.02.0.0992368584163.issue1234@psf.upfronthosting.co.za>


New submission from 
					S?bastien Sabl?
				:

There used to be a bug open concerning this problem in the old bug
tracker but I can't find it in the new bug tracker:

http://mail.python.org/pipermail/python-bugs-list/2005-June/029290.html

----------
messages: 56226
nosy: sable
severity: normal
status: open
title: semaphore errors on AIX 5.2

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

From report at bugs.python.org  Thu Oct  4 12:13:02 2007
From: report at bugs.python.org (Andy Schumann)
Date: Thu, 04 Oct 2007 10:13:02 -0000
Subject: [New-bugs-announce] [issue1235] CGIHTTPRequestHandler.run_cgi()
	does not run on Windows if sys.executable contains blanks
Message-ID: <1191492781.93.0.606740316101.issue1235@psf.upfronthosting.co.za>


New submission from Andy Schumann:

On Windows a path can contain spaces (e.g. C:\Program Files\python22
\python.exe). If using popenx each component in a command line has 
therefore to be double quoted as well as the whole command string.
The method run_cgi() of the class CGIHTTPRequestHandler in the module 
CGIHTTPServer does not do this.

Therefore the line 236:
cmdline = "%s -u %s" % (interp, cmdline)
should be replaced by
cmdline = '""%s" -u "%s""' % (interp, cmdline)

----------
components: Windows
messages: 56229
nosy: schu
severity: normal
status: open
title: CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks
versions: Python 2.3

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

From report at bugs.python.org  Thu Oct  4 23:31:58 2007
From: report at bugs.python.org (Kenneth Duda)
Date: Thu, 04 Oct 2007 21:31:58 -0000
Subject: [New-bugs-announce] [issue1236] subprocess is not thread-safe
Message-ID: <1191533517.74.0.548071476021.issue1236@psf.upfronthosting.co.za>


New submission from Kenneth Duda:

The following test program crashes:

========================================
import threading, sys, subprocess

# subprocess._cleanup = lambda: None

def doit():
   for i in xrange(0, 1000):
      p = subprocess.Popen( "true" )
      p.wait()

t = threading.Thread( target=doit )
t.start()
doit()

==============================

It crashes because when one thread calls subprocess.Popen(), subprocess
calls this _cleanup() function, which might reap the subprocess started
in another thread !  The other thread might be inside
subprocess.Popen.wait(), just about to call waitpid(), and kill itself.

If you uncomment the commented line, then the program runs with no problems.

I imagine the purpose of _cleanup is to protect users from themselves,
i.e., protect a user who calls subprocess.Popen() a lot without ever
calling wait().  I suggest either:

  (1) eliminating this _cleanup() mechanism completely; people who do
not wait() deserve the zombies they get;
  (2) synchronizing _cleanup() with wait() through a lock; or,
  (3) having wait() simply retry if it gets ECHILD.  On the retry, it
will discover that returncode is set, and return normally.

-Ken

----------
components: Library (Lib)
messages: 56230
nosy: kjd at duda.org
severity: normal
status: open
title: subprocess is not thread-safe
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct  5 02:00:42 2007
From: report at bugs.python.org (Adam Olsen)
Date: Fri, 05 Oct 2007 00:00:42 -0000
Subject: [New-bugs-announce] [issue1237] type_new doesn't allocate space for
	sentinal slot
Message-ID: <1191542441.83.0.652795661207.issue1237@psf.upfronthosting.co.za>


New submission from Adam Olsen:

type_new() allocates the exact number of slots it's going to use, but
various other functions assume there's one more slot with a NULL name
field serving as a sentinel.  I'm unsure why it doesn't normally crash.

----------
components: Interpreter Core
messages: 56231
nosy: rhamphoryncus
severity: normal
status: open
title: type_new doesn't allocate space for sentinal slot

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

From report at bugs.python.org  Fri Oct  5 09:30:55 2007
From: report at bugs.python.org (Anthon van der Neut)
Date: Fri, 05 Oct 2007 07:30:55 -0000
Subject: [New-bugs-announce] [issue1238] dictobject and dictentry not used
	consistently in dictobject.c
Message-ID: <1191569454.84.0.732829758035.issue1238@psf.upfronthosting.co.za>


New submission from Anthon van der Neut:

In dictobject.c the structures from dictobject.h are typedeffed to:
typedef PyDictEntry dictentry;
typedef PyDictObject dictobject;

However there are still a few locations in that file where the
PyDictEntry and PyDictObject types are used directly. IMHO these should
be replaced by  dictentry resp. dictobject

Attached is a patch for that.

----------
components: Interpreter Core
files: dictobject.c.patch
messages: 56234
nosy: anthon
severity: minor
status: open
title: dictobject and dictentry not used consistently in dictobject.c
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1238>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dictobject.c.patch
Type: text/x-patch
Size: 1703 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071005/90ce3c40/attachment.bin 

From report at bugs.python.org  Fri Oct  5 15:20:23 2007
From: report at bugs.python.org (Tim Gordon)
Date: Fri, 05 Oct 2007 13:20:23 -0000
Subject: [New-bugs-announce] [issue1240] str.split possible bug
Message-ID: <1191590423.15.0.942254766334.issue1240@psf.upfronthosting.co.za>


New submission from Tim Gordon:

>From the docs for str.split:
"If sep is not specified or is None... First, whitespace characters are 
stripped from both ends. Then, words are separated by arbitrary length 
strings of whitespace characters."

However, ' a b c '.split(None, 1) returns ['a', 'b c '] indicating that 
the "stripped from both ends" isn't taking place, but that it's 
removing whitespace as it goes and never gets to the end as it stops 
parsing when it hits the first split.

Note this is easily worked around by calling str.strip().split(None, 
1), but it would be good not to have to.

I've tested this on windows version 2.5, and 2.4.4 for Debian

----------
messages: 56237
nosy: QuantumTim
severity: normal
status: open
title: str.split possible bug
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Fri Oct  5 22:09:30 2007
From: report at bugs.python.org (Jason Kim)
Date: Fri, 05 Oct 2007 20:09:30 -0000
Subject: [New-bugs-announce] [issue1241] subprocess.py stdout of
	childprocess always buffered.
Message-ID: <1191614970.62.0.0159920077283.issue1241@psf.upfronthosting.co.za>


New submission from Jason Kim:

Hi. 

I am currently using subprocess.py (2.4.4 and above) to try to have a
portable way of running a sub task in linux and windows.

I ran into a strange problem - a program runs and is "timed out"
but the the subprocess's stdout and stderr are not fully "grabbed"
So I've been trying various ways to force "flush" the stdout and stderr
of the child process so that at least partial results can be saved.

The "problem" app being spawned off is very simple:
--------------------------------------
#include <stdio.h>

int main() {
  int i = 0;
  for (i = 0; i < 1000; ++i) {
    printf("STDOUT boo %d\n",i);
    fprintf(stdout,"STDOUT sleeping %d\n",i);
    fprintf(stderr,"STDERR sleeping %d\n",i);
    //fflush(stdout);
    //fflush(stderr);
    sleep(1);
  } 
}

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

i.e. it just dumps its output to both stdout and stderr. The issue that
I am seeing is that no matter what options I tried to place for
subprocess(), the ONLY output I see from the executed process are

"STDERR sleeping " lines, UNLESS I uncomment the fflush(stdout) line in
the application.

Executing the script with python -u doesn't seem to help either.
Now, if the task completes normally, then I am able to grab the entire
stdout and stderr produced by the subprocess. The issue is that I can't
seem to grab the partial output for stdout, and there does not seem to
be a way to make the file descriptors returned by pipe() to be unbuffered.

So the question is: what is the preferred method of forcing the pipe()
file descriptors created by subprocess.__init__() to be fully unbuffered?

Second, is there a better way of doing this?
i.e. a portable way to spawn off a task, with an optional timeout, grab
any partial results from the task's stdout and stderr, and grab the
return code from the child task?

Any hints and advice will be greatly appreciated.

Thank you.

The relevant snippet of python code is:

import threading
from signal import *
from subprocess import *
import time
import string
import copy
import re
import sys
import os
from glob import glob
from os import path
import thread

class task_wrapper():
   def run(s):
      if s.timeout > 0:
        #print "starting timer for ",s.timeout
        s.task_timer = threading.Timer(s.timeout, task_wrapper.cleanup, [s])
        s.task_timer.start()
      s.task_start_time = time.time()
      s.task_end_time = s.task_start_time
      s.subtask=Popen(s.cmd, bufsize=0, env=s.env, stdout=PIPE, stderr=PIPE)
      s.task_out, s.task_err = s.subtask.communicate()


  def kill(s, subtask):
    """ attempts a portable way to kill things
    First, flush the buffer
    """
    print "killing", subtask.pid
    sys.stdout.flush()
    #s.subtask.stdin.flush()
    print "s.subtask.stdout.fileno()=",s.subtask.stdout.fileno()
    print "s.subtask.stderr.fileno()=",s.subtask.stderr.fileno()
    #os.fsync(s.subtask.stderr.fileno())
    #os.fsync(s.subtask.stdout.fileno())    
    s.subtask.stdout.flush()
    s.subtask.stderr.flush()
    
    if os.name == "posix":
      os.kill(subtask.pid, SIGKILL)
    elif os.name == "nt":
      import win32api
      win32api.TerminateProcess(subtask._handle ,9)

  def cleanup(s, mode="TIMEOUT"):
    s.timer_lock.acquire()
    if s.task_result == None:
    if mode == "TIMEOUT":
       s.msg( """ Uhoh, subtask took too long""")
       s.kill(s.subtask) 
       ....

----------
messages: 56247
nosy: jason.w.kim
severity: normal
status: open
title: subprocess.py stdout of childprocess always buffered.
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Sat Oct  6 07:24:51 2007
From: report at bugs.python.org (Gopinath)
Date: Sat, 06 Oct 2007 05:24:51 -0000
Subject: [New-bugs-announce] [issue1242] test
Message-ID: <cb276d030710052224h4a87ed48yf17ee169c8c6eba9@mail.gmail.com>


New submission from Gopinath:

hi

I have registerd recently
and need notes on hacking disadvantages and advantages.

----------
files: unnamed
messages: 56249
nosy: gopiyadav26
severity: normal
status: open
title: test

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1242>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071006/1c70df43/attachment.txt 

From report at bugs.python.org  Sat Oct  6 18:03:12 2007
From: report at bugs.python.org (Chris Withers)
Date: Sat, 06 Oct 2007 16:03:12 -0000
Subject: [New-bugs-announce] [issue1243] option.dest not set when callback
	called with optparse
Message-ID: <1191686592.38.0.384749327692.issue1243@psf.upfronthosting.co.za>


New submission from Chris Withers:

The attached script demonstrates the bug.

option.dest should be set, even if not explicitly supplied in the call
to parser.add_option, by the time the callback is called.

Unless dest='something' is specified in the call to add_option, you will
get the following error when running "python test.py --myopt":

  File "test.py", line 4, in mycallback
    setattr(parser.values,option.dest,value)
TypeError: attribute name must be string

...as options.dest is still None.

I would expect options.dest to be computed as per the algorithm in
optparse.Option._check_dest.

----------
components: Library (Lib)
files: test.py
messages: 56252
nosy: cjw296
severity: normal
status: open
title: option.dest not set when callback called with optparse
versions: Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1243>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 276 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071006/0d9d745d/attachment.py 

From report at bugs.python.org  Mon Oct  8 07:49:28 2007
From: report at bugs.python.org (Alexander Shirokov)
Date: Mon, 08 Oct 2007 05:49:28 -0000
Subject: [New-bugs-announce] [issue1244] Error on 'raise' does not show
	correct line number and Traceback message
Message-ID: <1191822567.87.0.476542050297.issue1244@psf.upfronthosting.co.za>


New submission from Alexander Shirokov:

Please run debracket.py
It halts immediately and the message
explains the problem.
Regards
Alex

----------
files: debracket.py
messages: 56265
nosy: alexander.shirokov
severity: normal
status: open
title: Error on 'raise' does not show correct line number and Traceback message
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1244>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debracket.py
Type: text/x-python
Size: 3157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071008/a66ffa2d/attachment.py 

From report at bugs.python.org  Mon Oct  8 08:22:32 2007
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Oct 2007 06:22:32 -0000
Subject: [New-bugs-announce] [issue1245] Document PySys_GetObject()
Message-ID: <1191824552.71.0.744627118573.issue1245@psf.upfronthosting.co.za>


New submission from Brett Cannon:

PySys_GetObject() is not documented even though it is exposed as part of
the public API.

----------
components: Documentation
messages: 56266
nosy: brett.cannon
priority: low
severity: minor
status: open
title: Document PySys_GetObject()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  8 08:22:36 2007
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Oct 2007 06:22:36 -0000
Subject: [New-bugs-announce] [issue1246] Document PySys_GetObject()
Message-ID: <1191824556.45.0.43751222304.issue1246@psf.upfronthosting.co.za>


New submission from Brett Cannon:

PySys_GetObject() is not documented even though it is exposed as part of
the public API.

----------
components: Documentation
messages: 56267
nosy: brett.cannon
priority: low
severity: minor
status: open
title: Document PySys_GetObject()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Oct  8 18:39:20 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Christian_Heimes=0A=09=09=09=09?=)
Date: Mon, 08 Oct 2007 16:39:20 -0000
Subject: [New-bugs-announce] [issue1247] PEP 3137 patch (repr, names, parser)
Message-ID: <1191861560.57.0.865268002143.issue1247@psf.upfronthosting.co.za>


New submission from 
					Christian Heimes
				:

The patches changes:

- change PyString's repr() to return "b'...'"
- change PyBytes's repr() to return "buffer(b'...')"
- change parser so that b"..." returns PyString, not PyBytes
- rename bytes -> buffer, str8 -> bytes

The patch breaks some unit test because some of the infrastructure like
the new buffer() isn't in place yet. I'm not happy with bytes_repr() but
the for loop with *p++ was the easiest way to implement it. Every other
implementation I could think of was either too complicated or wouldn't
work (like memcpy).

----------
components: Interpreter Core
files: pep3137.patch
messages: 56280
nosy: tiran
severity: major
status: open
title: PEP 3137 patch (repr, names, parser)
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1247>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pep3137.patch
Type: text/x-diff
Size: 8685 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071008/d5e76988/attachment.patch 

From report at bugs.python.org  Mon Oct  8 22:12:04 2007
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Oct 2007 20:12:04 -0000
Subject: [New-bugs-announce] [issue1248] ftplib needs a rewrite to use
	bytes/buffers
Message-ID: <1191874324.3.0.017965594704.issue1248@psf.upfronthosting.co.za>


New submission from Brett Cannon:

For instance, ftplib.FTP reads from sockets using socket.makefile(), but
in text mode.  That's bad when the data could be in the format of ASCII
or binary data.

----------
components: Library (Lib)
keywords: py3k
messages: 56281
nosy: brett.cannon
priority: normal
severity: major
status: open
title: ftplib needs a rewrite to use bytes/buffers
versions: Python 3.0

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

From report at bugs.python.org  Tue Oct  9 15:38:28 2007
From: report at bugs.python.org (Thomas Lee)
Date: Tue, 09 Oct 2007 13:38:28 -0000
Subject: [New-bugs-announce] [issue1249] PEP 3137 patch: make
	PyBytes/PyUnicode ==/!= comparisons return False
Message-ID: <1191937107.83.0.816091478678.issue1249@psf.upfronthosting.co.za>


New submission from Thomas Lee:

Initial patch attached.

----------
components: Interpreter Core
files: bytes-unicode-return-false-r1.patch
messages: 56284
nosy: thomas.lee
severity: normal
status: open
title: PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False
type: rfe
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1249>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytes-unicode-return-false-r1.patch
Type: text/x-patch
Size: 1581 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071009/0faf8ac7/attachment.bin 

From report at bugs.python.org  Tue Oct  9 23:10:51 2007
From: report at bugs.python.org (anilj)
Date: Tue, 09 Oct 2007 21:10:51 -0000
Subject: [New-bugs-announce] [issue1250] Building external modules using Sun
	Studio 12
Message-ID: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za>


New submission from anilj:

When compiling matplotlib, ditutils defaults to using
/opt/SUNWspro/bin/cc but it needs to use /opt/SUNWspro/bin/CC for
compiling c++ files.

% python2.5 setup.py build
building for GTK requires pygtk; you must be able to "import gtk" in
your build/install environmentTKAgg requires TkInter
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc ->
build/lib.solaris-2.10-i86pc-2.5/matplotlib/mpl-data
running build_ext
building 'matplotlib._agg' extension
/opt/SUNWspro/bin/cc -DNDEBUG -O -fast -xipo -xtarget=opteron -Kpic
-Iagg23/include -Isrc -Iswig -I/usr/local/include/python2.5 -c
src/agg.cxx -o build/temp.solaris-2.10-i86pc-2.5/src/agg.o
cc: No input file specified, no output generated
error: command '/opt/SUNWspro/bin/cc' failed with exit status 1


% python2.5 setup.py build --help-compiler
building for GTK requires pygtk; you must be able to "import gtk" in
your build/install environmentTKAgg requires TkInter
List of available compilers:
  --compiler=bcpp     Borland C++ Compiler
  --compiler=cygwin   Cygwin port of GNU C Compiler for Win32
  --compiler=emx      EMX port of GNU C Compiler for OS/2
  --compiler=mingw32  Mingw32 port of GNU C Compiler for Win32
  --compiler=msvc     Microsoft Visual C++
  --compiler=mwerks   MetroWerks CodeWarrior
  --compiler=unix     standard UNIX-style compiler


Doesn't look like I can override the default compiler using the above
options.

Thanks.

----------
components: Distutils
messages: 56293
nosy: anilj
severity: normal
status: open
title: Building external modules using Sun Studio 12
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct 10 00:48:18 2007
From: report at bugs.python.org (Chris Stawarz)
Date: Tue, 09 Oct 2007 22:48:18 -0000
Subject: [New-bugs-announce] [issue1251] ssl module doesn't support
	non-blocking handshakes
Message-ID: <1191970098.04.0.2942232647.issue1251@psf.upfronthosting.co.za>


New submission from Chris Stawarz:

The current version of the ssl module doesn't support non-blocking
creation of SSLSocket objects.  The reason for this is that the SSL
handshaking (SSL_connect/SSL_accept) takes place during the
construction of the SSLContext object (in newPySSLObject).  This means
that if the socket being wrapped is non-blocking, and the handshake
fails with SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE, then the entire
SSLContext is scrapped, and newPySSLObject must be run again in its
entirety.  Unfortunately, restarting from scratch on the same socket
appears to confuse the remote host, and the new attempt fails.

The attached patch fixes this problem by removing the handshaking code
from newPySSLObject and adding a do_handshake method to SSLContext.
It also adds a new parameter (do_handshake_on_connect) to the
SSLSocket constructor and the wrap_socket function.  The default value
of the parameter is True, which preserves the current behavior of the
module by immediately calling do_handshake after sslwrap.  If
do_handshake_on_connect is set to False, then the caller is
responsible for calling do_handshake.  This allows code that uses
non-blocking sockets to first create the SSLSocket and then
iteratively call do_handshake and select.select until the process
completes (which is exactly how non-blocking reads and writes are
handled).

----------
components: Documentation, Library (Lib), Tests
files: ssl_nonblocking_handshake_patch.txt
messages: 56295
nosy: chris.stawarz
severity: normal
status: open
title: ssl module doesn't support non-blocking handshakes
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1251>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssl_nonblocking_handshake_patch.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071009/6af5321f/attachment.txt 

From report at bugs.python.org  Wed Oct 10 04:06:52 2007
From: report at bugs.python.org (Tal Einat)
Date: Wed, 10 Oct 2007 02:06:52 -0000
Subject: [New-bugs-announce] [issue1252] IDLE - patch Delegator to support
	callables
Message-ID: <1191982010.97.0.724994014869.issue1252@psf.upfronthosting.co.za>


New submission from Tal Einat:

Add an __call__ magic method to Delegator so that it can delegate to
callables. This will raise the required exception if the delegate isn't
callable.

The built-in callable() method will now return True for any Delegator.
Before this patch it always returns False, which is wrong if the
delegate is callable, so callable() doesn't really work on Delegator
instances in both cases. I couldn't see how this could be harmful.

Also make the Delegator class a new-style class.


This patch is required for the Squeezer and ShellLogger IDLE extensions
found on PyPI to be able to co-exist.

----------
components: IDLE
files: IDLE_Delegator.071010.patch
messages: 56305
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - patch Delegator to support callables
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1252>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_Delegator.071010.patch
Type: application/octet-stream
Size: 639 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071010/7af481a2/attachment.obj 

From report at bugs.python.org  Wed Oct 10 04:17:04 2007
From: report at bugs.python.org (Tal Einat)
Date: Wed, 10 Oct 2007 02:17:04 -0000
Subject: [New-bugs-announce] [issue1253] IDLE - Percolator overhaul
Message-ID: <1191982624.13.0.198270020748.issue1253@psf.upfronthosting.co.za>


New submission from Tal Einat:

The Percolator class has been very hard to figure out, and has been a
source of confusion for users wanting to "hack" IDLE.

This patch makes Percolator a generally useful class which inherits from
Delegator. It also adds a new class, TkTextPercolator, which inherits
from Percolator and does all of the Text widget specific stuff.

The code has been refactored, cleaned up, and the in-code comments have
been improved. UndoDelegator.py, ColorDelegator.py and EditorWindow.py
have been updated as needed.

Also, the code using ColorDelegator in EditorWindow.py has been slightly
modified to work better with the Percolator.

I've done some testing (only on WinXP but nothing here is platform
specific) and this seems to work without a hitch.

This patch is required for the Squeezer and ShellLogger IDLE extensions
found on PyPI to be able to co-exist.

----------
components: IDLE
files: IDLE_Percolator.071010.patch
messages: 56306
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Percolator overhaul
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1253>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_Percolator.071010.patch
Type: application/octet-stream
Size: 8896 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071010/c1395c12/attachment-0001.obj 

From report at bugs.python.org  Wed Oct 10 16:02:30 2007
From: report at bugs.python.org (Romain JACQUET)
Date: Wed, 10 Oct 2007 14:02:30 -0000
Subject: [New-bugs-announce] [issue1254] pdb fails to launch some script.
Message-ID: <1192024950.07.0.645250068829.issue1254@psf.upfronthosting.co.za>


New submission from Romain JACQUET:

Pdb fails to launch any scripts that uses the __file__ builtin.
This problem occurs because pdb does not set the global environnement
correctly.

It can be corrected by setting the global variable __file__ before pdb
executes the file.

Lib/pdb.py:
Replace : globals_ = {"__name__" : "__main__"} 
by: globals_ = {"__name__" : "__main__", "__file__": filename}

The problem happens also in python 2.5.

----------
components: Library (Lib)
files: bug.py
messages: 56312
nosy: romain_jacquet
severity: normal
status: open
title: pdb fails to launch some script.
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1254>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.py
Type: text/x-python
Size: 753 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071010/a9e1a979/attachment.py 

From report at bugs.python.org  Wed Oct 10 16:10:05 2007
From: report at bugs.python.org (Jiri Krivanek)
Date: Wed, 10 Oct 2007 14:10:05 -0000
Subject: [New-bugs-announce] [issue1255] Strange Python hangup
Message-ID: <1192025405.81.0.160567416704.issue1255@psf.upfronthosting.co.za>


New submission from Jiri Krivanek:

See please attached ZIP archive which contains the two simple example
source codes.

If you execute bb.py, let it running for a while and then press Ctrl+C
then the Python will terminate safely and you will get the following
output on your console:

E:\KkWebrman\Instalace\Tmp>bb.py
init
parsing time...
...done
started
parsing time...
...done
parsing time...
...done
finishing
done

E:\KkWebrman\Instalace\Tmp>

However, if you execute aa.py then it will not terminate by Ctrl+C and
you will get the following output on your console:

E:\KkWebrman\Instalace\Tmp>aa.py
init
parsing time...
started
finishing

The aa.py simply imports bb.

My OS is: MS Windows 2000.

My Python version is: Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC
v.1310 32 bit (Intel)] on win32

----------
components: Interpreter Core, Library (Lib)
files: Python24Error.zip
messages: 56313
nosy: kakacek
severity: urgent
status: open
title: Strange Python hangup
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1255>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python24Error.zip
Type: application/octet-stream
Size: 498 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071010/ff3b1c97/attachment.obj 

From report at bugs.python.org  Wed Oct 10 19:41:49 2007
From: report at bugs.python.org (superwesman)
Date: Wed, 10 Oct 2007 17:41:49 -0000
Subject: [New-bugs-announce] [issue1256] subprocess Popen wait() function
	hangs when stdout is > 20480
Message-ID: <1192038109.59.0.704801934631.issue1256@psf.upfronthosting.co.za>


New submission from superwesman:

hi - I noticed some odd behaviour with subprocess when the output
(stdout) is large - I did some sleuthing and found a reproduceable case
- I tested this on solaris using python 2.4.2 (sparc) and using 2.5
(opteron) - I've attached a python script that details the problem - I
created 2 files ("small_file" and "large_file") that are 20480 and 20481
bytes, respectively ....

> ls -lrt ./tmp/*_file
-rw-r--r--   1 wtorres  staff      20481 Oct 10 12:32 ./tmp/large_file
-rw-r--r--   1 wtorres  staff      20480 Oct 10 12:32 ./tmp/small_file

the script cats each file, thus generating an appropriately sized stdout
- the workaround we came up with was to use our own file handle and use
the parameter stdout=my_file_handle.fileno() instead of stdout=PIPE -
you can see this in the attached example as well

> python ./tmp/brent.py 
testing with a small file - these should both work
using my own file handle .... ok
using PIPE ... ok
testing with a large file - the second one here should fail
using my own file handle .... ok
using PIPE ...
Traceback (most recent call last):
  File "./tmp/brent.py", line 43, in ?
    test_popen_bug( large_file )
  File "./tmp/brent.py", line 31, in test_popen_bug
    rc = my_popen.wait()
  File "/tools/python/2.4.2/solaris/lib/python2.4/subprocess.py", line
1007, in wait
    pid, sts = os.waitpid(self.pid, 0)
KeyboardInterrupt

based on all this, it seems that the PIPE file handle has some buffer or
something that is filling up and not allowing us to continue... or
something.  Thoughts?
-w

----------
components: None
files: brent.py
messages: 56317
nosy: superwesman
severity: normal
status: open
title: subprocess Popen wait() function hangs when stdout is > 20480
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1256>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brent.py
Type: application/octet-stream
Size: 1298 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071010/4d4cdade/attachment.obj 

From report at bugs.python.org  Wed Oct 10 21:56:26 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Robert_Brewer=0A=09=09=09=09?=)
Date: Wed, 10 Oct 2007 19:56:26 -0000
Subject: [New-bugs-announce] [issue1257] atexit errors should result in
	nonzero exit code
Message-ID: <1192046186.55.0.804669715206.issue1257@psf.upfronthosting.co.za>


New submission from 
					Robert Brewer
				:

While debugging/fixing the logging module's atexit behavior (see
http://www.cherrypy.org/ticket/646 -- it chokes atexit if stdout is
closed), it became difficult to write an automated test that verified
the bug occurred, since it happened at program exit. Returning a nonzero
exit code when atexit errors occur would be preferable to just printing
the error. Of course, if SystemExit is already raised, we should
propagate that out, but other exceptions should print the traceback and
then return some other code IMO.

----------
components: Interpreter Core
messages: 56323
nosy: aminusfu
severity: normal
status: open
title: atexit errors should result in nonzero exit code
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Wed Oct 10 23:23:32 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 10 Oct 2007 21:23:32 -0000
Subject: [New-bugs-announce] [issue1258] Removal of basestring type
Message-ID: <1192051411.91.0.780062722344.issue1258@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch removes the basestring type from Python 3.0. PyString and
PyUnicode are subclasses of PyBaseObject_Type. Each occurrence of
basestring was replaces with str, mostly isinstance(egg, basestring)
with a few exceptions. PyObject_TypeCheck(args, &PyBaseString_Type) is
replaced with a check for PyUnicode and PyString.

----------
components: Interpreter Core
files: py3k_basestring_removal.patch
messages: 56326
nosy: tiran
severity: normal
status: open
title: Removal of basestring type
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1258>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_basestring_removal.patch
Type: text/x-diff
Size: 61579 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071010/c6f01d93/attachment-0001.patch 

From report at bugs.python.org  Thu Oct 11 01:41:29 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Robert_Collins=0A=09=09=09=09?=)
Date: Wed, 10 Oct 2007 23:41:29 -0000
Subject: [New-bugs-announce] [issue1259] string find and rfind methods give
	a TypeError that is misleading
Message-ID: <1192059689.8.0.690640268578.issue1259@psf.upfronthosting.co.za>


New submission from 
					Robert Collins
				:

Python 2.5.1 (r251:54863, May  2 2007, 16:56:35) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 'asd'.find('s', None, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__
method
>>> 'asd'.rfind('s', None, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__
method
>>> # Note that this works, at the price of a memory copy,
>>> # and on large strings that is undesirable.
>>> 'asd'[None:None].find('s')
1
>>> 'asd'[None:None].rfind('s')
1
>>>

----------
messages: 56332
nosy: rbcollins
severity: normal
status: open
title: string find and rfind methods give a TypeError that is misleading
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 11 05:00:27 2007
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 11 Oct 2007 03:00:27 -0000
Subject: [New-bugs-announce] [issue1260] PEP 3137: Remove the buffer API
	from PyUnicode
Message-ID: <1192071626.91.0.943640538165.issue1260@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

This patch removes the buffer API from PyUnicode, as specified by PEP
3137. All the unit tests passes. However, I believe there is a few
function calls to PyArg API that could become problematic if they are
given a PyUnicode object:

  % egrep -R --include='*.c' 'PyArg.*Parse.*"[^;:]*[cwt].*"' py3k/

I haven't checked these function calls yet. So, it would probably be a
good idea to wait I do so before committing this patch.

----------
files: unicode_rm_buf_api.patch
messages: 56336
nosy: alexandre.vassalotti
severity: normal
status: open
title: PEP 3137: Remove the buffer API from PyUnicode
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1260>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unicode_rm_buf_api.patch
Type: text/x-diff
Size: 1890 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071011/2fd04a35/attachment.patch 

From report at bugs.python.org  Thu Oct 11 10:45:44 2007
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 11 Oct 2007 08:45:44 -0000
Subject: [New-bugs-announce] [issue1261] PEP 3137: make bytesobject.c
	methods use PEP 3118 buffer API
Message-ID: <1192092343.97.0.94438121325.issue1261@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

This makes all existing bytesobject.c methods use the buffer API rather
than explicitly requiring bytes objects as input.  It also fixes input
to append() and remove() that was not strict enough and improves a few
unit tests in that area.

NOTE: this patch likely depends on http://bugs.python.org/issue1260
removing the buffer API from the unicode type in order for all unit
tests to pass (i only tested it with that applied since thats where
we're headed).

----------
files: bytes-methods-use-buffer-api-01.diff.txt
keywords: patch, py3k
messages: 56341
nosy: gregory.p.smith
severity: normal
status: open
title: PEP 3137: make bytesobject.c methods use PEP 3118 buffer API
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1261>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bytes-methods-use-buffer-api-01.diff.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071011/6feed221/attachment.txt 

From report at bugs.python.org  Thu Oct 11 13:30:38 2007
From: report at bugs.python.org (Reto Wehrli)
Date: Thu, 11 Oct 2007 11:30:38 -0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue1262=5D_IDLE_does_not_start?=
	=?utf-8?q?_if_windows_environment_variable_containing_=27German_Um?=
	=?utf-8?b?bGF1dGU6IMOkw7bDvCcgZXhpc3Rz?=
Message-ID: <1192102237.9.0.369599220332.issue1262@psf.upfronthosting.co.za>


New submission from Reto Wehrli:

C:\devtools\Python30\Lib\idlelib>set
...
eRoomOfflineFiles=Z:\Documents and Settings\tgdwere3\My Documents\eRoom
Dateien
f?r die Offline-Bearbeitung\
...

C:\devtools\Python30\Lib\idlelib>..\..\python.exe idle.pyw
object  : UnicodeDecodeError('utf8', b'Z:\\Documents and
Settings\\tgdwere3\\My
Documents\\eRoom Dateien f\xfcr die Offline-Bearbeitung\\', 63, 69, 'u
nsupported Unicode code range')
type    : UnicodeDecodeError
refcount: 4
address : 00B825B0
lost sys.stderr

after removing the env variable idle starts

----------
components: IDLE
messages: 56342
nosy: reto
severity: normal
status: open
title: IDLE does not start if windows environment variable containing 'German Umlaute: ???' exists
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Thu Oct 11 14:20:47 2007
From: report at bugs.python.org (Thomas Lee)
Date: Thu, 11 Oct 2007 12:20:47 -0000
Subject: [New-bugs-announce] [issue1263] PEP 3137 patch - str8/str
	comparison should return false
Message-ID: <1192105247.69.0.759609123255.issue1263@psf.upfronthosting.co.za>


New submission from Thomas Lee:

The main patch - while exactly what is needed to make str8/str equality
checks return False - breaks a bunch of tests due to PyString_* still
being used elsewhere when it should be using PyUnicode.

The second patch modifies structmember.c to use PyUnicode_* where it was
previously using PyString_*, which fixes the first problem I stumbled
across in trying to get test_unicode to run.

Unfortunately, similar errors are present in Python/codecs.c and other
places (maybe Python/modsupport.c too? not 100% sure yet) - these still
need to be fixed!

----------
components: Interpreter Core
files: unicode-string-eq-false-r2.patch
messages: 56343
nosy: thomas.lee
severity: normal
status: open
title: PEP 3137 patch - str8/str comparison should return false
type: rfe
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1263>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unicode-string-eq-false-r2.patch
Type: text/x-patch
Size: 1953 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071011/5547548e/attachment.bin 

From report at bugs.python.org  Thu Oct 11 17:49:25 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Oct 2007 15:49:25 -0000
Subject: [New-bugs-announce] [issue1264] __file__ and co_filename as unicode
Message-ID: <1192117764.73.0.471656029437.issue1264@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This is a *preliminary* patch for __file__ and co_filename which decodes
char* / PyString using the FS default encoding. I'm still working on it.

----------
components: Interpreter Core
files: py3k_file_fsenc.patch
messages: 56345
nosy: tiran
severity: normal
status: open
title: __file__ and co_filename as unicode
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1264>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_file_fsenc.patch
Type: text/x-diff
Size: 6323 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071011/0ed43947/attachment.patch 

From report at bugs.python.org  Thu Oct 11 18:00:52 2007
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 11 Oct 2007 16:00:52 -0000
Subject: [New-bugs-announce] [issue1265] pdb bug with "with" statement
Message-ID: <1192118452.75.0.65576179893.issue1265@psf.upfronthosting.co.za>


New submission from Christian Heimes:

found a pretty annoying bug caused by with blocks. A with block
terminates the debugging session and the program keeps running. It's not
possible to go to the next line with 'n'. 's' steps into the open() call.

# pdbtest.py
import pdb
pdb.set_trace()
print("before with")
with open("/etc/passwd") as fd:
    data = fd.read()
print("after with")
print("end of program")

$ ./python pdbtest.py
> /home/heimes/dev/python/py3k/pdbtest.py(3)<module>()
-> print("before with")
(Pdb) n
before with
> /home/heimes/dev/python/py3k/pdbtest.py(4)<module>()
-> with open("/etc/passwd") as fd:
(Pdb) n
after with
end of program

----------
components: Interpreter Core, Library (Lib)
messages: 56346
nosy: tiran
severity: normal
status: open
title: pdb bug with "with" statement
versions: Python 3.0

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

From report at bugs.python.org  Thu Oct 11 20:14:44 2007
From: report at bugs.python.org (Thorben)
Date: Thu, 11 Oct 2007 18:14:44 -0000
Subject: [New-bugs-announce] [issue1266] segfault in curses when calling
	redrawwin() before refresh()
Message-ID: <1192126484.51.0.25368750134.issue1266@psf.upfronthosting.co.za>


New submission from Thorben:

attached file makes python 2.5.1 segfault

----------
components: Library (Lib)
files: curses-01.py
messages: 56348
nosy: Thorben
severity: critical
status: open
title: segfault in curses when calling redrawwin() before refresh()
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1266>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: curses-01.py
Type: text/x-python
Size: 157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071011/497880bc/attachment.py 

From report at bugs.python.org  Fri Oct 12 01:02:39 2007
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 11 Oct 2007 23:02:39 -0000
Subject: [New-bugs-announce] [issue1267] Py3K cannot run as ``python -S``
Message-ID: <1192143759.73.0.716718415917.issue1267@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If Py3K is executed without importing site, it fails horribly.  This is
because site.py sets __builtins__.open, sys.stdout, sys.stderr, and
sys.stdin.

The setting of sys.stderr is especially bad as exception printing
requires sys.stderr, otherwise it reports that sys.stderr was lost. 
This prevents debugging any exceptions thrown when site.py isn't/can't
be imported (e.g., trying to debug bootstrapping importlib).

----------
components: Interpreter Core
keywords: py3k
messages: 56350
nosy: brett.cannon
severity: normal
status: open
title: Py3K cannot run as ``python -S``
versions: Python 3.0

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

From report at bugs.python.org  Fri Oct 12 05:10:48 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Oct 2007 03:10:48 -0000
Subject: [New-bugs-announce] [issue1268] array unittest problems with UCS4
	build
Message-ID: <1192158648.5.0.179668399301.issue1268@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The array module is using a different typecode for unicode array
depending on UCS2 or UCS4:

#define Py_UNICODE_SIZE 4

#if Py_UNICODE_SIZE >= 4
#define Py_UNICODE_WIDE
#endif

#ifdef Py_UNICODE_WIDE
#define PyArr_UNI 'w'
#define PyArr_UNISTR "w"
#else
#define PyArr_UNI 'u'
#define PyArr_UNISTR "u"
#endif

It's causing a bunch of unit test to fail which depend on 'u' as the
type code for an unicode array. I don't see the benefit from specifying
an alternative typecode for wide unicode arrays. It may be useful to
have an additional typecode that fails for UCS-2 builds.

My patch keeps 'u' in every build and adds 'w' as an alias for 'u' in
UCS-4 builds only. It also introduces the new module variable typecodes
which is a unicode string containing all valid typecodes.

----------
components: Extension Modules
files: py3k_array_typecode.patch
messages: 56353
nosy: tiran
severity: normal
status: open
title: array unittest problems with UCS4 build
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1268>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_array_typecode.patch
Type: text/x-diff
Size: 8188 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071012/ea9165dd/attachment-0001.patch 

From report at bugs.python.org  Fri Oct 12 09:14:22 2007
From: report at bugs.python.org (Andrew Stromnov)
Date: Fri, 12 Oct 2007 07:14:22 -0000
Subject: [New-bugs-announce] [issue1269] Exception in pstats print_callers()
Message-ID: <1192173262.83.0.27550877069.issue1269@psf.upfronthosting.co.za>


New submission from Andrew Stromnov:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pstats
>>> ps = pstats.Stats("profile.log")
>>> ps.add("profile.log")
<pstats.Stats instance at 0x01358BC0>
>>> ps.print_callers()
   Random listing order was used

{method 'append' of 'list' objects}                                    
           <-
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python25\lib\pstats.py", line 388, in print_callers
    self.print_call_line(width, func, callers, "<-")
  File "C:\Python25\lib\pstats.py", line 417, in print_call_line
    nc, cc, tt, ct = value
ValueError: too many values to unpack

----------
components: Library (Lib)
files: profile.log
messages: 56358
nosy: stromnov
severity: normal
status: open
title: Exception in pstats print_callers()
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1269>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profile.log
Type: application/octet-stream
Size: 2733 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071012/57b7f71c/attachment.obj 

From report at bugs.python.org  Fri Oct 12 12:02:24 2007
From: report at bugs.python.org (Andre M. Descombes)
Date: Fri, 12 Oct 2007 10:02:24 -0000
Subject: [New-bugs-announce] [issue1270] MemoryError when working on large
	dictionaries on Windows 2003 Server
Message-ID: <1192183344.18.0.434949656884.issue1270@psf.upfronthosting.co.za>


New submission from Andre M. Descombes:

Hi everybody,

I am using Python 2.5.1.
I am creating a rather large dictionnary, with more than 8 million
entries, memory usage should be about 1.5GB. If I run the program on
Windows XP all runs fine, if I run the program on Windows Server 2003 I
start getting MemoryError exceptions around the 1GB boundary.
Is there a known issue with Windows 2003 Server?

Thanks,

Andr? M. Descombes

----------
components: Interpreter Core
messages: 56361
nosy: amdescombes
severity: critical
status: open
title: MemoryError when working on large dictionaries on Windows 2003 Server
type: resource usage
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 12 14:52:37 2007
From: report at bugs.python.org (Tim Gordon)
Date: Fri, 12 Oct 2007 12:52:37 -0000
Subject: [New-bugs-announce] [issue1271] Raw string parsing fails with
	backslash as last character
Message-ID: <1192193557.25.0.892687713719.issue1271@psf.upfronthosting.co.za>


New submission from Tim Gordon:

If you have a raw string with a backslash as the last character, the 
parser thinks the following quote, actually used to mark the end of the 
string, is being quoted by the backslash.  For example, r'\' should be 
the string with one backslash, but...

>>> print r'\'
SyntaxError: EOL while scanning single-quoted string

There seems to have been a fix added to python 3.0 (see issue 1720390), 
but it doesn't look like it's been backtracked into any earlier version.

----------
components: Interpreter Core
messages: 56370
nosy: QuantumTim
severity: normal
status: open
title: Raw string parsing fails with backslash as last character
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Fri Oct 12 15:41:38 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 12 Oct 2007 13:41:38 -0000
Subject: [New-bugs-announce] [issue1272] Decode __file__ and co_filename to
	unicode using fs default
Message-ID: <1192196498.75.0.195670929774.issue1272@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I'm sending the patch in for review.

----------
components: Interpreter Core
files: py3k_file_fsenc2.patch
messages: 56374
nosy: tiran
severity: normal
status: open
title: Decode __file__ and co_filename to unicode using fs default
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1272>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_file_fsenc2.patch
Type: text/x-diff
Size: 9342 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071012/32dd9344/attachment.patch 

From report at bugs.python.org  Fri Oct 12 18:03:19 2007
From: report at bugs.python.org (Ed Vinyard)
Date: Fri, 12 Oct 2007 16:03:19 -0000
Subject: [New-bugs-announce] [issue1273] email module example
	email-unpack.py error
Message-ID: <1192204998.94.0.0490108270822.issue1273@psf.upfronthosting.co.za>


New submission from Ed Vinyard:

In the email module example, email-unpack.py
(http://docs.python.org/lib/email-unpack.txt), line 56 throws an
AttributeError.  It is currently

    ext = mimetypes.guess_extension(part.get_type())

I think this line should be

    ext = mimetypes.guess_extension(part.get_content_type())

The Message documentation
(http://docs.python.org/lib/module-email.message.html) mentions that
"Changed in version 2.5: The previously deprecated methods get_type(),
get_main_type(), and get_subtype() were removed."

----------
components: Documentation
messages: 56376
nosy: esv
severity: minor
status: open
title: email module example email-unpack.py error
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 12 21:20:02 2007
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 12 Oct 2007 19:20:02 -0000
Subject: [New-bugs-announce] [issue1275] bsddb closing a DB object before
	all DBCursors using it are closed crashes
Message-ID: <1192216802.58.0.956972286502.issue1275@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

If a bsddb.db.DB object is closed before any DBCursor objects
referencing it are closed, python will crash when the cursors are closed
or deleted.

Workaround: never close a database with open cursors.  this is annoying
in unittest code where a tearDown method closes the DB in the exception
handling path on a test failure before the cursors have been closed or
garbage collected.

I've got a test in my sandbox, I'll check it in with the fix as its a
crasher otherwise.

----------
assignee: gregory.p.smith
components: Extension Modules
messages: 56383
nosy: gregory.p.smith
severity: normal
status: open
title: bsddb closing a DB object before all DBCursors using it are closed crashes
type: crash

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

From report at bugs.python.org  Sat Oct 13 12:07:09 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09jos=0A=09=09=09=09?=)
Date: Sat, 13 Oct 2007 10:07:09 -0000
Subject: [New-bugs-announce] [issue1276] LookupError: unknown encoding:
	X-MAC-JAPANESE
Message-ID: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za>


New submission from 
					jos
				:

When I compile Python-3.0a1 on Mac OS X with Japanese locale,
I've got LookupError like below.

==========================================
running build_scripts
creating build/scripts-3.0
Traceback (most recent call last):
  File "./setup.py", line 1572, in <module>
    main()
  File "./setup.py", line 1567, in main
    'Lib/smtpd.py']
  File "/private/tmp/Python-3.0a1/Lib/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 943, in
run_commands
    self.run_command(cmd)
  File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 963, in
run_command
    cmd_obj.run()
  File "/private/tmp/Python-3.0a1/Lib/distutils/command/build.py", line
106, in run
    self.run_command(cmd_name)
  File "/private/tmp/Python-3.0a1/Lib/distutils/cmd.py", line 317, in
run_command
    self.distribution.run_command(command)
  File "/private/tmp/Python-3.0a1/Lib/distutils/dist.py", line 963, in
run_command
    cmd_obj.run()
  File
"/private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py", line
51, in run
    self.copy_scripts()
  File
"/private/tmp/Python-3.0a1/Lib/distutils/command/build_scripts.py", line
82, in copy_scripts
    first_line = f.readline()
  File "/private/tmp/Python-3.0a1/Lib/io.py", line 1259, in readline
    decoder = self._decoder or self._get_decoder()
  File "/private/tmp/Python-3.0a1/Lib/io.py", line 1111, in _get_decoder
    make_decoder = codecs.getincrementaldecoder(self._encoding)
  File "/private/tmp/Python-3.0a1/Lib/codecs.py", line 951, in
getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: X-MAC-JAPANESE
make: *** [sharedmods] Error 1
==========================================

This problem happens for lack of appropriate codec
so also occurs in apps using getdefaultencoding.

After patching Tools/unicode/Makefile and
running make generates build/mac_japanese.py, mac-japanese codec.

----------
components: Build, Demos and Tools, Library (Lib), Macintosh, Unicode
files: x_mac_japanese.diff
messages: 56386
nosy: josm
severity: normal
status: open
title: LookupError: unknown encoding: X-MAC-JAPANESE

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x_mac_japanese.diff
Type: application/octet-stream
Size: 413 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071013/ce915c1f/attachment.obj 

From report at bugs.python.org  Sun Oct 14 18:02:43 2007
From: report at bugs.python.org (Bernd Wurst)
Date: Sun, 14 Oct 2007 16:02:43 -0000
Subject: [New-bugs-announce] [issue1277] mailbox.Maildir: factory not used
Message-ID: <1192377763.05.0.280093607923.issue1277@psf.upfronthosting.co.za>


New submission from Bernd Wurst:

The "factory"-argument to the constructorof mailbox.Maildir is not 
used as it should be.

First, it's default is set to rfc822.Message instead of MaildirMessage 
and then, inside the module's code, MaildirMessage is hard-coded as a 
message constructor.

If I need a derived class with custom attributes, I cannot use it.

----------
components: Extension Modules
messages: 56418
nosy: bwurst
severity: normal
status: open
title: mailbox.Maildir: factory not used
type: resource usage
versions: Python 2.5

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

From report at bugs.python.org  Mon Oct 15 03:34:28 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 15 Oct 2007 01:34:28 -0000
Subject: [New-bugs-announce] [issue1278] imp.find_module() ignores -*-
	coding: Latin-1 -*-
Message-ID: <1192412068.91.0.486789183864.issue1278@psf.upfronthosting.co.za>


New submission from Christian Heimes:

imp.find_module() returns an io.TextIOWrapper instance first value. The
encoding of the TextIOWrapper isn't set from a -*- coding: Latin-1 -*- line.

>>> import imp
>>> imp.find_module("heapq")
(<io.TextIOWrapper object at 0xb7c8f50c>,
'/home/heimes/dev/python/py3k/Lib/heapq.py', ('.py', 'U', 1))
>>> imp.find_module("heapq")[0].read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/heimes/dev/python/py3k/Lib/io.py", line 1224, in read
    res += decoder.decode(self.buffer.read(), True)
  File "/home/heimes/dev/python/py3k/Lib/codecs.py", line 291, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position
1428-1430: invalid data
>>> imp.find_module("heapq")[0].encoding
'UTF-8'
>>> imp.find_module("heapq")[0].readline()
'# -*- coding: Latin-1 -*-\n'

----------
components: Interpreter Core
messages: 56431
nosy: tiran
severity: normal
status: open
title: imp.find_module() ignores -*- coding: Latin-1 -*-
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct 15 15:12:56 2007
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Mon, 15 Oct 2007 13:12:56 -0000
Subject: [New-bugs-announce] [issue1279] os.system() oddity under Windows XP
	SP2
Message-ID: <1192453976.49.0.177979344354.issue1279@psf.upfronthosting.co.za>


New submission from Stefan Sonnenberg-Carstens:

When doing such
os.system("a command wich writes a outfile")
f = open("the file the command before wrote")

the file is empty.

If I do this:

os.popen("a command wich writes a outfile")
f = open("the file the command before wrote")

everything is fine

----------
components: Interpreter Core
messages: 56439
nosy: pythonmeister
severity: major
status: open
title: os.system() oddity under Windows XP SP2
type: behavior
versions: Python 2.3

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

From report at bugs.python.org  Mon Oct 15 16:27:18 2007
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 15 Oct 2007 14:27:18 -0000
Subject: [New-bugs-announce] [issue1280] PEP 3137: Make PyString's indexing
	and iteration return integers
Message-ID: <1192458438.2.0.278920353598.issue1280@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

Here a preliminary patch to make PyString return integers on indexing
and iteration. There is still quite a few XXX in the patch, that I would
like to fix. However, the good thing is all tests passes.

----------
components: Interpreter Core
files: string_iter_ret_ints.patch
messages: 56442
nosy: alexandre.vassalotti
severity: normal
status: open
title: PEP 3137: Make PyString's indexing and iteration return integers
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1280>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string_iter_ret_ints.patch
Type: text/x-diff
Size: 12186 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071015/09fc34a4/attachment.patch 

From report at bugs.python.org  Mon Oct 15 21:26:02 2007
From: report at bugs.python.org (Ben Sherman)
Date: Mon, 15 Oct 2007 19:26:02 -0000
Subject: [New-bugs-announce] [issue1281] type in docutmentatio section
	14.3.3.4
Message-ID: <1192476362.59.0.198935696979.issue1281@psf.upfronthosting.co.za>


New submission from Ben Sherman:

"""
If, a little later on, "-tracks=4" is seen, it does:

options.tracks.append(int("4"))
"""

That should read --tracks=4, not -tracks=4

Found at
http://docs.python.org/lib/optparse-standard-option-actions.html

----------
components: Documentation
messages: 56460
nosy: bsherman
severity: normal
status: open
title: type in docutmentatio section 14.3.3.4
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 16 01:26:51 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 15 Oct 2007 23:26:51 -0000
Subject: [New-bugs-announce] [issue1282] re module needs to support bytes /
	memoryview well
Message-ID: <1192490811.67.0.131142181278.issue1282@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Once PEP 3137 is fully implemented, the re module needs to be fixed so
that the regex argument, the substitution argument, and the argument
being searched/replaced are allowed to be arbitrary bytes arrays; where
hashing is needed a copy in an immutable bytes object can be made.

----------
messages: 56472
nosy: gvanrossum
severity: normal
status: open
title: re module needs to support bytes / memoryview well
versions: Python 3.0

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

From report at bugs.python.org  Tue Oct 16 02:31:50 2007
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 16 Oct 2007 00:31:50 -0000
Subject: [New-bugs-announce] [issue1283] PyBytes (buffer) .extend method
	needs to accept any iterable of ints
Message-ID: <1192494710.42.0.243752942125.issue1283@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The PyBytes (pep3137 buffer) .extend() method currently only accepts as
input something supporting the pep3118 buffer API.  It also needs to
accept an iterable of ints in the 0..255 range.

----------
keywords: py3k
messages: 56478
nosy: gregory.p.smith
severity: normal
status: open
title: PyBytes (buffer) .extend method needs to accept any iterable of ints
versions: Python 3.0

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

From report at bugs.python.org  Tue Oct 16 03:07:10 2007
From: report at bugs.python.org (Eric Wollesen)
Date: Tue, 16 Oct 2007 01:07:10 -0000
Subject: [New-bugs-announce] [issue1284] typo in lib doc 7.3.2.1
	MaildirMessage
Message-ID: <1192496830.47.0.752456645031.issue1284@psf.upfronthosting.co.za>


New submission from Eric Wollesen:

get_subdir(  	)
    Return either "new" (if the message should be stored in the new
subdirectory) or "cur" (if the message should be stored in the cur
subdirectory). Note: A message is typically moved from new to cur after
its mailbox has been accessed, whether or not the message is has been
read. A message msg has been read if "S" not in msg.get_flags() is True. 

----

The last sentence above is incorrect.  The "not" should be removed.  It
should read:

A message msg has been read if "S" in msg.get_flags() is True.

----------
components: Documentation
messages: 56481
nosy: encoded
severity: minor
status: open
title: typo in lib doc 7.3.2.1 MaildirMessage
type: rfe
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 16 09:29:09 2007
From: report at bugs.python.org (Ulrich Weber)
Date: Tue, 16 Oct 2007 07:29:09 -0000
Subject: [New-bugs-announce] [issue1285] setp.py error "The process cannot
	access the file ..."
Message-ID: <1192519749.91.0.34801949524.issue1285@psf.upfronthosting.co.za>


New submission from Ulrich Weber:

When creating a windows installer using setup.py an error message is 
displayed: "error: c:\docume~1\uweber\loca1s~1\temp\tmppnj1gz .zip: The 
process cannot access the file because it is being used by another 
process". The installer is created nevertheless and seems to work fine. 
I am using Python 2.5.1 on WinXP SP2.

----------
components: Distutils
messages: 56496
nosy: uweber4711
severity: normal
status: open
title: setp.py error "The process cannot access the file ..."
type: behavior

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

From report at bugs.python.org  Tue Oct 16 13:59:57 2007
From: report at bugs.python.org (Yitz Gale)
Date: Tue, 16 Oct 2007 11:59:57 -0000
Subject: [New-bugs-announce] [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
Message-ID: <1192535997.09.0.645609216663.issue1286@psf.upfronthosting.co.za>


Changes by Yitz Gale:


----------
components: Extension Modules
nosy: ygale
severity: normal
status: open
title: fileinput, StringIO, and cStringIO do not support the with protocol
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Oct 16 19:55:10 2007
From: report at bugs.python.org (Gustavo Niemeyer)
Date: Tue, 16 Oct 2007 17:55:10 -0000
Subject: [New-bugs-announce] [issue1287] os.environ.pop doesn't work
Message-ID: <1192557310.97.0.899369581443.issue1287@psf.upfronthosting.co.za>


Changes by Gustavo Niemeyer:


----------
nosy: niemeyer
severity: normal
status: open
title: os.environ.pop doesn't work
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Oct 16 22:27:31 2007
From: report at bugs.python.org (Adam Doherty)
Date: Tue, 16 Oct 2007 20:27:31 -0000
Subject: [New-bugs-announce] [issue1288] dict.fromkeys - Odd logic when
	passing second dict.fromkeys as value
Message-ID: <1192566451.3.0.9845024568.issue1288@psf.upfronthosting.co.za>


New submission from Adam Doherty:

Hello:

I'm am trying to conduct some tests on a list of data that checks for
the position of values in list elements using the bisect module.  To
store the results of these tests for output to a template I have build a
dictionary with 47 keys the values of which are dictionaries themselves.
 These inner dictionaries contain 7 keys that initially are valued at
zero.  Looping through the data in my list I check for values from 1 to
47 and if I find the value I am looking for I lookup it's position in
the row using the bisect module.  Using the current value I am looking
for and the position returned from bisect I increase the value in the
matching dictionary key value position by 1. Now for speed I have built
the dictionary using d =
dict.fromkeys(xrange(1,48),dict.fromkeys(xrange(1,8),0)) as this gives
the desired result.  Unfortunately when I run my test for values each
value in the dictionary is listed as the total number of rows in the
data list.  This is not the desired result which is correctly achieved
using:
d = {}
for x in xrange(1,48):
    d[x] = dict.fromkeys(xrange(1,8),0)

I have included output from IDLE to demonstrate the problem.

----------
components: Interpreter Core
files: problem-report.txt
messages: 56507
nosy: dohertywa
severity: normal
status: open
title: dict.fromkeys - Odd logic when passing second dict.fromkeys as value
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1288>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: problem-report.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071016/bdd5f55a/attachment.txt 

From report at bugs.python.org  Thu Oct 18 03:06:05 2007
From: report at bugs.python.org (Nathan Haines)
Date: Thu, 18 Oct 2007 01:06:05 -0000
Subject: [New-bugs-announce] [issue1289] Typo in Context Manager Types
Message-ID: <1192669565.11.0.542171346949.issue1289@psf.upfronthosting.co.za>


New submission from Nathan Haines:

In the first sentence in the ContextManager.__exit__() section,
"exception" is spelled "expection".

----------
components: Documentation
messages: 56510
nosy: nhaines
severity: normal
status: open
title: Typo in Context Manager Types
type: rfe
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Oct 18 03:58:15 2007
From: report at bugs.python.org (Sharmila Sivakumar)
Date: Thu, 18 Oct 2007 01:58:15 -0000
Subject: [New-bugs-announce] [issue1290] xml.dom.minidom not able to handle
	utf-8 data
Message-ID: <1192672695.43.0.309092072224.issue1290@psf.upfronthosting.co.za>


New submission from Sharmila Sivakumar:

I try to load the data in the testdata.txt file into a dom.

I tried 
import xml.dom.minidom as dom
data = open('testdata.txt','r').read()
mydom = dom.parseString(data)
I get the following error

>>> mydom.firstChild.childNodes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2022' in 
position 18: ordinal not in range(128)


So I tried decoding the data and using it but it failed again.

>>> mydom2 = dom.parseString(data.decode('utf-8'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/_xmlplus/dom/minidom.py", line 
1925, in parseString
    return expatbuilder.parseString(string)
  File "/usr/lib/python2.5/site-packages/_xmlplus/dom/expatbuilder.py", 
line 942, in parseString
    return builder.parseString(string)
  File "/usr/lib/python2.5/site-packages/_xmlplus/dom/expatbuilder.py", 
line 223, in parseString
    parser.Parse(string, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u014d' in 
position 173: ordinal not in range(128)


I am willing to fix this myself if I'm given the permission.

----------
components: Interpreter Core, Unicode, XML
files: testdata.txt
messages: 56511
nosy: sharmila
severity: normal
status: open
title: xml.dom.minidom not able to handle utf-8 data
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file8558/testdata.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1290>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testdata.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071018/dc3ca282/attachment.txt 

From report at bugs.python.org  Thu Oct 18 11:13:42 2007
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 18 Oct 2007 09:13:42 -0000
Subject: [New-bugs-announce] [issue1291] test_resource fails on recent linux
	systems (
Message-ID: <1192698822.84.0.082608978163.issue1291@psf.upfronthosting.co.za>


New submission from Matthias Klose:

The test_resource test fails at least on all non x86 linux systems; the
test case notes:

# Now check to see what happens when the RLIMIT_FSIZE is small.  Some
# versions of Python were terminated by an uncaught SIGXFSZ, but
# pythonrun.c has been fixed to ignore that exception.  If so, the
# write() should return EFBIG when the limit is exceeded.

however instead of EFBIG errno is set to ESPIPE, causing an IOException.
and letting the test fail.

----------
components: Extension Modules
files: tst.c
messages: 56520
nosy: doko
severity: normal
status: open
title: test_resource fails on recent linux systems (
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8561/tst.c

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1291>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tst.c
Type: text/x-csrc
Size: 958 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071018/0f415ca4/attachment.c 

From report at bugs.python.org  Thu Oct 18 11:23:06 2007
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 18 Oct 2007 09:23:06 -0000
Subject: [New-bugs-announce] [issue1292] libffi needs an update to support
	mips64, arm and armeabi on linux
Message-ID: <1192699386.49.0.555660775493.issue1292@psf.upfronthosting.co.za>


New submission from Matthias Klose:

libffi needs an update to support mips64, arm and armeabi on linux; the
current bits are all available in GCC trunk. as an alternative, those
systems should be default to --with-system-ffi, unless this is
xplicitely disabled.

----------
assignee: theller
components: Extension Modules
messages: 56522
nosy: doko, theller
severity: normal
status: open
title: libffi needs an update to support mips64, arm and armeabi on linux
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 18 14:47:42 2007
From: report at bugs.python.org (Guillaume Girard)
Date: Thu, 18 Oct 2007 12:47:42 -0000
Subject: [New-bugs-announce] [issue1293] Trailing slash in sys.path cause
	import failure
Message-ID: <1192711662.66.0.399172727466.issue1293@psf.upfronthosting.co.za>


New submission from Guillaume Girard:

On win32, the following code:

import sys
sys.path.append('../bar/')
import bar

where the file bar.py is present in ../bar/ will return an import error
"No module named bar". Remove the trailing slash and the bar.py is
imported correctly. The problem is identical with backslash. This code
works in Python 2.4.

Not a very serious bug, but it breaks programs working with Python 2.4.

----------
components: Interpreter Core
messages: 56523
nosy: guillaumegirard
severity: minor
status: open
title: Trailing slash in sys.path cause import failure
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 18 14:51:56 2007
From: report at bugs.python.org (BULOT)
Date: Thu, 18 Oct 2007 12:51:56 -0000
Subject: [New-bugs-announce] [issue1294] Management of KeyboardInterrupt in
	cmd.py
Message-ID: <1192711916.5.0.235687394478.issue1294@psf.upfronthosting.co.za>


New submission from BULOT:

According to me, the Ctrl-C is not managed correctly in cmd.py. Ctrl-C
generates a a KeyboardInterrupt exceptions, and only EOFError is
managed. I propose to manage KeyboardInterrupt on line 130:
                               print 'are you sure you want to exit? y/n'
                                answer =''
                                while (answer != 'y') & (answer != 'n'):
                                        answer = raw_input()
                                if answer == 'y':
                                        exit(0)

Here is attached my new cmd.py
Hope ti will help.

----------
components: None
files: cmd.py
messages: 56524
nosy: stephbul
severity: normal
status: open
title: Management of KeyboardInterrupt in cmd.py
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8562/cmd.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmd.py
Type: text/x-python
Size: 15153 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071018/70d5c0e5/attachment.py 

From report at bugs.python.org  Thu Oct 18 17:30:36 2007
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Oct 2007 15:30:36 -0000
Subject: [New-bugs-announce] [issue1295] logging records cache the result of
	formatException()
Message-ID: <1192721436.77.0.0263561863659.issue1295@psf.upfronthosting.co.za>


New submission from Thomas Heller:

I needed two logging handlers in my application, one notifiying the user
of errors, the other writing errors to a logfile.  So I created a custom
subclass of logging.Formatter and redefined the formatException() method
that returned a summary of the exception like 'ZeroDivisionError'
instead of the full traceback.

Unfortunately the logging record caches the result of the
handler.formatException() call in the exc_text variable, and the
formatException() method of the second handler isn't called at all.

The attached patch removes the caching and fixes the problem.

----------
components: Library (Lib)
files: logging.patch
keywords: patch
messages: 56525
nosy: theller
severity: normal
status: open
title: logging records cache the result of formatException()
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8563/logging.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1295>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logging.patch
Type: text/x-patch
Size: 1109 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071018/78cc6184/attachment-0001.bin 

From report at bugs.python.org  Thu Oct 18 17:46:31 2007
From: report at bugs.python.org (Paul Melis)
Date: Thu, 18 Oct 2007 15:46:31 -0000
Subject: [New-bugs-announce] [issue1296] optparse's OptionGroup not described
Message-ID: <1192722391.31.0.57718526952.issue1296@psf.upfronthosting.co.za>


New submission from Paul Melis:

The current 2.5 documentation does not seem to describe the OptionGroup
feature of the optparse module.

In 2003 there was a patch submitted that added a section on OptionGroup (
http://bugs.python.org/issue697941). The issue entry mentions it was
accepted, but the current docs do not seem to contain that section.

----------
components: Documentation
messages: 56526
nosy: paulmelis
severity: normal
status: open
title: optparse's OptionGroup not described
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 18 19:06:17 2007
From: report at bugs.python.org (Nick)
Date: Thu, 18 Oct 2007 17:06:17 -0000
Subject: [New-bugs-announce] [issue1297] pyconfig.h not compatible with MS
	VC++ Express Edition
Message-ID: <1192727177.86.0.467865548072.issue1297@psf.upfronthosting.co.za>


New submission from Nick:

pyconfig.h checks for _MSC_VER and based on its value decides to include
<basetsd.h>.

MS VC++ Express reports _MSC_VER to be 1400 but does _NOT_ have the file
basetsd.h.

So when including Python.h with the Microsoft VC Express compiler,
pyconfig.h will try to include the non existing basetsd.h and compiling
fails.

----------
components: Build
messages: 56531
nosy: weegreenblobbie
severity: normal
status: open
title: pyconfig.h not compatible with MS VC++ Express Edition
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 18 19:14:11 2007
From: report at bugs.python.org (Lauri Alanko)
Date: Thu, 18 Oct 2007 17:14:11 -0000
Subject: [New-bugs-announce] [issue1298] Support for z/OS and EBCDIC.
Message-ID: <1192727651.25.0.882300002662.issue1298@psf.upfronthosting.co.za>


New submission from Lauri Alanko:

The attached patch, based on Jean-Yves Mengant's work, is against svn
head, and adds support for z/OS in particular, and non-ASCII platforms
in general. Further details are in a separate mail to python-dev, which
I will send shortly.

----------
components: Build, Distutils, Extension Modules, Interpreter Core, Library (Lib), Unicode
files: python-20071018-zos.patch
messages: 56532
nosy: lealanko
severity: normal
status: open
title: Support for z/OS and EBCDIC.
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file8564/python-20071018-zos.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-20071018-zos.patch
Type: text/x-patch
Size: 64199 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071018/2be713e8/attachment-0001.bin 

From report at bugs.python.org  Thu Oct 18 19:16:50 2007
From: report at bugs.python.org (Nick)
Date: Thu, 18 Oct 2007 17:16:50 -0000
Subject: [New-bugs-announce] [issue1299] distutils.sysconfig is not
	cross-platform compatible
Message-ID: <1192727810.38.0.522851261061.issue1299@psf.upfronthosting.co.za>


New submission from Nick:

I'm using scons (www.scons.org) and Python's distutils.sysconfig to
determine the correct compiler flags automatically to embed Python into
my C++ application.  I discovered that distuils.sysconfig is not fully
implemented on Windows.  Using distutils.sysconfg.get_config_var() or
get_config_vars() does not work on the Windows distribution.

The above calls will return values for INCLUDEPY LIBDIR LIB on Ubuntu
Linux, however, on Windows, these variables are not all declared.

These variables should be declared on all platforms so one can
automatically get the correct compiler flags needed to embed python in
one's C/C++ project.

----------
components: Build
messages: 56533
nosy: weegreenblobbie
severity: normal
status: open
title: distutils.sysconfig is not cross-platform compatible
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 18 19:40:54 2007
From: report at bugs.python.org (Andrew Moise)
Date: Thu, 18 Oct 2007 17:40:54 -0000
Subject: [New-bugs-announce] [issue1300] subprocess.list2cmdline doesn't do
	pipe symbols
Message-ID: <1192729254.96.0.285794085895.issue1300@psf.upfronthosting.co.za>


New submission from Andrew Moise:

I expected subprocess.list2cmdline() to convert my list of arguments
into a command line which results in behavior equivalent to the Unix
exec() functions -- that is, that I can safely pass arbitrary characters
to it and it'll make it such that those characters are escaped.  It
looks to me, though, like it doesn't handle the pipe symbol, so that if
I call list2cmdline(['echo', 'foo|bar']), I get the command line 'echo
foo|bar' instead of 'echo "foo|bar"' as I would expect.

If this is actually a result of my misunderstanding (or if it's fixed in
a more recent version), please accept my apologies.

----------
components: Windows
messages: 56534
nosy: chops at demiurgestudios.com
severity: normal
status: open
title: subprocess.list2cmdline doesn't do pipe symbols
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 19 01:26:25 2007
From: report at bugs.python.org (Stephen P. Schaefer)
Date: Thu, 18 Oct 2007 23:26:25 -0000
Subject: [New-bugs-announce] [issue1301] Bad assertion in _tkinter.c
Message-ID: <1192749985.07.0.719728900575.issue1301@psf.upfronthosting.co.za>


New submission from Stephen P. Schaefer:

The following fails with python 2.5 as built by Fedora 7:

t2.py:
import sys, Tkinter
Tkinter.Button(text=u"").pack( )
Tkinter.mainloop( )

$ python t2.py
python: ./Modules/_tkinter.c:941: AsObj: Assertion `size < size *
sizeof(Tcl_UniChar)' failed.
Aborted

The following patch corrects the problem:

--- Python-2.5-fc7/Modules/_tkinter.c   2006-08-11 22:33:36.000000000 -0400
+++ Python-2.5/Modules/_tkinter.c       2007-10-18 18:44:40.000000000 -0400
@@ -938,7 +938,7 @@
 #if defined(Py_UNICODE_WIDE) && TCL_UTF_MAX == 3
                Tcl_UniChar *outbuf;
                Py_ssize_t i;
-               assert(size < size * sizeof(Tcl_UniChar));
+               assert(size == 0 || size < size * sizeof(Tcl_UniChar));
                outbuf = (Tcl_UniChar*)ckalloc(size * sizeof(Tcl_UniChar));
                if (!outbuf) {
                        PyErr_NoMemory();

----------
components: Tkinter
messages: 56546
nosy: thyrsus
severity: normal
status: open
title: Bad assertion in _tkinter.c
versions: Python 2.5

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

From report at bugs.python.org  Sat Oct 20 00:18:02 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Oct 2007 22:18:02 -0000
Subject: [New-bugs-announce] [issue1302] Fixes for profile/cprofile
Message-ID: <1192832282.86.0.0922652821698.issue1302@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch fixes the output for profile and cProfile. Another patch from
Alexandre and me added additional calls to the UTF-8 codec.

----------
components: Library (Lib)
messages: 56569
nosy: gvanrossum, tiran
severity: normal
status: open
title: Fixes for profile/cprofile
versions: Python 3.0

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

From report at bugs.python.org  Sat Oct 20 00:44:50 2007
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Oct 2007 22:44:50 -0000
Subject: [New-bugs-announce] [issue1303] adapt str8 constructor to bytes
	constructor
Message-ID: <1192833890.07.0.771268986482.issue1303@psf.upfronthosting.co.za>


New submission from Georg Brandl:

This makes the str8 constructor accept the same kinds of types as the
bytes constructor. I had to fix instances of str8("abc") to str8(b"abc")
to make tests pass again. The only remaining failure should be test_str
-- the string test suite must be thoroughly redesigned to fit all three
string-like types.

----------
assignee: gvanrossum
components: Interpreter Core
files: str_constructor.diff
keywords: py3k
messages: 56572
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: adapt str8 constructor to bytes constructor
versions: Python 3.0
Added file: http://bugs.python.org/file8570/str_constructor.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1303>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: str_constructor.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071019/6836c4fe/attachment.txt 

From report at bugs.python.org  Sat Oct 20 00:59:21 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 19 Oct 2007 22:59:21 -0000
Subject: [New-bugs-announce] [issue1304] py3k compilation on Windows
Message-ID: <1192834761.88.0.529928768511.issue1304@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This patch is needed to have py3k compile on win32, since the
introduction of bytes_methods.c.
Also, use the recently re-added md5module.c and sha1module.c, because a
precompiled openssl library is difficult to obtain on Windows.

Note: I tested only with VS2005. I will watch the buildbots to verify
that compilation actually succeeds.

----------
components: Build, Windows
files: win32build.diff
messages: 56573
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k compilation on Windows
versions: Python 3.0
Added file: http://bugs.python.org/file8571/win32build.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1304>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32build.diff
Type: application/octet-stream
Size: 2798 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071019/798b5330/attachment.obj 

From report at bugs.python.org  Sat Oct 20 08:11:09 2007
From: report at bugs.python.org (andres)
Date: Sat, 20 Oct 2007 06:11:09 -0000
Subject: [New-bugs-announce] [issue1305] socket.py hangs on Mac OS X
Message-ID: <1192860669.18.0.477878627649.issue1305@psf.upfronthosting.co.za>


New submission from andres:

Repeated socket connection attempts hang for >2s on Python 2.5.1 & OS X 
10.4 after 250 attempts have been made.

----------
components: Library (Lib), Macintosh
files: sockettest.py
messages: 56601
nosy: andres
severity: normal
status: open
title: socket.py hangs on Mac OS X
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8576/sockettest.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1305>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sockettest.py
Type: text/x-python-script
Size: 408 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071020/c8eb4f75/attachment.bin 

From report at bugs.python.org  Sat Oct 20 15:35:10 2007
From: report at bugs.python.org (Karemir)
Date: Sat, 20 Oct 2007 13:35:10 -0000
Subject: [New-bugs-announce] [issue1306] Embedded python reinitialization
Message-ID: <1192887310.11.0.424828418654.issue1306@psf.upfronthosting.co.za>


New submission from Karemir:

Hi, 
I'm embedding stackless python in a c++ application under linux. When I 
try to Finalize and Initialize again, I'm getting errors. this is a 
sample code that doesn't work:

int main() {
        Py_Initialize();
        Py_Finalize();
        Py_Initialize();
        Py_Finalize();
}

Second call to Init throws out a nice Segmentation Fault. Here's a 
stack trace:

PyDict_SetItem (op=0x0, key=0x2aaaaab1a4c8, value=0x6bab20) at 
Objects/dictobject.c:616
616             if (!PyDict_Check(op)) {
Current language:  auto; currently c
(gdb) bt
#0  PyDict_SetItem (op=0x0, key=0x2aaaaab1a4c8, value=0x6bab20) at 
Objects/dictobject.c:616
#1  0x0000000000476ac9 in PyDict_SetItemString (v=0x0, 
key=Variable "key" is not available.
) at Objects/dictobject.c:2178
#2  0x00000000004ea77f in PyErr_PrintEx (set_sys_last_vars=1) at 
Python/pythonrun.c:1098
#3  0x00000000004ebfb9 in Py_InitializeEx (install_sigs=1) at 
Python/pythonrun.c:995
#4  0x000000000044a8cc in main () at main.cpp:23

I'm using gcc 3.4.6, and Python 2.5.1 Stackless 3.1b3.

----------
components: Interpreter Core
messages: 56603
nosy: Karemir
severity: urgent
status: open
title: Embedded python reinitialization
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Sun Oct 21 03:51:06 2007
From: report at bugs.python.org (Derek Shockey)
Date: Sun, 21 Oct 2007 01:51:06 -0000
Subject: [New-bugs-announce] [issue1307] smtpd.SMTPServer throws exception
	on MAIL command with no arg
Message-ID: <1192931466.78.0.585745682774.issue1307@psf.upfronthosting.co.za>


New submission from Derek Shockey:

smtpd.SMTPChannel contains a bug such that when connected to an 
SMTPServer (or any subclass thereof), issuing a MAIL command with no 
argument closes the socket and gives this error on the server:

(<type 'exceptions.TypeError'>:'NoneType' object is unsubscriptable ... 
smtpd.py|__getaddr|212])

The desired result is of course is to respond with a 501 Syntax error. 
The problem arises because the arg parameter passed to each smtp_* 
command handler function is None when there is no argument. arg is 
passed on to __getaddr which attempts a slice on the None object.

A check for None in __getaddr that returns will allow the existing code 
to issue the appropriate 501 Syntax error.

----------
components: Library (Lib)
messages: 56616
nosy: dshockey
severity: normal
status: open
title: smtpd.SMTPServer throws exception on MAIL command with no arg
versions: Python 2.5

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

From report at bugs.python.org  Sun Oct 21 22:45:10 2007
From: report at bugs.python.org (James G. sack (jim))
Date: Sun, 21 Oct 2007 20:45:10 -0000
Subject: [New-bugs-announce] [issue1308] unicode(None) anomaly
Message-ID: <1192999510.61.0.176237814745.issue1308@psf.upfronthosting.co.za>


New submission from James G. sack (jim):

'2.5 (r25:51908, Apr 10 2007, 10:27:40) \n[GCC 4.1.2 20070403 (Red Hat 
4.1.2-8)]'

unicode(None)
u'None'

This doesn't seem right, ;-)

Regards,
,,jim

----------
components: Unicode
messages: 56628
nosy: jgsack
severity: normal
status: open
title: unicode(None) anomaly
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Oct 22 02:35:13 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Oct 2007 00:35:13 -0000
Subject: [New-bugs-announce] [issue1309] windows build fix
Message-ID: <1193013313.48.0.697778250167.issue1309@psf.upfronthosting.co.za>


New submission from Christian Heimes:

bytes_methods.c isn't in PCbuild/pythoncore.vcproj

----------
components: Windows
files: py3k_pcbuild_bytes.patch
messages: 56632
nosy: tiran
severity: normal
status: open
title: windows build fix
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file8588/py3k_pcbuild_bytes.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1309>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_pcbuild_bytes.patch
Type: text/x-diff
Size: 559 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071022/d54609b8/attachment.patch 

From report at bugs.python.org  Mon Oct 22 04:23:03 2007
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 22 Oct 2007 02:23:03 -0000
Subject: [New-bugs-announce] [issue1310] tempfile breaks on Windows
Message-ID: <1193019783.77.0.732948071539.issue1310@psf.upfronthosting.co.za>


New submission from Christian Heimes:

tempfile breaks on Windows because exception objectss no longer support
e[0]. The fix is simple and short:

Index: Lib/tempfile.py
===================================================================
--- Lib/tempfile.py     (Revision 58587)
+++ Lib/tempfile.py     (Arbeitskopie)
@@ -201,7 +201,7 @@
                 del fp, fd
                 return dir
             except (OSError, IOError) as e:
-                if e[0] != _errno.EEXIST:
+                if e.args[0] != _errno.EEXIST:
                     break # no point trying more names in this directory
                 pass

----------
components: Library (Lib)
messages: 56638
nosy: tiran
severity: normal
status: open
title: tempfile breaks on Windows
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct 22 14:04:18 2007
From: report at bugs.python.org (=?utf-8?q?David_K=C3=A5gedal?=)
Date: Mon, 22 Oct 2007 12:04:18 -0000
Subject: [New-bugs-announce] [issue1311] os.path.exists(os.devnul)
	regression on windows
Message-ID: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za>


New submission from David K?gedal:

When moving from Python 2.4 to Python 2.5, my program stopped working on
win32 because of a change in os.path.exists. I couldn't find any
description of the change, so I can only assume it's a bug.

The os.devnul variable contains the name of the "null file", which is
"/dev/null" on posix, and "nul" on win32. As I understand it, "NUL" is a
file that exists in every directory on win32.

Opening the "nul" file with open("nul", "r") works fine, but
os.path.exists("nul") returns False. In Python 2.4, it returns True.

----------
components: Library (Lib)
messages: 56644
nosy: d_kagedal
severity: normal
status: open
title: os.path.exists(os.devnul) regression on windows
versions: Python 2.5

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

From report at bugs.python.org  Mon Oct 22 22:19:07 2007
From: report at bugs.python.org (Daniel Nouri)
Date: Mon, 22 Oct 2007 20:19:07 -0000
Subject: [New-bugs-announce] [issue1312] doctest EXCEPTION_RE can't handle
	preceding output
Message-ID: <1193084346.99.0.810572537289.issue1312@psf.upfronthosting.co.za>


New submission from Daniel Nouri:

doctest.DocTestParser._EXCEPTION_RE does not allow for output before the
actual traceback.

Attached is a simple test that demonstrates the problem.  This patch
fixes it:

--- /usr/lib/python2.5/doctest.py 2007-10-22 21:45:21.000000000 +0200
+++ /home/daniel/tmp/doctest.py       2007-10-22 22:19:12.000000000 +0200
@@ -513,7 +513,7 @@
     _EXCEPTION_RE = re.compile(r"""
         # Grab the traceback header.  Different versions of Python have
         # said different things on the first traceback line.
-        ^(?P<hdr> Traceback\ \(
+        .*^(?P<hdr> Traceback\ \(
             (?: most\ recent\ call\ last
             |   innermost\ last
             ) \) :


    _EXCEPTION_RE = re.compile(r"""
        # Grab the traceback header.  Different versions of Python have
        # said different things on the first traceback line.
        ^(?P<hdr> Traceback\ \(
            (?: most\ recent\ call\ last
            |   innermost\ last
            ) \) :
        )
        \s* $                # toss trailing whitespace on the header.
        (?P<stack> .*?)      # don't blink: absorb stuff until...
        ^ (?P<msg> \w+ .*)   #     a line *starts* with alphanum.
        """, re.VERBOSE | re.MULTILINE | re.DOTALL)

----------
components: Library (Lib)
files: doctest-bug.py
messages: 56655
nosy: nouri
severity: normal
status: open
title: doctest EXCEPTION_RE can't handle preceding output
versions: Python 2.5
Added file: http://bugs.python.org/file8591/doctest-bug.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1312>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doctest-bug.py
Type: text/x-python
Size: 302 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071022/a822c701/attachment.py 

From report at bugs.python.org  Mon Oct 22 23:09:55 2007
From: report at bugs.python.org (Nathan Haines)
Date: Mon, 22 Oct 2007 21:09:55 -0000
Subject: [New-bugs-announce] [issue1313] Typo in Python Library Reference
	documentation: logging module
Message-ID: <1193087395.88.0.157483594139.issue1313@psf.upfronthosting.co.za>


New submission from Nathan Haines:

In the Python Library Reference manual, in section 14.5 (logging), there
is a typo in the debug function example code.  In the 2.5 PDF this is on
page 446.

The last line reads:
logging.warning("Protocol problem: %s", "connection reset", extra=d)

This should read:
logging.warning("Protocol problem: %s", "connection reset", extra=dict)

This error persists in the 2.6 and 3.0 documentation.

----------
components: Documentation
messages: 56658
nosy: nhaines
severity: normal
status: open
title: Typo in Python Library Reference documentation: logging module
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Oct 23 10:35:59 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 23 Oct 2007 08:35:59 -0000
Subject: [New-bugs-announce] [issue1314] Patch for strftime problem on
	German Windows
Message-ID: <1193128559.94.0.435784915491.issue1314@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch fixes the failing unit tests for time and strptime on German
and probably other Windows installations.

-                       ret = PyUnicode_FromStringAndSize(outbuf, buflen);
+                       ret = PyUnicode_Decode(outbuf, buflen,
+                                              TZNAME_ENCODING, NULL);

----------
components: Extension Modules
files: py3k_win_strftime.patch
messages: 56675
nosy: tiran
severity: normal
status: open
title: Patch for strftime problem on German Windows
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8595/py3k_win_strftime.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1314>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_win_strftime.patch
Type: text/x-diff
Size: 473 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071023/ec394a3a/attachment.patch 

From report at bugs.python.org  Tue Oct 23 12:31:25 2007
From: report at bugs.python.org (Joel Schaerer)
Date: Tue, 23 Oct 2007 10:31:25 -0000
Subject: [New-bugs-announce] [issue1315] Bug in pstats.print_callers
Message-ID: <1193135485.77.0.648443887061.issue1315@psf.upfronthosting.co.za>


New submission from Joel Schaerer:

The following command:

python -c "import
pstats;s=pstats.Stats('profile.pck');s.strip_dirs();s.print_callers(25)"

Crashes with the following traceback:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/pstats.py", line 388, in print_callers
    self.print_call_line(width, func, callers, "<-")
  File "/usr/lib/python2.5/pstats.py", line 417, in print_call_line
    nc, cc, tt, ct = value
ValueError: too many values to unpack

when called with the attached profile.pck file, which was generated with
cProfile.

The interesting thing is that is I remove strip_dirs, it works.

----------
components: Library (Lib)
files: profile.pck
messages: 56677
nosy: lardon
severity: normal
status: open
title: Bug in pstats.print_callers
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8596/profile.pck

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1315>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profile.pck
Type: application/octet-stream
Size: 115173 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071023/ec670981/attachment-0001.obj 

From report at bugs.python.org  Tue Oct 23 20:41:36 2007
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Oct 2007 18:41:36 -0000
Subject: [New-bugs-announce] [issue1316] fix a few PyInt_Check vs
	PyLong_Check problems
Message-ID: <1193164896.58.0.699335652661.issue1316@psf.upfronthosting.co.za>


New submission from Georg Brandl:

This fixes a few places where PyInt_Check and PyLong_Check are used
redundantly, and where the checks must be changed now that there's only
PyLong.

----------
assignee: gvanrossum
files: long_check.diff
keywords: patch, py3k
messages: 56685
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: fix a few PyInt_Check vs PyLong_Check problems
versions: Python 3.0
Added file: http://bugs.python.org/file8598/long_check.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1316>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: long_check.diff
Type: application/pgp-signature
Size: 7749 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071023/def0e6f1/attachment.pgp 

From report at bugs.python.org  Tue Oct 23 21:24:30 2007
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 23 Oct 2007 19:24:30 -0000
Subject: [New-bugs-announce] [issue1317] smtplib.SMTP docs
Message-ID: <1193167470.47.0.372860933497.issue1317@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr.:

The docstring for the smtplib.SMTP class includes descriptions of some
instance attributes that are not covered by the documentation:

  does_esmtp
  ehlo_resp
  esmtp_features
  helo_resp

If these are intended as part of the public interface, they should be
documented in the .tex/.rst documentation, otherwise their descriptions
should be in a comment instead of a docstring.  (helo_resp is mentioned
in Misc/HISTORY, if that actually means anything.)

----------
components: Documentation
messages: 56688
nosy: fdrake
severity: normal
status: open
title: smtplib.SMTP docs
type: rfe
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Oct 23 23:22:21 2007
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 23 Oct 2007 21:22:21 -0000
Subject: [New-bugs-announce] [issue1318] Remove os.tmpnam() and os.tempnam()
	[patch]
Message-ID: <1193174541.45.0.8073399338.issue1318@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I couldn't stand the compiler warnings any more. :)

The patch removes os.tmpnam() and os.tempnam() from the posix module. It
also updates the docs and tests. TMP_MAX is kept for the tempfile
module. I haven't figured out how to remove the defines from pyconfig.h.
I guess they are always added by autoconf/automake.

----------
components: Documentation, Extension Modules
files: py3k_remove_os_tmpnam.patch
messages: 56693
nosy: tiran
severity: normal
status: open
title: Remove os.tmpnam() and os.tempnam() [patch]
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file8599/py3k_remove_os_tmpnam.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1318>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_remove_os_tmpnam.patch
Type: text/x-diff
Size: 9957 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071023/8678788c/attachment-0001.patch 

From report at bugs.python.org  Wed Oct 24 00:50:18 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Oct 2007 22:50:18 -0000
Subject: [New-bugs-announce] [issue1319] py3k: fixes for test_ctypes
Message-ID: <1193179818.56.0.0105500594667.issue1319@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

Updates to ctypes for python 3.0 to make the tests pass.

Notable changes are:
- return bytes instead of str8
- integers in range(256) are accepted as "one char string":
libc.strchr("abcdef", 98) is now valid.
- directly use the wide-char version of the win32 function LoadLibrary.

Tested on WinXP, with Visual Studio Express 2005.

----------
components: Interpreter Core
files: ctypes.diff
messages: 56696
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: fixes for test_ctypes
versions: Python 3.0
Added file: http://bugs.python.org/file8600/ctypes.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1319>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctypes.diff
Type: application/octet-stream
Size: 20925 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071023/14281ee8/attachment-0001.obj 

From report at bugs.python.org  Wed Oct 24 05:12:35 2007
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 24 Oct 2007 03:12:35 -0000
Subject: [New-bugs-announce] [issue1320] PCBuild8 Solution Support Changes
Message-ID: <1193195555.05.0.403245196794.issue1320@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

The following observations were made of the PCBuild8 solution:

1  pyproject.vsprops was missing usermacros for tcltk / msi
2  no vcproj for ssl module like the PCBuild solution has
3  _msi project did not havea valid includedir
4  _tkinter did not have a valid includedir


Suggested Changes:


1  I would like to suggest adding macros such as the following to the
pyproject.vsprops.  These could then be referenced throughout the
associated projects.

<UserMacro
  Name="tcltkDir"
  Value="..\..\..\tcltk"
/>
<UserMacro
  Name="msinstDir"
  Value="C:\MsiIntel.SDK\"
/>

Reasoning: To continue to promote pyproject.vsprops as being an
almost-one-stop-shop for setting relative locations of third party
libraries.  This can be done in the following way:

- tcltkDir could be used to add a valid includedir to the _tkinter project
- msinstDir could be used to add a valid includedir to the _msi project.


2  no vcproj for ssl module like the PCBuild solution has

See: pcbuild8_for_ssl.patch... The only thing left to do is add the
associated _ssl project to the vsproj.

Reasoning: To let their be a way to build the ssl module.

Note: I suppose there could have been good reason for not putting in the
_ssl module, since it uses a support .bat / .py to build (but that's for
better people to decide)


3 If 1 is satisfied, a standard includedir variable could be added


4 If 1 is satisfied, a standard includedir variable could be added


I am hesitant to submit a full patch for all of these here, since it may
be decided that some of these be treated as separate issues.  If a full
patch is desired I can submit one.

----------
components: Build, Windows
files: pcbuild8_for_ssl.patch
messages: 56698
nosy: JosephArmbruster
severity: normal
status: open
title: PCBuild8 Solution Support Changes
versions: Python 2.6
Added file: http://bugs.python.org/file8601/pcbuild8_for_ssl.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1320>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcbuild8_for_ssl.patch
Type: application/octet-stream
Size: 13003 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071024/7c5b2113/attachment.obj 

From report at bugs.python.org  Wed Oct 24 10:18:16 2007
From: report at bugs.python.org (Moshe Cohen)
Date: Wed, 24 Oct 2007 08:18:16 -0000
Subject: [New-bugs-announce] [issue1321] TimedRotatingFileHandler logic for
	day of week is wrong
Message-ID: <1193213896.73.0.793108305919.issue1321@psf.upfronthosting.co.za>


Changes by Moshe Cohen:


----------
components: None
nosy: mosheco
severity: major
status: open
title: TimedRotatingFileHandler logic for day of week is wrong
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Wed Oct 24 19:21:04 2007
From: report at bugs.python.org (Yann Cointepas)
Date: Wed, 24 Oct 2007 17:21:04 -0000
Subject: [New-bugs-announce] [issue1322] platform.dist() has unpredictable
	result under Linux
Message-ID: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>


New submission from Yann Cointepas:

The distribution name returned by platform.dist() depends on the order
of os.path.listdir( '/etc' ). It selects the first file matching the
regex r'(\w+)[-_](release|version)' and takes part of the file name
(i.e. matchResult.groups()[0]) as distribution name. But there are often
several files matching this pattern (at least on Fedora and Mandriva).
For instance, on a Mandriva 2007.1 official, I can see the following files:

[login at localhost ~]$ ls -l /etc/*-release
-rw-r--r-- 1 root root 137 jan 18  2007 /etc/lsb-release
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/mandrakelinux-release ->
mandriva-r                                                             
                              elease
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/mandrake-release ->
mandriva-releas                                                        
                                   e
-rw-r--r-- 1 root root  50 avr  2  2007 /etc/mandriva-release
lrwxrwxrwx 1 root root  16 oct  7 17:32 /etc/redhat-release ->
mandriva-release

Therefore, the result for platform.distrib()[0] could be mandriva,
mandrake, redhat or even lsb. The first match wins !

Ignoring symlinks could remove part of the problem. On Mandriva, it
would leave only lsb-release and mandriva-release. It is possible to
select the good one by ignoring lsb-release or by verifying the file's
content (mandriva-release has one line and lsb-release has several
lines). I do not know if the second method is portable.

----------
messages: 56710
nosy: sapetnioc
severity: major
status: open
title: platform.dist() has unpredictable result under Linux
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 25 00:30:33 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Oct 2007 22:30:33 -0000
Subject: [New-bugs-announce] [issue1323] py3k: file.truncate() changes the
	file position
Message-ID: <1193265033.18.0.927714620141.issue1323@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This patch corrects a problem in test_file.py on Windows:
f.truncate() seeks to the truncation point, but does not empty the
buffers. In the test, f.tell() returns -1...

Now we flush the file before, and seek to the initial position after.
The same trick was present in 2.5, in fileobject.c::file_truncate. The
same comments apply as well.

Reviewers needed! Flushing may change the behaviour, but seems more
correct to me (and closer to python2.5). Should we add specific tests
for this?

Also, change the test to be sure to close the file before trying to
remove it (it seems that in a finally: block, the exception still
references all the local variables in the traceback). Otherwise the
previous problem is hidden by a "file locked" error in the finally block.

----------
components: Windows
files: truncate.diff
messages: 56732
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: file.truncate() changes the file position
versions: Python 3.0
Added file: http://bugs.python.org/file8606/truncate.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1323>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: truncate.diff
Type: application/octet-stream
Size: 2111 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071024/ec80455c/attachment.obj 

From report at bugs.python.org  Thu Oct 25 09:04:59 2007
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 25 Oct 2007 07:04:59 -0000
Subject: [New-bugs-announce] [issue1324] r58034 breaks building _ctypes with
	the upstream libffi.
Message-ID: <1193295899.21.0.371258619006.issue1324@psf.upfronthosting.co.za>


New submission from Matthias Klose:

This breaks building _ctypes with the upstream libffi.

r58034 | thomas.heller | 2007-09-07 08:32:17 +0200 (Fr, 07 Sep 2007) | 1
line

Add a 'c_longdouble' type to the ctypes module.


gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes
-I/usr/include -I.
-I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/./Include
-I./Include -IInclude -I. -I/usr/local/include
-I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Include
-I/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build -c
/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c
-o
build/temp.linux-armv5tel-2.6/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.o
/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c:1756:
error: redefinition of 'ffi_type_double'
/home/pybot/buildarea-armeabi/trunk.klose-linux-armeabi/build/Modules/_ctypes/cfield.c:1755:
error: previous definition of 'ffi_type_double' was here

ffi.h has:
#if 0
extern ffi_type ffi_type_longdouble;
#else
#define ffi_type_longdouble ffi_type_double
#endif

----------
assignee: theller
components: Extension Modules
messages: 56736
nosy: doko, theller
severity: normal
status: open
title: r58034 breaks building _ctypes with the upstream libffi.
versions: Python 2.6

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

From report at bugs.python.org  Thu Oct 25 15:01:36 2007
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 25 Oct 2007 13:01:36 -0000
Subject: [New-bugs-announce] [issue1325] zipimport.zipimporter.archive
	undocumented and untested
Message-ID: <1193317296.93.0.487573711229.issue1325@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

zipimporter instances have a read-only "archive" attribute, but there is
no documentation referring to it, nor any test coverage for its existence.

It's quite useful to know what a zipimporter is pointed at (for
debugging and other introspection).  It'd be nice to know that this is a
real feature and isn't going to disappear.

----------
components: Documentation, Library (Lib)
messages: 56741
nosy: exarkun
severity: normal
status: open
title: zipimport.zipimporter.archive undocumented and untested
type: rfe

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

From report at bugs.python.org  Thu Oct 25 15:08:00 2007
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 25 Oct 2007 13:08:00 -0000
Subject: [New-bugs-announce] [issue1326] "internal" zipimport.zipimporter
	feature untested
Message-ID: <1193317680.83.0.000309828654595.issue1326@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

It's possible to construct a zipimporter with a "path" which points
first to a zip file and then continues to refer to a file within that
zip file.  For example,

    /foo/bar.zip/baz

where /foo/bar.zip is not a directory, but a zip file, and baz is a file
or directory in the contents of the zip file.

There is no test coverage for this functionality, though.

----------
components: Library (Lib)
messages: 56742
nosy: exarkun
severity: normal
status: open
title: "internal" zipimport.zipimporter feature untested
type: rfe

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

From report at bugs.python.org  Fri Oct 26 00:59:36 2007
From: report at bugs.python.org (James G. sack (jim))
Date: Thu, 25 Oct 2007 22:59:36 -0000
Subject: [New-bugs-announce] [issue1328] feature request: force BOM option
Message-ID: <1193353176.1.0.485065586233.issue1328@psf.upfronthosting.co.za>


New submission from James G. sack (jim):

The behavior of codecs utf_16_[bl]e is to omit the BOM.

In a testing environment (and perhaps elsewhere), a forced BOM is useful.
I'm requesting an optional argument something like
 force_BOM=False

I guess it would require such an option in multiple function calls, sorry I 
don't know enough to itemize them.

If this is implemented, it might be desirable to think about the aliases 
like unicode*unmarked.

Regards,
..jim

----------
components: Unicode
messages: 56759
nosy: jgsack
severity: minor
status: open
title: feature request: force BOM option
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 26 01:07:48 2007
From: report at bugs.python.org (Jean Brouwers)
Date: Thu, 25 Oct 2007 23:07:48 -0000
Subject: [New-bugs-announce] [issue1329] Different 3.0a1 exit behavior
Message-ID: <1193353667.97.0.10282198755.issue1329@psf.upfronthosting.co.za>


New submission from Jean Brouwers:

Python 3.0a1 on Linux and MacOS X 10.4.10 exits differently than Python 
2.4 and 2.5.

With previous Python binaries the destructor** function of any pre-
loaded shared library is called prior to exit.  With Python 3.0a1 it is 
not, neither when exiting Python from the command line with Ctrl-D nor 
when using exit().

A workaround is to install a SIGABRT signal handler from the library and 
exit Python with os.abort().

Python 3.0a1 was built from source using the standard build sequence 
without any ./configure options except --prefix. 

---
**) defined with GNU __attribute__((destructor)).  The shared library is  
loaded through environment variable LD_PRELOAD on Linux and 
DYLD_INSERT_LIBRARIES on MacOS X.

----------
components: Interpreter Core
messages: 56761
nosy: MrJean1
severity: normal
status: open
title: Different 3.0a1 exit behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Oct 26 03:39:31 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Oct 2007 01:39:31 -0000
Subject: [New-bugs-announce] [issue1330] Fix truncate on Windows,
	this time for real
Message-ID: <1193362771.35.0.841578891036.issue1330@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch fixes for real what "Patch # 1323 by Amaury Forgeot d'Arc"
claims to have fixed. I reverted his patch to io.py and implemented the
fix in the Windows specific part of truncate in _fileio.c. It fixes two
tests for raw io on Windows.

----------
components: Library (Lib)
files: py3k_win_io.patch
messages: 56769
nosy: tiran
severity: normal
status: open
title: Fix truncate on Windows, this time for real
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8613/py3k_win_io.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1330>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_win_io.patch
Type: text/x-diff
Size: 2166 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071026/6665671d/attachment.patch 

From report at bugs.python.org  Fri Oct 26 04:21:15 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Oct 2007 02:21:15 -0000
Subject: [New-bugs-announce] [issue1331] More fixes for Windows
Message-ID: <1193365275.63.0.0756380747917.issue1331@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch fixes some of the problems on Windows. It doesn't introduce
addition problems on Linux.

----------
components: Library (Lib)
files: py3k_misc_win.patch
messages: 56770
nosy: gvanrossum, nnorwitz, tiran
severity: normal
status: open
title: More fixes for Windows
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8614/py3k_misc_win.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1331>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_misc_win.patch
Type: text/x-diff
Size: 7054 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071026/facf7426/attachment.patch 

From report at bugs.python.org  Fri Oct 26 04:48:31 2007
From: report at bugs.python.org (Warren DeLano)
Date: Fri, 26 Oct 2007 02:48:31 -0000
Subject: [New-bugs-announce] [issue1332] threading.RLock().aquire(0) fails
	with python-2.5.1.amd64.msi
Message-ID: <1193366911.48.0.10009390282.issue1332@psf.upfronthosting.co.za>


Changes by Warren DeLano:


----------
components: Windows
nosy: delwarl
severity: normal
status: open
title: threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Fri Oct 26 14:16:28 2007
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 26 Oct 2007 12:16:28 -0000
Subject: [New-bugs-announce] [issue1333] merge urllib and urlparse
	functionality
Message-ID: <1193400988.05.0.68480909797.issue1333@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

The purpose is to encapsulate all URL handling functions in one module.
At the moment there are three modules that dissect URLs for various bits
of information. These are urlparse - to split url into components,
urllib - to decode splitted data and cgi - to parse query component.

To outline the API of the proposed module I'll start with urlparse :
http://docs.python.org/lib/module-urlparse.html

1. There are two identical functions - urlparse and urlsplit that make
the same parsing operation, but vary in format of return arguments. They
could be replaced with one - let's call it urlsplitex - that returns
result in a class with attributes - not a subclass of list, but rather
dictionary subclass, because positional arguments are evil and you
always have to look into reference to find out the correct order if you
read or debug the code.

2. Returned class should not be immutable. It must be possible to modify
the results to unset extra parts (like fragments) or edit required parts
as needed and get the target URL via urlunsplitex or embedded method of
the same class. Thus arguments "default_scheme" and "allow_fragments"
will be useless as well as function urldefrag.

3. urlparsex, a replacement for "parsing" function of the new library
should be high-level functions to dissect url information into tree-like
structure with atomic leafs. This includes decoding url entities and
splitting parameters into child structures. The proposed structure of
url class attributes is:

scheme       string
netloc       class
       username  string
       password  string
       server    string
       port      integer
path         list with objects of class
       part      string
       param     list with objects of class
           name     string
           value    string
query        list with objects of class
       name      string
       value     string
fragment     string


4. urlunparsex will be provided to reassemble class back into URL. This
will deprecate series of functions from urllib like quote, unquote,
urlencode and also functions parse_qs and parse_qsl from cgi module.

References:
http://mail.python.org/pipermail/patches/2005-February/016972.html
http://bugs.python.org/issue1722348
http://bugs.python.org/issue1462525

----------
components: Library (Lib)
messages: 56787
nosy: techtonik
severity: normal
status: open
title: merge urllib and urlparse functionality
type: rfe
versions: Python 3.0

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

From report at bugs.python.org  Fri Oct 26 15:16:09 2007
From: report at bugs.python.org (Tal Einat)
Date: Fri, 26 Oct 2007 13:16:09 -0000
Subject: [New-bugs-announce] [issue1334] IDLE - Fix several highlighting bugs
Message-ID: <1193404569.43.0.620999793422.issue1334@psf.upfronthosting.co.za>


New submission from Tal Einat:

This patch fixes the following bugs:

* Configured selection highlighting colors were ignored
* Updating highlighting in the config dialog would cause
  non-Python files to be colored as if they were Python source

Additionally, adding and removing of ColorDelegators to the Percolator
was not being done in an organized fashion, causing multiple colorizers
to be present simultaneously in certain cases. This patch ensures that
there will always be at most one colorizer present in the Percolator.

This patch also reduces code duplication by grouping colorization code
into EditorWindow.ResetColorizer, and having __init__ let ResetColorizer
do its thing.

There is one side effect to this patch - applying a new highlighting
scheme or renaming a file causes the screen to "blink". This can be
avoided without too much work, but IMHO is minor enough to leave as it is.

----------
components: IDLE
files: IDLE_highlighting.071026.patch
messages: 56788
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Fix several highlighting bugs
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8618/IDLE_highlighting.071026.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1334>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_highlighting.071026.patch
Type: application/octet-stream
Size: 5388 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071026/1ef27895/attachment.obj 

From report at bugs.python.org  Fri Oct 26 15:50:39 2007
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Oct 2007 13:50:39 -0000
Subject: [New-bugs-announce] [issue1335] bytesiterator patch
Message-ID: <1193406639.07.0.00963695082717.issue1335@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Here is the long promised bytes iterator view. It was much, *much*
easier to write it than I have thought. In fact I spent more time fixing
the indention than to modify the code from striterator.

I haven't written an unit test for it. The other iterators don't have
extra tests, too.

>>> iter(bytes(b"abc"))
<bytesiterator object at 0xb7cc578c>
>>> for i in iter(bytes(b"abc")): print(i)
...
97
98
99
>>> for i in bytes(b"abc"): print(i)
...
97
98
99

----------
components: Interpreter Core
files: py3k_bytesiterator.patch
messages: 56789
nosy: gvanrossum, tiran
severity: normal
status: open
title: bytesiterator patch
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8619/py3k_bytesiterator.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1335>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_bytesiterator.patch
Type: text/x-diff
Size: 4646 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071026/f0a8f418/attachment.patch 

From report at bugs.python.org  Fri Oct 26 16:04:12 2007
From: report at bugs.python.org (Jonathan Amsterdam)
Date: Fri, 26 Oct 2007 14:04:12 -0000
Subject: [New-bugs-announce] [issue1336] subprocess.Popen hangs when child
	writes to stderr
Message-ID: <1193407452.43.0.999665750675.issue1336@psf.upfronthosting.co.za>


New submission from Jonathan Amsterdam:

This is under Linux (2.6).

I occasionally see subprocess.Popen() fail to return, and I have
finally figured out roughly what's going on. It involves the GC and
stderr.

1. os.fork()

2. Parent blocks reading from errpipe_read (subprocess.py:982)

3. In child, a GC occurs before the exec.

4. The GC attempts to free a file descriptor, calling file_dealloc.

5. That function gets an error closing the descriptor ("close failed:
[Errno 9] Bad file descriptor\n," is the string I extracted via gdb).

6. It attempts to write the error to stderr and blocks. Since it never
execs or writes to errpipe_write, both child and parent are hung.

Here is the pstack output on the child:

#0  0x006587a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0072f11b in __write_nocancel () from /lib/tls/libc.so.6
#2  0x006d409f in _IO_new_file_write () from /lib/tls/libc.so.6
#3  0x006d42ec in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#4  0x006afce9 in buffered_vfprintf () from /lib/tls/libc.so.6
#5  0x006afe8b in vfprintf () from /lib/tls/libc.so.6
#6  0x080dd4af in mywrite ()
#7  0x080dd505 in PySys_WriteStderr ()
#8  0x08064cd0 in file_dealloc ()
#9  0x08079c88 in dict_dealloc ()
#10 0x0808931d in subtype_dealloc ()
#11 0x08079af3 in PyDict_Clear ()
#12 0x0807bb6a in dict_tp_clear ()
#13 0x080e0ead in collect ()
#14 0x080e1912 in _PyObject_GC_New ()
#15 0x0805e50b in PyInstance_NewRaw ()
#16 0x0805e5d7 in PyInstance_New ()
#17 0x0805bdc0 in PyObject_Call ()
#18 0x080aecef in PyEval_CallObjectWithKeywords ()
#19 0x080ca975 in PyErr_NormalizeException ()
#20 0x080b492c in PyEval_EvalFrame ()
#21 0x080b5eb2 in PyEval_EvalCodeEx ()
#22 0x080b3c83 in PyEval_EvalFrame ()
#23 0x080b5734 in PyEval_EvalFrame ()
#24 0x080b5eb2 in PyEval_EvalCodeEx ()
#25 0x080fce92 in function_call ()
#26 0x0805bdc0 in PyObject_Call ()
#27 0x080641e5 in instancemethod_call ()
#28 0x0805bdc0 in PyObject_Call ()
#29 0x0808ffce in slot_tp_init ()
#30 0x08088b3a in type_call ()
#31 0x0805bdc0 in PyObject_Call ()
#32 0x080b0f05 in PyEval_EvalFrame ()
#33 0x080b5eb2 in PyEval_EvalCodeEx ()
#34 0x080fce92 in function_call ()
#35 0x0805bdc0 in PyObject_Call ()
#36 0x080641e5 in instancemethod_call ()
#37 0x0805bdc0 in PyObject_Call ()
#38 0x0808ffce in slot_tp_init ()
#39 0x08088b3a in type_call ()
#40 0x0805bdc0 in PyObject_Call ()
#41 0x080b0f05 in PyEval_EvalFrame ()
#42 0x080b5734 in PyEval_EvalFrame ()
#43 0x080b5eb2 in PyEval_EvalCodeEx ()
#44 0x080fce92 in function_call ()
#45 0x0805bdc0 in PyObject_Call ()
#46 0x080641e5 in instancemethod_call ()
#47 0x0805bdc0 in PyObject_Call ()
#48 0x0808ffce in slot_tp_init ()
#49 0x08088b3a in type_call ()
#50 0x0805bdc0 in PyObject_Call ()
#51 0x080b0f05 in PyEval_EvalFrame ()
#52 0x080b5eb2 in PyEval_EvalCodeEx ()
#53 0x080fce92 in function_call ()
#54 0x0805bdc0 in PyObject_Call ()
#55 0x080b075f in PyEval_EvalFrame ()
#56 0x080b5734 in PyEval_EvalFrame ()
#57 0x080b5734 in PyEval_EvalFrame ()
#58 0x080b5734 in PyEval_EvalFrame ()
#59 0x080b5eb2 in PyEval_EvalCodeEx ()
#60 0x080b3c83 in PyEval_EvalFrame ()
#61 0x080b5734 in PyEval_EvalFrame ()
#62 0x080b5734 in PyEval_EvalFrame ()
#63 0x080b5eb2 in PyEval_EvalCodeEx ()
#64 0x080b3c83 in PyEval_EvalFrame ()
#65 0x080b5eb2 in PyEval_EvalCodeEx ()
#66 0x080b3c83 in PyEval_EvalFrame ()
#67 0x080b5eb2 in PyEval_EvalCodeEx ()
#68 0x080b3c83 in PyEval_EvalFrame ()
#69 0x080b5734 in PyEval_EvalFrame ()
#70 0x080b5734 in PyEval_EvalFrame ()
#71 0x080b5734 in PyEval_EvalFrame ()
#72 0x080b5734 in PyEval_EvalFrame ()
#73 0x080b5734 in PyEval_EvalFrame ()
#74 0x080b5eb2 in PyEval_EvalCodeEx ()
#75 0x080fce92 in function_call ()
#76 0x0805bdc0 in PyObject_Call ()
#77 0x080b075f in PyEval_EvalFrame ()
#78 0x080b5eb2 in PyEval_EvalCodeEx ()
#79 0x080b3c83 in PyEval_EvalFrame ()
#80 0x080b5eb2 in PyEval_EvalCodeEx ()
#81 0x080b3c83 in PyEval_EvalFrame ()
#82 0x080b5eb2 in PyEval_EvalCodeEx ()
#83 0x080b3c83 in PyEval_EvalFrame ()
#84 0x080b5734 in PyEval_EvalFrame ()
#85 0x080b5734 in PyEval_EvalFrame ()
#86 0x080b5eb2 in PyEval_EvalCodeEx ()
#87 0x080b601a in PyEval_EvalCode ()
#88 0x080d9ff4 in PyRun_FileExFlags ()
#89 0x080da8d6 in PyRun_SimpleFileExFlags ()
#90 0x08055617 in Py_Main ()
#91 0x08054e3f in main ()

----------
components: Library (Lib)
messages: 56790
nosy: jba
severity: normal
status: open
title: subprocess.Popen hangs when child writes to stderr
type: crash
versions: Python 2.4

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

From report at bugs.python.org  Fri Oct 26 16:10:25 2007
From: report at bugs.python.org (Kevin Watters)
Date: Fri, 26 Oct 2007 14:10:25 -0000
Subject: [New-bugs-announce] [issue1337] Tools/msi/msi.py does not work with
	PCBuild8
Message-ID: <1193407824.97.0.744123721135.issue1337@psf.upfronthosting.co.za>


New submission from Kevin Watters:

The msi.py script for creating an Windows MSI installer from a Python
source tree has hardcoded values for "PCBuild." The newer MSVC 2005
build directory is "PCBuild8" and has a slightly different structure.

msi.py needs to be changed to be able to work with a 2005-built Python
tree as well.

----------
components: Build
messages: 56791
nosy: kevinwatters
severity: normal
status: open
title: Tools/msi/msi.py does not work with PCBuild8
type: rfe
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Oct 26 21:06:01 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Oct 2007 19:06:01 -0000
Subject: [New-bugs-announce] [issue1338] pickling bytes?
Message-ID: <1193425561.23.0.273747744158.issue1338@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Alexandre Vassalotti suggested the following:

A simple way to add specific pickling support for bytes/buffer objects
would be to define two new constants:

 BYTES          = b'\x8c'  # push a bytes object
 BUFFER         = b'\x8d'  # push a buffer object

And add the following pickling and unpickling procedures:

 def save_bytes(self, obj, pack=struct.pack):
     n = len(obj)
     self.write(BYTES + pack("<i", n) + obj)

 def save_buffer(self, obj, pack=struct.pack):
     n = len(obj)
     self.write(BUFFER + pack("<i", n) + obj)

 def load_bytes(self):
     len = mloads(b'i' + self.read(4))
     self.append(self.read(len))

 def load_buffer(self):
     len = mloads(b'i' + self.read(4))
     self.append(buffer(self.read(len)))

The only problem with this approach is that bytes object bigger than
4GB cannot be pickled. Currently, this applies to all string-like
objects, so I don't think this restriction will cause any trouble.
Also, it would be a good idea to bump the protocol version to 3 to
ensure that older Python versions don't try to load pickle streams
created with these new constants.

By the way, would it be a good idea to add specific pickling support
for sets (and frozensets)?

----------
keywords: py3k
messages: 56809
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: pickling bytes?
versions: Python 3.0

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

From report at bugs.python.org  Sat Oct 27 01:26:14 2007
From: report at bugs.python.org (Bill Fenner)
Date: Fri, 26 Oct 2007 23:26:14 -0000
Subject: [New-bugs-announce] [issue1339] smtplib starttls() should ehlo() if
	it needs to
Message-ID: <1193441174.56.0.280335873353.issue1339@psf.upfronthosting.co.za>


New submission from Bill Fenner:

smtplib's "complex" methods, login and sendmail, try to EHLO or HELO if 
it hasn't been done yet.  login also checks to see if the EHLO response 
included the ability to do authorization.

starttls seems to me to be similar in nature: why should it not try to 
EHLO or HELO, and check that self.has_extn("starttls")?

----------
components: Library (Lib)
messages: 56829
nosy: fenner
severity: normal
status: open
title: smtplib starttls() should ehlo() if it needs to
type: rfe
versions: Python 2.4

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

From report at bugs.python.org  Sat Oct 27 01:28:09 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Oct 2007 23:28:09 -0000
Subject: [New-bugs-announce] [issue1340] correction for test_tempfile in
	py3k on Windows
Message-ID: <1193441289.92.0.979777798118.issue1340@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This tiny patch correct a failure in test_tempfile on Windows: in
SpooledTemporaryFile, avoid translating the newlines twice.
Otherwise, in "universal" text mode, \n gets transformed to \r\n, then
to \r\r\n, which is read as \n\n.
Passing the encoding is OK, since the round-trip gives the same result,
and it allow encoding errors to occur at the right place.

Index: Lib/tempfile.py
===================================================================
--- Lib/tempfile.py     (revision 58680)
+++ Lib/tempfile.py     (working copy)
@@ -495,7 +495,7 @@
         if 'b' in mode:
             self._file = _io.BytesIO()
         else:
-            self._file = _io.StringIO(encoding=encoding, newline=newline)
+            self._file = _io.StringIO(encoding=encoding)
         self._max_size = max_size
         self._rolled = False
         self._TemporaryFileArgs = {'mode': mode, 'buffering': buffering,

----------
components: Windows
messages: 56830
nosy: amaury.forgeotdarc
severity: normal
status: open
title: correction for test_tempfile in py3k on Windows
versions: Python 3.0

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

From report at bugs.python.org  Sat Oct 27 01:59:30 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Oct 2007 23:59:30 -0000
Subject: [New-bugs-announce] [issue1341] correction for test_fileinput in
	py3k on Windows
Message-ID: <1193443170.37.0.0840293747234.issue1341@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This patch corrects test_fileinput on Windows: when redirecting stdout,
os.open should be given O_BINARY, because the file descriptor is then
wrapped in a text-mode file; os.fdopen(fd, "w").

----------
files: fileinput.diff
messages: 56833
nosy: amaury.forgeotdarc
severity: normal
status: open
title: correction for test_fileinput in py3k on Windows
Added file: http://bugs.python.org/file8623/fileinput.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1341>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileinput.diff
Type: application/octet-stream
Size: 880 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071026/a39dbda9/attachment.obj 

From report at bugs.python.org  Sat Oct 27 05:40:36 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Oct 2007 03:40:36 -0000
Subject: [New-bugs-announce] [issue1342] Crash on Windows if Python runs
	from a directory with umlauts
Message-ID: <1193456436.1.0.972609600257.issue1342@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python 3.0 doesn't run from a directory with umlauts and possible other
non ASCII chars.

I renamed my development folder from C:\dev\ to c:\test ???? name\.
Python crashes after a few moments before it can reach its shell.

 	python30.dll!PyErr_SetObject(_object * exception=0x1e1b9888, _object *
value=0x00a0b8a0)  Zeile 56 + 0xb Bytes	C
 	python30.dll!PyErr_SetString(_object * exception=0x1e1b9888, const
char * string=0x1e18c358)  Zeile 77 + 0xd Bytes	C
 	python30.dll!find_module(char * fullname=0x0021fcc0, char *
subname=0x00000000, _object * path=0x00000000, char * buf=0x0021fb70,
unsigned int buflen=257, _iobuf * * p_fp=0x0021fb64, _object * *
p_loader=0x0021fb68)  Zeile 1228 + 0x10 Bytes	C
 	python30.dll!import_submodule(_object * mod=0x1e1c6a88, char *
subname=0x0021fcc0, char * fullname=0x00000000)  Zeile 2313 + 0x27 Bytes	C
 	python30.dll!load_next(_object * mod=0x1e1c6a88, _object *
altmod=0x1e1c6a88, char * * p_name=0x00000000, char * buf=0x0021fcc0,
int * p_buflen=0x0021fcbc)  Zeile 2127 + 0x15 Bytes	C
 	python30.dll!import_module_level(char * name=0x00000000, _object *
globals=0x00000000, _object * locals=0x1e069ec3, _object *
fromlist=0x00000000, int level=0)  Zeile 1908 + 0x1a Bytes	C
 	python30.dll!PyImport_ImportModuleLevel(char * name=0x1e184b04,
_object * globals=0x00000000, _object * locals=0x00000000, _object *
fromlist=0x00000000, int level=0)  Zeile 1979 + 0x18 Bytes	C
 	python30.dll!_PyCodecRegistry_Init()  Zeile 841 + 0x12 Bytes	C
 	python30.dll!PyCodec_LookupError(const char * name=0x00000000)  Zeile
436 + 0xc Bytes	C
 	python30.dll!unicode_decode_call_errorhandler(const char *
errors=0x00000000, _object * * errorHandler=0x00000009, const char *
encoding=0x1e1979ec, const char * reason=0x00000000, const char * *
input=0x0021fe80, const char * * inend=0x0021fe84, int *
startinpos=0x0021fe6c, int * endinpos=0x0021fe68, _object * *
exceptionObject=0x00000000, const char * * inptr=0x0021fe90, _object * *
output=0x0021fe70, int * outpos=0x0021fe88, unsigned short * *
outptr=0x0021fe74)  Zeile 1384 + 0xa Bytes	C
 	python30.dll!PyUnicodeUCS2_DecodeUTF8Stateful(const char *
s=0x1e1dd010, int size=48, const char * errors=0x00000000, int *
consumed=0x00000000)  Zeile 1967 + 0x47 Bytes	C
 	python30.dll!PyUnicodeUCS2_FromStringAndSize(const char *
u=0x1e1dd008, int size=48)  Zeile 464 + 0xb Bytes	C
 	python30.dll!PyUnicodeUCS2_FromString(const char * u=0x1e1dd008) 
Zeile 482 + 0x7 Bytes	C
 	python30.dll!_PySys_Init()  Zeile 1084 + 0xb Bytes	C
 	python30.dll!Py_InitializeEx(int install_sigs=1)  Zeile 220	C
 	python30.dll!Py_Initialize()  Zeile 292 + 0x7 Bytes	C
 	python30.dll!Py_Main(int argc=2, char * * argv=0x00000001)  Zeile 432	C
>	python.exe!mainCRTStartup()  Zeile 398 + 0xe Bytes	C
 	kernel32.dll!7c816fd7()

----------
components: Interpreter Core
messages: 56841
nosy: tiran
severity: normal
status: open
title: Crash on Windows if Python runs from a directory with umlauts
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Sat Oct 27 19:15:09 2007
From: report at bugs.python.org (Dean Sturtevant)
Date: Sat, 27 Oct 2007 17:15:09 -0000
Subject: [New-bugs-announce] [issue1344] subprocess.communication doc could
	use clarification
Message-ID: <1193505309.53.0.688990452376.issue1344@psf.upfronthosting.co.za>


New submission from Dean Sturtevant:

It would be helpful for the documentation for subprocess.communicate to
point out that when Popening a process, stdin=PIPE needs to be set if
the input parameter to communicate is to have any meaning. Similary,
stdout=PIPE and stderr=PIPE need to be set in order for the respective
component of the return value not to be None. That is, if that is indeed
correct (I observed this using Python 2.5 (r25:51908, Sep 19 2006,
09:52:17) [MSC v.1310 32 bit (Intel)] on win32)

----------
components: Documentation
messages: 56858
nosy: dsturtevant
severity: normal
status: open
title: subprocess.communication doc could use clarification
versions: Python 2.5

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

From report at bugs.python.org  Sat Oct 27 23:45:48 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 27 Oct 2007 21:45:48 -0000
Subject: [New-bugs-announce] [issue1345] Fix for test_netrc on Windows
Message-ID: <1193521548.65.0.259822939924.issue1345@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Index: Lib/test/test_netrc.py
===================================================================
--- Lib/test/test_netrc.py      (revision 58695)
+++ Lib/test/test_netrc.py      (working copy)
@@ -25,7 +25,7 @@
         mode = 'w'
         if sys.platform not in ['cygwin']:
             mode += 't'
-        fp = open(temp_filename, mode)
+        fp = open(temp_filename, mode, newline='')
         fp.write(TEST_NETRC)
         fp.close()

----------
components: Library (Lib)
messages: 56863
nosy: tiran
severity: normal
status: open
title: Fix for test_netrc on Windows
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct 28 00:33:15 2007
From: report at bugs.python.org (Dale)
Date: Sat, 27 Oct 2007 22:33:15 -0000
Subject: [New-bugs-announce] [issue1346] Error using >>> from OpenGL.GLUT
	import *
Message-ID: <1193524395.52.0.467041983847.issue1346@psf.upfronthosting.co.za>


New submission from Dale:

I get the response shown below when trying to use OpenGL. I have Python 
2.5, PIL-1.1.6, and PyOpenGL 3.0 installed.
Any help would be greatly appreciated.

Thanks,
Dale


>>> from OpenGL.GLUT import *

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    from OpenGL.GLUT import *
  File "build\bdist.win32\egg\OpenGL\GLUT\__init__.py", line 4, in 
<module>
  File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in 
<module>
AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow'
>>> 



__init__.py line 4 is;

from OpenGL.GLUT.special import *


special.py line 73 is;

_base_glutDestroyWindow = GLUT.glutDestroyWindow

----------
components: Windows
messages: 56866
nosy: neuralsensor
severity: normal
status: open
title: Error using >>> from OpenGL.GLUT import *
type: compile error
versions: Python 2.5

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

From report at bugs.python.org  Sun Oct 28 02:06:36 2007
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 28 Oct 2007 00:06:36 -0000
Subject: [New-bugs-announce] [issue1347] BaseHTTPServer writing strings to
	bytes interface
Message-ID: <1193529996.43.0.859664216454.issue1347@psf.upfronthosting.co.za>


New submission from Bill Janssen:

A number of places in the BaseHTTPServer got missed when converting 
between bytes and strings.  Here's a patch to fix that.

----------
components: Library (Lib)
files: a
messages: 56868
nosy: janssen
severity: normal
status: open
title: BaseHTTPServer writing strings to bytes interface
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8636/a

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1347>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a
Type: application/octet-stream
Size: 2090 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071028/83805cf7/attachment.obj 

From report at bugs.python.org  Sun Oct 28 02:49:13 2007
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 28 Oct 2007 00:49:13 -0000
Subject: [New-bugs-announce] [issue1348] httplib closes socket,
	then tries to read from it
Message-ID: <1193532553.16.0.237482805264.issue1348@psf.upfronthosting.co.za>


New submission from Bill Janssen:

I can't get urllib.urlopen() to work with SSL, and it seems to be due to 
a bug in the re-write of httplib.  HTTPConnection.getresponse() is 
closing the socket, but then returning a response object holding onto 
that closed socket to the caller, who then tries to read from the 
(closed) socket.  Due to the delayed closing of sockets, this error is 
masked, but in SSL, the context is torn down on close, so we see real 
failures.

----------
components: Library (Lib)
keywords: py3k
messages: 56870
nosy: janssen
priority: urgent
severity: normal
status: open
title: httplib closes socket, then tries to read from it
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sun Oct 28 02:33:21 2007
From: report at bugs.python.org (Bill Janssen)
Date: Sun, 28 Oct 2007 01:33:21 -0000
Subject: [New-bugs-announce] [issue1349] more uses of ord() in plat-mac/ic.py
Message-ID: <1193535201.15.0.846048268818.issue1349@psf.upfronthosting.co.za>


New submission from Bill Janssen:

Neal, a patch to get rid of the other ord() calls in ic.py.

----------
assignee: nnorwitz
components: Library (Lib), Macintosh
files: d
keywords: py3k
messages: 56872
nosy: janssen, nnorwitz
priority: high
severity: normal
status: open
title: more uses of ord() in plat-mac/ic.py
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8639/d

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d
Type: application/octet-stream
Size: 1274 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071028/bc067385/attachment.obj 

From report at bugs.python.org  Sun Oct 28 03:59:54 2007
From: report at bugs.python.org (Tal Einat)
Date: Sun, 28 Oct 2007 02:59:54 -0000
Subject: [New-bugs-announce] [issue1350] IDLE - CallTips enhancement - show
	full doc-string in new window
Message-ID: <1193540394.75.0.209428889105.issue1350@psf.upfronthosting.co.za>


New submission from Tal Einat:

This (relatively speaking) simple patch allows the full doc-string of a
callable to be displayed in a textView window. Once a call-tip is being
displayed, hitting one of the keys which is bound to the
force-open-calltip virtual event (Control-backslash by default) opens
the new window. If there is no extra documentation to be shown (in
addition to what is already shown in the call-tip), the window is not
displayed.

----------
components: IDLE
files: IDLE_CallTips.071028.patch
messages: 56876
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - CallTips enhancement - show full doc-string in new window
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file8641/IDLE_CallTips.071028.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1350>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_CallTips.071028.patch
Type: application/octet-stream
Size: 5961 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071028/ad9f917a/attachment-0001.obj 

From report at bugs.python.org  Sun Oct 28 12:09:43 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Oct 2007 11:09:43 -0000
Subject: [New-bugs-announce] [issue1351] Add getsize() to io instances
Message-ID: <1193569783.49.0.578170746692.issue1351@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I always missed a getsize() method on file objects. The patch adds a
method getsize() to all io instances. The method returns a SizeInfo
object which can print a human readable name or the bare size in bytes.
The method is using os.fstat and falls back to the seek(0,2), tell()
pattern.

>>> f = open("/etc/passwd")
>>> f.getsize()
<SizeInfo 1.7 KiB>
>>> int(f.getsize())
1721
>>> str(f.getsize())
'1.7 KiB'
>>> (f.getsize().sizeinfo())
(1.681, 1)

I'm going to provide unit tests and documentation if you like the feature.

----------
components: Library (Lib)
files: py3k_sizeinfo.patch
messages: 56877
nosy: tiran
severity: normal
status: open
title: Add getsize() to io instances
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8642/py3k_sizeinfo.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1351>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_sizeinfo.patch
Type: text/x-diff
Size: 2276 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071028/e7543558/attachment.patch 

From report at bugs.python.org  Sun Oct 28 14:51:14 2007
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 28 Oct 2007 13:51:14 -0000
Subject: [New-bugs-announce] [issue1352] Preliminary stderr patch
Message-ID: <1193579474.79.0.743146991528.issue1352@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Here is another patch related to stdio from me. It creates and sets up a
very dumb and easy stderr writer until the new io infrastructure is
initialized. It makes debugging problems in the init phase much easier.

----------
components: Interpreter Core
files: py3k_preliminary_stderr.patch
messages: 56880
nosy: tiran
severity: normal
status: open
title: Preliminary stderr patch
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8644/py3k_preliminary_stderr.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1352>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: py3k_preliminary_stderr.patch
Type: text/x-diff
Size: 4310 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071028/8ddad3f4/attachment.patch 

From report at bugs.python.org  Mon Oct 29 11:54:36 2007
From: report at bugs.python.org (Jacob)
Date: Mon, 29 Oct 2007 10:54:36 -0000
Subject: [New-bugs-announce] [issue1353] mp4 missing from mimetypes.py
Message-ID: <1193655276.24.0.947404053059.issue1353@psf.upfronthosting.co.za>


New submission from Jacob:

mp4 is missing from the mimetypes.py list of valid mimetypes. mp4 is 
registered with IANA and is defined in the mpeg-4 standard as a container 
for mpeg-4 codecs such as h264. Lack of this definition means the format 
cannot be recognised by software dependsing on the mimetypes modules, that 
don't use one of the suggested local mime definitions (OpenBSD).

----------
components: Library (Lib)
files: mimetypes.py.patch
messages: 56900
nosy: kraft
severity: normal
status: open
title: mp4 missing from mimetypes.py
type: rfe
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file8649/mimetypes.py.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mimetypes.py.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071029/7f67641f/attachment.txt 

From report at bugs.python.org  Mon Oct 29 12:16:05 2007
From: report at bugs.python.org (Raja R)
Date: Mon, 29 Oct 2007 11:16:05 -0000
Subject: [New-bugs-announce] [issue1354] windows installer problem
Message-ID: <1193656564.93.0.383203609595.issue1354@psf.upfronthosting.co.za>


New submission from Raja R:

Hi,
  I downloaded the python-2.5.msi yesterday and tried installing it 
but i am getting the following error "This installation package could 
not be opened . cOntact the application vendor to verify that this is 
a valid WIndows Installer package."

I was able to install python 2.4.4 successfully in my system. I want 
python 2.5 urgently as I need to work in PyQt.

My machine config is: Microsoft Windows XP, Media Center Edition 
Version 2002, Service Pack 2. 

Please advice on this problem at the earliest.

Thanks,
Raja.

----------
components: Installation
messages: 56901
nosy: rajar
severity: urgent
status: open
title: windows installer problem
versions: Python 2.5

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

From report at bugs.python.org  Mon Oct 29 13:23:02 2007
From: report at bugs.python.org (whooey1830)
Date: Mon, 29 Oct 2007 12:23:02 -0000
Subject: [New-bugs-announce] [issue1355] xml.dom refers to PyXML,
	which is no longer maintained
Message-ID: <1193660582.0.0.373333913487.issue1355@psf.upfronthosting.co.za>


New submission from whooey1830:

http://docs.python.org/dev/library/xml.dom.html#module-xml.dom

"PyXML
    Users that require a full-featured implementation of DOM should use
the PyXML package."

PyXML however is no longer maintained. Is it a wise idea to link to that
resource? Novice users might trust blindly, before finding out about the
restrictions they are going to face (maintainence, code fixes..) I
suggest adding at least information, that no code fixes are being done,
but documentation on the pyxml website is still updated (Thats how i've
understood their website. Please correct me if i am wrong. I'm feeling a
bit frustrated having spent time with a package, which is no longer
maintained, to be honest.)

----------
components: Documentation
messages: 56902
nosy: whooey1830
severity: normal
status: open
title: xml.dom refers to PyXML, which is no longer maintained
versions: Python 2.5

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

From report at bugs.python.org  Mon Oct 29 17:35:45 2007
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 29 Oct 2007 16:35:45 -0000
Subject: [New-bugs-announce] [issue1356] 3.0a1 Solaris w/ SUN C/C++
Message-ID: <1193675745.64.0.802991254571.issue1356@psf.upfronthosting.co.za>


New submission from Jean Brouwers:

Building 3.0a1 on Solaris 10 using SUN's C/C++ compilers fails due to 
one compilation error.

The problem is the name of the last argument 'restrict' of function 
analyze_cells on line 473 in file Python/symtable.c.  Changing that name 
to something else like 'restricted' makes the build build.

There is an '*** Error code 1' at the very end of  make test, but that 
is a separate issue.   

The ./configure command line needs to include the options  --without-gcc 
and  --with-cxx-main=CC.

This is Solaris 10 on an Ultra 20 (Opteron) machine with SUN C/C++ 5.8 
2005/10/13.

----------
components: Build
messages: 56908
nosy: MrJean1
severity: normal
status: open
title: 3.0a1 Solaris w/ SUN C/C++
type: compile error
versions: Python 3.0

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

From report at bugs.python.org  Mon Oct 29 18:08:03 2007
From: report at bugs.python.org (Jean Brouwers)
Date: Mon, 29 Oct 2007 17:08:03 -0000
Subject: [New-bugs-announce] [issue1357] 3.0a1 make test Error on Solaris w/
	SUN C/C++
Message-ID: <1193677683.71.0.404085069091.issue1357@psf.upfronthosting.co.za>


New submission from Jean Brouwers:

The 3.0a1 Solaris build (see issue #1356) fails at the end of  make test 
with the following error:

....
test_zlib
278 tests OK.
5 tests failed:
    test_cookielib test_email test_fileio test_pipes test_uuid
39 tests skipped:
    test_aepack test_applesingle test_bsddb test_bsddb3
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_ctypes test_curses
    test_gdbm test_hashlib test_hmac test_macostools
    test_normalization test_ossaudiodev test_pep277 test_plistlib
    test_scriptpackages test_socket_ssl test_socketserver test_sqlite
    test_ssl test_startfile test_sundry test_tarfile test_tcl
    test_timeout test_unicode_file test_unicodedata test_urllib2
    test_urllib2_localnet test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
11 skips unexpected on sunos5:
    test_hashlib test_hmac test_urllib2_localnet test_urllib2net
    test_ctypes test_urllib2 test_tcl test_sundry test_ssl
    test_tarfile test_unicodedata
*** Error code 1
make: Fatal error: Command failed for target `test'

The entire log of  make test is attached.  If you need other make or  
configure logs or if I should rebuild with other options, let me know.

----------
components: Tests
files: log.make_test
messages: 56910
nosy: MrJean1
severity: normal
status: open
title: 3.0a1 make test Error on  Solaris w/ SUN C/C++
versions: Python 3.0
Added file: http://bugs.python.org/file8652/log.make_test

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1357>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.make_test
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071029/e356c028/attachment-0001.txt 

From report at bugs.python.org  Mon Oct 29 19:14:49 2007
From: report at bugs.python.org (andres)
Date: Mon, 29 Oct 2007 18:14:49 -0000
Subject: [New-bugs-announce] [issue1358] Compile error on OS X 10.5
Message-ID: <1193681689.41.0.805287335304.issue1358@psf.upfronthosting.co.za>


New submission from andres:

Compiling python 2.5.1 on Mac OS X 10.5 (Leopard) fails with the
following message:

gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
-mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes  -I.
-I./Include   -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o
Modules/posixmodule.o
./Modules/posixmodule.c: In function ?posix_setpgrp?:
./Modules/posixmodule.c:3592: error: too few arguments to function ?setpgrp?
make: *** [Modules/posixmodule.o] Error 1

I am also attaching the output of the configuration script.

----------
components: Macintosh
files: configure.txt
messages: 56921
nosy: andres
severity: major
status: open
title: Compile error on OS X 10.5
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file8655/configure.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1358>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20071029/ecf79fa2/attachment.txt 

From report at bugs.python.org  Mon Oct 29 22:21:29 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Oct 2007 21:21:29 -0000
Subject: [New-bugs-announce] [issue1359] py3k: out of bounds read in
	PyUnicode_DecodeUnicodeEscape
Message-ID: <1193692889.31.0.0582486390862.issue1359@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

A correction for the problem found by GvR in change 58692:

> There's one mystery: if I remove ob_sstate from the PyStringObject struct,
> some (unicode) string literals are mutilated, e.g. ('\\1', '\1') prints
> ('\\1', '\t').  This must be an out of bounds write or something that I
> can't track down.  (It doesn't help that it doesn't occur in debug mode.
> And no, make clean + recompilation doesn't help either.)
> 
> So, in the mean time, I just keep the field, renamed to 'ob_placeholder'.

I think I found the problem. It reproduces on Windows, with a slightly
different input
    >>> ('\\2','\1')
    ('\\2', '\n')
(the win32 release build is of the kind "optimized with debug info", so
using the debugger is possible)

The problem is in unicodeobject.c::PyUnicode_DecodeUnicodeEscape:
- the input buffer is not null-terminated
- when decoding octal escape, we increment s without checking if it is
still in the limits.
In my case, the "\1" was followed by a "2" in memory, hence the bogus
chr(0o12) == '\n'.

Also corrected a potential problem when the string ends with a \:
PyUnicode_DecodeUnicodeEscape("\\t", 1) should return an error.

----------
components: Interpreter Core
files: unicodeEscape.diff
messages: 56933
nosy: amaury.forgeotdarc, gvanrossum
severity: normal
status: open
title: py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape
versions: Python 3.0
Added file: http://bugs.python.org/file8658/unicodeEscape.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1359>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unicodeEscape.diff
Type: application/octet-stream
Size: 1688 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071029/a1541f32/attachment.obj 

From report at bugs.python.org  Tue Oct 30 01:06:30 2007
From: report at bugs.python.org (Daniele Varrazzo)
Date: Tue, 30 Oct 2007 00:06:30 -0000
Subject: [New-bugs-announce] [issue1360] Queue.get() can't be interrupted
	with Ctrl-C unless timed out
Message-ID: <1193702790.06.0.592600873674.issue1360@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

This issue probably depends on #1167930

When waiting on a queue in blocking mode, in no timeout is set, ctrl-C
doesn't raise KeyboardInterrupt::

    q = Queue()
    q.get(True)
    # ctrl-c doesn't work here

If any timeout is set, ctrl-c works as expected::

    q = Queue()
    ONEYEAR = 365 * 24 * 60 * 60
    q.get(True, ONEYEAR)
    # ctrl-c works here

    Traceback (most recent call last):
    File "queuebug.py", line 6, in <module>
        q.get(True, ONEYEAR)
    File "/usr/lib/python2.5/Queue.py", line 174, in get
        self.not_empty.wait(remaining)
    File "/usr/lib/python2.5/threading.py", line 233, in wait
        _sleep(delay)
    KeyboardInterrupt

----------
components: Library (Lib)
messages: 56942
nosy: piro
severity: normal
status: open
title: Queue.get() can't be interrupted with Ctrl-C unless timed out
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 30 01:56:13 2007
From: report at bugs.python.org (Eric Hopper)
Date: Tue, 30 Oct 2007 00:56:13 -0000
Subject: [New-bugs-announce] [issue1361] hashlib uses OpenSSL which is much
	slower than Aaron Gifford
Message-ID: <1193705773.8.0.670166527886.issue1361@psf.upfronthosting.co.za>


New submission from Eric Hopper:

Aaron Gifford's implementation of SHA-{256,384,512} is nearly twice as
fast as OpenSSLs.

----------
components: Extension Modules
messages: 56946
nosy: Omnifarious
severity: normal
status: open
title: hashlib uses OpenSSL which is much slower than Aaron Gifford
type: resource usage
versions: Python 2.5

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

From report at bugs.python.org  Tue Oct 30 01:56:54 2007
From: report at bugs.python.org (Dan M)
Date: Tue, 30 Oct 2007 00:56:54 -0000
Subject: [New-bugs-announce] [issue1362] Simple mistake in
	http://docs.python.org/tut/node6.html
Message-ID: <1193705814.05.0.19491362552.issue1362@psf.upfronthosting.co.za>


New submission from Dan M:

In section 4.6 it says:
Writing the value None is normally suppressed by the interpreter if it
would be the only value written.

When it should say:
Writing the value None is normally displayed by the interpreter if it
would be the only value written.

Or less wordy:
The value None is (normally) displayed by the interpreter when it would
be the only value written.

----------
components: Documentation
messages: 56948
nosy: dmazz
severity: minor
status: open
title: Simple mistake in http://docs.python.org/tut/node6.html

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

From report at bugs.python.org  Tue Oct 30 19:18:10 2007
From: report at bugs.python.org (Paul)
Date: Tue, 30 Oct 2007 18:18:10 -0000
Subject: [New-bugs-announce] [issue1363] python 2.4.4 fails on solaris
	(sun4u sparc SUNW, Sun-Fire-880)
Message-ID: <1193768290.81.0.981284051139.issue1363@psf.upfronthosting.co.za>


New submission from Paul:

Trying to compile Plone (3.0.2) on a Sun V880 (SunOS genome 5.10
Generic_125100-05 sun4u sparc SUNW,Sun-Fire-880).  Plone is a web
application which runs on the Zope framework. What fails is the python
(2.4.4) which is distributed with Zope.

During the configure step of the build, I receive the following warning:

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



Then this nasty error breaks the entire config:


******BEGIN Snippet
checking size of int... configure: error: cannot compute sizeof (int), 77
See `config.log' for more details.
******END Snippet

----------
components: Build
messages: 56972
nosy: theoryno3
severity: normal
status: open
title: python 2.4.4 fails on solaris (sun4u sparc SUNW,Sun-Fire-880)
versions: Python 2.4

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

From report at bugs.python.org  Wed Oct 31 04:11:12 2007
From: report at bugs.python.org (billiejoex)
Date: Wed, 31 Oct 2007 03:11:12 -0000
Subject: [New-bugs-announce] [issue1364] os.lstat documentation error
Message-ID: <1193800272.82.0.918454638792.issue1364@psf.upfronthosting.co.za>


New submission from billiejoex:

os module documentation says about lstat():

> lstat( path) 
> 
> Like stat(), but do not follow symbolic links. 
> Availability: Macintosh, Unix. 

This is not true since os.lstat() is also available under Windows
(tested under Win XP sp, Python 2.5).

Moreover, wouldn't it be better having os.lstat() available on all
platforms and turn it into an alias of os.stat on those platforms which
do not support symbolic links?

----------
components: Documentation
messages: 56982
nosy: billiejoex
severity: normal
status: open
title: os.lstat documentation error
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct 31 10:50:11 2007
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 31 Oct 2007 09:50:11 -0000
Subject: [New-bugs-announce] [issue1365] bytes(<int>) constructor
Message-ID: <1193824211.16.0.246660638775.issue1365@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Hey Guido!

During my testing and local modifications of the PEP 3137 branch I found
a bunch of unit tests that were choking on bytes(1) where bytes is PyString.

The PEP doesn't list bytes(<int>) as a valid constructor, only
buffer(<int>). I don't see a reason why bytes() shouldn't accept an int
when b'1' still creates a byte sequence with 3 elements. Here is a patch

----------
components: Interpreter Core
messages: 56990
nosy: gvanrossum, tiran
severity: normal
status: open
title: bytes(<int>) constructor
type: rfe
versions: Python 3.0

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

From report at bugs.python.org  Wed Oct 31 10:59:43 2007
From: report at bugs.python.org (=?utf-8?q?Patrick_M=C3=A9zard?=)
Date: Wed, 31 Oct 2007 09:59:43 -0000
Subject: [New-bugs-announce] [issue1366] popen spawned process may not write
	to stdout under windows
Message-ID: <1193824783.73.0.865697244253.issue1366@psf.upfronthosting.co.za>


New submission from Patrick M?zard:

Let child.py be:
"""
import sys

sys.stdout.write('1:stdout\n')
sys.stdout.flush()
sys.stderr.write('2:stderr\n')
sys.stderr.flush()
sys.stdout.write('3:stdout\n')
sys.stdout.flush()
"""

and parent.py:
"""
import os

cmd = 'python child.py'
for l in os.popen(cmd):
    print l,
"""

Then running it:
"""
>python parent.py
1:stdout

>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
"""

I would have expected at least:
"""
1:stdout
3:stdout
"""
to be output, which actually happens if the stderr is nullified like
"python child.py 2>nul" in parent.py call.

Am I wrong ?

----------
components: Windows
messages: 56991
nosy: pmezard
severity: normal
status: open
title: popen spawned process may not write to stdout under windows
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Wed Oct 31 13:43:32 2007
From: report at bugs.python.org (anonyprog)
Date: Wed, 31 Oct 2007 12:43:32 -0000
Subject: [New-bugs-announce] [issue1367] mkdir+chdir problem in multiple
	threads
Message-ID: <1193834612.62.0.192544402104.issue1367@psf.upfronthosting.co.za>


New submission from anonyprog:

Under certain circumstances, creating a directory using os.mkdir then
immediately changing to it using os.chdir fails with a file not found
exception.

Here is some code to demonstrate that. Using the following program with
a parameter of 1 works fine. But anything greater than that and
exceptions occur in the first os.chdir until only one thread is left to
run completely.

Tested on Python 2.5.1 for Windows and Python 2.3.5 for Linux.

    # mkdirtest.py
    #
    # usage: mkdirtest <number of threads>

    import os, threading, sys

    x = int(sys.argv[1])

    class MkdirTest(threading.Thread):

        def __init__(self, t):
            threading.Thread.__init__(self)
            self.t = t
            print "new thread "+str(t)

        def run(self):
            for i in range(0,50):
                s = str(self.t)+"_"+str(i)
                print "mkdir "+s
                os.mkdir(s)
                os.chdir(s)
                os.chdir("..")
            print "end thread "+str(t)

    for t in range(0,x):
        print t
        a = MkdirTest(t)
        a.start()

----------
components: None
messages: 56992
nosy: anonyprog
severity: normal
status: open
title: mkdir+chdir problem in multiple threads
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Thu Oct 25 23:33:47 2007
From: report at bugs.python.org (Eric Sammons)
Date: Thu, 25 Oct 2007 21:33:47 -0000
Subject: [New-bugs-announce] [issue1327] Python 2.4+ spends too much time in
	PyEval_EvalFrame w/ xmlrpmclib
Message-ID: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za>


New submission from Eric Sammons:

Created a small program using xmlrpclib.  When connecting to one url
where my list is < 300 items and the program finishes no problem. 
Connect to another url where my list is over 500 items and the program
times out after 40+ minutes with no results printed.  On my RHEL system
I used oprofile and determined that time spent was in ceval.c, symbol
PyEval_EvalFrame. This issue seems to be new to Python 2.4 as shipped
with RHEL.  I am currently in the process of building non-RHEL python to
 verify issue does or does not exist there as well.

<code>
#!/usr/bin/env python

import xmlrpclib

u = 'someuser'
p = 'password'

server_url = 'http://rhn.redhat.com/rpc/api'

server = xmlrpclib.Server(server_url)

session = server.auth.login(u,p)

l = server.channel.listSoftwareChannels(session)
for a in l:
    print a['channel_label']
</code>

----------
components: Library (Lib), XML
files: ceval.c
messages: 56755
nosy: eanxgeek
severity: critical
status: open
title: Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file8611/ceval.c

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ceval.c
Type: text/x-csrc
Size: 176814 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071025/7b3d12df/attachment-0001.c