From report at bugs.python.org Wed Jul 1 05:56:12 2009
From: report at bugs.python.org (Matt)
Date: Wed, 01 Jul 2009 03:56:12 +0000
Subject: [New-bugs-announce] [issue6392] IDLE 3.1 will not open
In-Reply-To: <1246420572.02.0.605221544968.issue6392@psf.upfronthosting.co.za>
Message-ID: <1246420572.02.0.605221544968.issue6392@psf.upfronthosting.co.za>
New submission from Matt <matthall.oxford at gmail.com>:
IDLE will not open; it does not give an error or even appear on the
process list.
I am using Windows XP on an IBM Thinkpad. I tried the prescribed
solution on Issue 4049, and it returned this message:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Matt>cd \python31
C:\Python31>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
File "Lib\idlelib\idle.py", line 11, in <module>
idlelib.PyShell.main()
File "C:\Python31\Lib\idlelib\PyShell.py", line 1374, in main
root = Tk(className="Idle")
File "C:\Python31\Lib\tkinter\__init__.py", line 1632, in __init__
self.tk = _tkinter.create(screenName, baseName, className,
interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following
directories:
{C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTOOLS/Python22/tcl/tcl8.5
C:/Python3
1/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library
C:/tcl8.5.2/libra
ry C:/tcl8.5.2/library
C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl: version conflict for
package "Tcl": ha
ve 8.5.2, need exactly 8.4
version conflict for package "Tcl": have 8.5.2, need exactly 8.4
while executing
"package require -exact Tcl 8.4"
(file "C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl" line 19)
invoked from within
"source C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
C:\Python31>
I am very new to Python (and programming in general), and I have no
idea how to fix this.
By the way, I did install the program for all users.
----------
components: IDLE
messages: 89962
nosy: matthall
severity: normal
status: open
title: IDLE 3.1 will not open
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6392>
_______________________________________
From report at bugs.python.org Wed Jul 1 17:08:09 2009
From: report at bugs.python.org (Jon Anglin)
Date: Wed, 01 Jul 2009 15:08:09 +0000
Subject: [New-bugs-announce] [issue6394] getppid support in os module on
Windows
In-Reply-To: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
Message-ID: <1246460889.83.0.840180185924.issue6394@psf.upfronthosting.co.za>
New submission from Jon Anglin <janglin at fortresgrand.com>:
Implements getppid in the os module on Windows systems. The getppid
function was only available on Unix like systems, this diff patch brings
this functionality to Windows systems. This function will return the
parent process Id, upon error it will return -1. This differs from the
Unix implementation that never fails. Due to the way Windows returns the
parent process Id, a never fail guarantee can not be made. It should only
fail in low memory conditions. This patch is on the latest svn trunk (
http://svn.python.org/projects/python/trunk). This implementation should
port to any python version (older or newer). I have personally tested it
against Python 2.5.4, 2.6.2, 3.1, and the aforementioned svn trunk.
----------
components: Library (Lib)
files: mydiffs.diff
keywords: patch
messages: 89981
nosy: janglin
severity: normal
status: open
title: getppid support in os module on Windows
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14419/mydiffs.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6394>
_______________________________________
From report at bugs.python.org Wed Jul 1 18:14:07 2009
From: report at bugs.python.org (Mahmoud)
Date: Wed, 01 Jul 2009 16:14:07 +0000
Subject: [New-bugs-announce] [issue6396] No conversion specifier in the
string, no __getitem__ method in the right hand value
In-Reply-To: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
Message-ID: <1246464847.52.0.736883285817.issue6396@psf.upfronthosting.co.za>
New submission from Mahmoud <saghaei at med.mui.ac.ir>:
When using a class instance as a mapping for the right hand value in a
sting format expression without conversion specifier, it seems logical
that the class has a __getitem__ method. Therefore following format
expression should raise an exception.
>>> class AClass(object):
... pass
...
>>> c = AClass()
>>> "a string with no conversion specifier" % c
'a string with no conversion specifier'
----------
messages: 89987
nosy: msaghaei
severity: normal
status: open
title: No conversion specifier in the string, no __getitem__ method in the right hand value
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6396>
_______________________________________
From report at bugs.python.org Wed Jul 1 12:51:57 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 01 Jul 2009 10:51:57 +0000
Subject: [New-bugs-announce] [issue6393] OS X: python3 from python-3.1.dmg
crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
There was a report[1] on c.l.p. that python3 from the OS X Python 3.1
dmg download at www.python.org/download/releases/3.1/ crashes on
startup. I can reproduce this with the python.org download (using the
OS X Terminal) only with a bad locale setting:
newton:~ dickinsm$ LANG=utf-8 python3
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding:
Abort trap (core dumped)
The core dump isn't useful: just lots of 'No symbol table info
available.'
This is on OS X 10.5.7/Intel.
I can't reproduce it with either the py3k branch or the release31-maint
branch, built from scratch.
I suspect that this has to do with the behaviour of nl_langinfo(CODESET)
on OS X: namely, after doing (in C) setlocale(LC_CTYPE, ""), the result
of nl_langinfo(CODESET) appears to be "UTF-8" for well-defined utf-8
locales (e.g., 'en_US.UTF-8'), "US-ASCII" for meaningless locales (e.g.,
'invalid'), but one just gets "" for locales like 'utf-8' or 'en_US'.
This in turn affects Python's locale.getpreferredencoding function.
See also issue 2173, which may be related.
Ronald, any ideas?
[1] http://mail.python.org/pipermail/python-list/2009-June/718255.html
----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 89972
nosy: marketdickinson, ronaldoussoren
severity: normal
status: open
title: OS X: python3 from python-3.1.dmg crashes at startup
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6393>
_______________________________________
From report at bugs.python.org Wed Jul 1 17:46:28 2009
From: report at bugs.python.org (ThomasH)
Date: Wed, 01 Jul 2009 15:46:28 +0000
Subject: [New-bugs-announce] [issue6395] Add Pickle Support to the codecs
Module
In-Reply-To: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
Message-ID: <1246463188.35.0.320675118154.issue6395@psf.upfronthosting.co.za>
New submission from ThomasH <thomas.bugzilla at gmx.net>:
I recently ran into an infinite recursion trying to unpickle a
codecs.StreamWriter object (I presume the issue would be the same for a
StreamReader).
Here is the end of the stack trace:
? File "/sw/lib/python2.5/codecs.py", line 330, in __getattr__? ?
? ? return getattr(self.stream, name)
? File "/sw/lib/python2.5/codecs.py", line 330, in __getattr__?
? ? return getattr(self.stream, name)?
? File "/sw/lib/python2.5/codecs.py", line 330, in __getattr__?
? ? return getattr(self.stream, name)?
RuntimeError: maximum recursion depth exceeded
The issue is the same under Python2.6 but the error output has changed
(see http://bugs.python.org/issue5508).
The problem is that the codecs module tries to delegate member lookup to
the underlying stream. But after unpickling, "self.stream" is not
defined, so the reference to self.stream in __getattr__ itself leads to
an invocation of __getattr__ - hence the recursion loop.
Using tools from the Pickle protocol, like __getstate__/__setstate__,
could help degrade codecs objects gracefully during pickle/unpickle
cycles. E.g. it might be enough to provide a dummy self.stream through
__setstate__.
----------
components: Library (Lib)
messages: 89985
nosy: ThomasH
severity: normal
status: open
title: Add Pickle Support to the codecs Module
type: crash
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6395>
_______________________________________
From report at bugs.python.org Wed Jul 1 18:49:15 2009
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 01 Jul 2009 16:49:15 +0000
Subject: [New-bugs-announce] [issue6397] Implementing Solaris "poll" in the
"select" module
In-Reply-To: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
Message-ID: <1246466955.08.0.134631976531.issue6397@psf.upfronthosting.co.za>
New submission from Jes?s Cea Avi?n <jcea at jcea.es>:
In Python 2.6 we added support for Linux "epoll" and *BSD "kqueue" in
the select module. I think we should add support for Solaris "poll"
interface too.
What do you think?.
I volunteer to do the work, if you agree this is a feature we want to
have. I think so.
----------
assignee: jcea
components: Library (Lib)
messages: 89989
nosy: jcea
severity: normal
stage: needs patch
status: open
title: Implementing Solaris "poll" in the "select" module
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6397>
_______________________________________
From report at bugs.python.org Wed Jul 1 22:30:45 2009
From: report at bugs.python.org (Nathan Michaels)
Date: Wed, 01 Jul 2009 20:30:45 +0000
Subject: [New-bugs-announce] [issue6398] README typo
In-Reply-To: <1246480245.72.0.392053113431.issue6398@psf.upfronthosting.co.za>
Message-ID: <1246480245.72.0.392053113431.issue6398@psf.upfronthosting.co.za>
New submission from Nathan Michaels <nmichaels at gmail.com>:
There's a typo in the README in the 2.6 source root. "versio" on line
942 should be "version".
----------
assignee: georg.brandl
components: Documentation
files: fix.diff
keywords: patch
messages: 89998
nosy: georg.brandl, nmichaels
severity: normal
status: open
title: README typo
versions: Python 2.6
Added file: http://bugs.python.org/file14423/fix.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6398>
_______________________________________
From report at bugs.python.org Thu Jul 2 11:50:31 2009
From: report at bugs.python.org (Mike)
Date: Thu, 02 Jul 2009 09:50:31 +0000
Subject: [New-bugs-announce] [issue6399] Error reporting by
logging.config.fileConfig()
In-Reply-To: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
Message-ID: <1246528231.33.0.0905986098741.issue6399@psf.upfronthosting.co.za>
New submission from Mike <python at amadron.com>:
Hi,
I had a logging.conf file with the following logger def in it:
[logger_Builder]
level=DEBUG
handlers=consoleStderr
qualname=Builder
propogate=0
And I couldn't understand why all my log messages were coming out twice.
It took me four hours :-\ to realise I had misspelt "propagate".
Wouldn't it be better if spurious names raised parsing exceptions?
Thanks,
Mike.
P.S. Another thing that might have helped me track this down a little
quicker is if I could have printed the name of the logger that was the
source of some output. %(name)s gives the logger that *received* the log
message. If there was another format variable for the logger that was
the source of a log message I would have seen one message from Builder
and one message from root and it would have been more obvious what was
going on.
----------
components: Extension Modules
messages: 90007
nosy: mike
severity: normal
status: open
title: Error reporting by logging.config.fileConfig()
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6399>
_______________________________________
From report at bugs.python.org Thu Jul 2 15:09:39 2009
From: report at bugs.python.org (Alejandro)
Date: Thu, 02 Jul 2009 13:09:39 +0000
Subject: [New-bugs-announce] [issue6400] incorrect commands import
In-Reply-To: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
Message-ID: <1246540179.08.0.172564067781.issue6400@psf.upfronthosting.co.za>
New submission from Alejandro <alejolp at alejolp.com>:
I'm porting a project to Py3k wich contains a "commands.py" script on
the project's module.
Inside "a.py" there is an "import commands" statement:
/mymodule/commands.py
/mymodule/a.py
The 2to3 tool replaces the "import commands" and all the "commands"
ocurrences with the word "subprocess".
Is is possible to adapt the fix_imports fixer to detect a local import,
like the fix_import fixer (probably_a_local_import)?
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90010
nosy: alejolp
severity: normal
status: open
title: incorrect commands import
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6400>
_______________________________________
From report at bugs.python.org Thu Jul 2 15:56:25 2009
From: report at bugs.python.org (j_pok)
Date: Thu, 02 Jul 2009 13:56:25 +0000
Subject: [New-bugs-announce] [issue6401] Unexpected module garbage collection
In-Reply-To: <1246542985.56.0.681737783337.issue6401@psf.upfronthosting.co.za>
Message-ID: <1246542985.56.0.681737783337.issue6401@psf.upfronthosting.co.za>
New submission from j_pok <pystole at gmail.com>:
This code does not behave as I expected. Removing module from
sys.modules and from local variable causes garbage collection (?) of
module in spite of there is an instance of a class from this module.
Instance method test() from TestClass returns global variable contained
in module.
import sys
module = __import__("broken_module")
instance = module.TestClass()
print("a: "+str(instance.test()))
del sys.modules["broken_module"]
print("b: "+str(instance.test()))
del module
print("c: "+str(instance.test()))
Output:
a: test
b: test
c: None
----------
components: None
files: broken_module.py
messages: 90011
nosy: j_pok
severity: normal
status: open
title: Unexpected module garbage collection
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14426/broken_module.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6401>
_______________________________________
From report at bugs.python.org Thu Jul 2 18:54:26 2009
From: report at bugs.python.org (Jan Lieskovsky)
Date: Thu, 02 Jul 2009 16:54:26 +0000
Subject: [New-bugs-announce] [issue6402] Crash after attempt to set the
error indicator via PyErr_SetString()
In-Reply-To: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
Message-ID: <1246553666.48.0.84202001291.issue6402@psf.upfronthosting.co.za>
New submission from Jan Lieskovsky <iankko at seznam.cz>:
Hello guys,
i am experiencing segmentation fault, when trying to set the
error indicator via the PyErr_SetString() method called from C source.
This occurs for all Python exceptions, as documented in:
http://docs.python.org/c-api/exceptions.html
Checked Python-2.6.2, also Python-2.4.1 - the crash is present
there (wondering what's wrong with the provided reproducer).
Scenario:
--------
tar xvzf pyexceptions-sample.tar.gz
cd pyexceptions-sample
make
./pyexceptionssample ->
Segmentation fault (core dumped)
Note: Doesn't matter if compiled with libpython2.6.a or libpython2.4.so,
the crash is still there.
Here is the most interesting part of the backtrace (the whole
coredump also attached).
gdb ./pyexceptions-sample core.31283
Core was generated by `./pyexceptions-sample'.
Program terminated with signal 11, Segmentation fault.
[New process 31283]
#0 PyErr_Restore (type=0x60000000000058f0, value=0x2000000000435030,
traceback=0x0) at Python/errors.c:39
39 oldtype = tstate->curexc_type;
(gdb) bt
#0 PyErr_Restore (type=0x60000000000058f0, value=0x2000000000435030,
traceback=0x0) at Python/errors.c:39
#1 0x4000000000125180 in PyErr_SetString (exception=0x60000000000058f0,
string=<value optimized out>) at Python/errors.c:57
#2 0x4000000000005eb0 in check_value ()
#3 0x4000000000006670 in main ()
(gdb) info args
type = (PyObject *) 0x60000000000058f0
value = (PyObject *) 0x2000000000435030
traceback = (PyObject *) 0x0
(gdb) info locals
tstate = (PyThreadState *) 0x0
oldtype = <value optimized out>
oldvalue = <value optimized out>
oldtraceback = <value optimized out>
(Looks like NULL ptr dereference in tstate = (PyThreadState *)).
Could you please have a look?
Thanks && regards, Jan.
--
Jan iankko Lieskovsky
----------
components: Interpreter Core
files: pyexceptions-sample.tar.gz
messages: 90026
nosy: iankko
severity: normal
status: open
title: Crash after attempt to set the error indicator via PyErr_SetString()
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14428/pyexceptions-sample.tar.gz
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6402>
_______________________________________
From report at bugs.python.org Thu Jul 2 22:26:45 2009
From: report at bugs.python.org (ivank)
Date: Thu, 02 Jul 2009 20:26:45 +0000
Subject: [New-bugs-announce] [issue6403] distutils builds extension modules
to root package directory
In-Reply-To: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
Message-ID: <1246566405.01.0.90148130878.issue6403@psf.upfronthosting.co.za>
New submission from ivank <ivan at ludios.org>:
When I built Twisted, I noticed that 'python2.7 setup.py build' created
_c_urlang.so in the wrong place:
$ find . | grep _c_url
./twisted/protocols/_c_urlarg.c
./build/lib.linux-x86_64-2.7/_c_urlarg.so
./build/temp.linux-x86_64-2.7/twisted/protocols/_c_urlarg.o
I noticed the same problem when I built Mercurial 1.3, too.
This happens with svn r73778, but not svn r73145 (June 2). I don't know
which commit caused the problem. I don't know if the problem is in 3.x too.
----------
assignee: tarek
components: Distutils
messages: 90034
nosy: ivank, tarek
severity: normal
status: open
title: distutils builds extension modules to root package directory
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6403>
_______________________________________
From report at bugs.python.org Fri Jul 3 01:57:52 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 02 Jul 2009 23:57:52 +0000
Subject: [New-bugs-announce] [issue6404] 3.1 NEWS.txt points to alpha 2 file
In-Reply-To: <1246579072.98.0.262073120436.issue6404@psf.upfronthosting.co.za>
Message-ID: <1246579072.98.0.262073120436.issue6404@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
On Thu, 02 Jul 2009 16:43:15 -0700, <webmaster at python.org> wrote:
> On Mon, Jun 29, 2009, Sridhar Ratnakumar wrote:
>>
>> From http://www.python.org/download/releases/3.1/NEWS.txt
>>
>> (...)
>>
>> What's New in Python 3.1 alpha 2?
>> =================================
>>
>> *Release date: 2009-4-4*
>
> AFAICT, this isn't maintained by webmasters, please submit a report to
> bugs.python.org
----------
assignee: georg.brandl
components: Documentation
messages: 90038
nosy: georg.brandl, srid
severity: normal
status: open
title: 3.1 NEWS.txt points to alpha 2 file
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6404>
_______________________________________
From report at bugs.python.org Fri Jul 3 13:07:23 2009
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 03 Jul 2009 11:07:23 +0000
Subject: [New-bugs-announce] [issue6405] Redundant redeclarations in
descrobject.h
In-Reply-To: <1246619243.32.0.155882535989.issue6405@psf.upfronthosting.co.za>
Message-ID: <1246619243.32.0.155882535989.issue6405@psf.upfronthosting.co.za>
New submission from Floris Bruynooghe <floris.bruynooghe at gmail.com>:
There are redundant redeclarations for PyGetSetDescr_Type and
PyMemberDescr_Type in descrobject.h. This is an issue when compiling an
extension module with the -Wredundant-decls flag:
In file included from /usr/local/include/python3.1/Python.h:98,
from src/util.c:27:
/usr/local/include/python3.1/descrobject.h:76: error: redundant
redeclaration of ?PyGetSetDescr_Type?
/usr/local/include/python3.1/descrobject.h:71: error: previous
declaration of ?PyGetSetDescr_Type? was here
/usr/local/include/python3.1/descrobject.h:77: error: redundant
redeclaration of ?PyMemberDescr_Type?
/usr/local/include/python3.1/descrobject.h:72: error: previous
declaration of ?PyMemberDescr_Type? was here
error: command 'gcc' failed with exit status 1
The patch is trivial.
----------
components: Extension Modules
files: descrobject.diff
keywords: patch
messages: 90047
nosy: flub
severity: normal
status: open
title: Redundant redeclarations in descrobject.h
type: compile error
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14435/descrobject.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6405>
_______________________________________
From report at bugs.python.org Fri Jul 3 14:33:29 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Fri, 03 Jul 2009 12:33:29 +0000
Subject: [New-bugs-announce] [issue6406] NameError on 2to3 tool
In-Reply-To: <1246624409.35.0.327265047408.issue6406@psf.upfronthosting.co.za>
Message-ID: <1246624409.35.0.327265047408.issue6406@psf.upfronthosting.co.za>
New submission from Alejandro Santos <alejolp at alejolp.com>:
Using the -j switch of the 2to3 tool shiped with Python 3.1 final i'm
getting:
Traceback (most recent call last):
File "/home/alejo/apps/local/bin/2to3", line 6, in <module>
sys.exit(main("lib2to3.fixes"))
File "/home/alejo/apps/local/lib/python3.1/lib2to3/main.py", line 132,
in main
options.processes)
File "/home/alejo/apps/local/lib/python3.1/lib2to3/refactor.py", line
553, in refactor
for i in xrange(num_processes)]
NameError: global name 'xrange' is not defined
Attached patch seems to work fine.
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3-xrange.patch
keywords: patch
messages: 90048
nosy: alejolp, djc
severity: normal
status: open
title: NameError on 2to3 tool
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14436/2to3-xrange.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6406>
_______________________________________
From report at bugs.python.org Fri Jul 3 15:23:18 2009
From: report at bugs.python.org (Matthew Leon Grinshpun)
Date: Fri, 03 Jul 2009 13:23:18 +0000
Subject: [New-bugs-announce] [issue6407] multiprocessing Pool should allow
custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
New submission from Matthew Leon Grinshpun <vertespain at gmail.com>:
Multiprocessing's Pool class __init__ method is written in a way that
makes it very difficult for a subclass to modify self._taskqueue. There
are very good reasons for wanting to do this - ie, making the taskqueue
block when it reaches a certain size. It seems to me that simply moving
the taskqueue assignment into _setup_queues() would do the trick.
The following usenet group discussion contains further details:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e6c67a09fb20cdec#
----------
components: Library (Lib)
messages: 90052
nosy: masher
severity: normal
status: open
title: multiprocessing Pool should allow custom task queue
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________
From report at bugs.python.org Fri Jul 3 15:50:36 2009
From: report at bugs.python.org (Alejandro Santos)
Date: Fri, 03 Jul 2009 13:50:36 +0000
Subject: [New-bugs-announce] [issue6408] 2to3: Local package import
In-Reply-To: <1246629036.25.0.586773207888.issue6408@psf.upfronthosting.co.za>
Message-ID: <1246629036.25.0.586773207888.issue6408@psf.upfronthosting.co.za>
New submission from Alejandro Santos <alejolp at alejolp.com>:
The 2to3 tool shipped with Python 3.1 final doesn't handle correctly a
local package import (fixer fix_import). Test case:
$ find . -name '*.py'
./__init__.py
./a.py
./b/__init__.py
./b/m.py
$ 2to3 a.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.
$ cat a.py
from b import m
m.q()
Trying to use the 2to3 tool from one level up won't work either:
$ 2to3 test2to3/a.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No files need to be modified.
It seems to be a bug in the fixer, which is using the os.path.pathsep
constant when it should be using the os.path.sep instead.
The probably_a_local_import function is checking if "test2to3/b:"
exists, when it should be checking against: "test2to3/b/"
Attached patch seems to be working:
$ 2to3 test2to3/a.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- test2to3/a.py (original)
+++ test2to3/a.py (refactored)
@@ -1,5 +1,5 @@
-from b import m
+from .b import m
m.q()
RefactoringTool: Files that need to be modified:
RefactoringTool: test2to3/a.py
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3-os.path.sep.path
messages: 90055
nosy: alejolp, djc
severity: normal
status: open
title: 2to3: Local package import
versions: Python 3.1
Added file: http://bugs.python.org/file14437/2to3-os.path.sep.path
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6408>
_______________________________________
From report at bugs.python.org Fri Jul 3 17:53:46 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 03 Jul 2009 15:53:46 +0000
Subject: [New-bugs-announce] [issue6409] 2to3 generates malformed diffs
In-Reply-To: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
Message-ID: <1246636426.08.0.872531312657.issue6409@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
I ran 2to3 over Twisted r27084 like this:
time ~/Projects/python/trunk/python
/home/exarkun/Projects/python/trunk/Tools/scripts/2to3 -j 4 twisted/ >
2to3.patch
Visual inspection revealed some curious defects, and attempting to apply
it failed like this:
$ patch -p0 < 2to3.patch
patching file twisted/application/app.py
patching file twisted/conch/client/connect.py
patching file twisted/conch/client/default.py
patch: **** malformed patch at line 129: @@ -1,6 +1,6 @@
The resulting file is attached.
----------
components: Library (Lib)
files: 2to3.patch
keywords: patch
messages: 90064
nosy: exarkun
severity: normal
status: open
title: 2to3 generates malformed diffs
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file14441/2to3.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6409>
_______________________________________
From report at bugs.python.org Fri Jul 3 22:33:58 2009
From: report at bugs.python.org (Michael W.)
Date: Fri, 03 Jul 2009 20:33:58 +0000
Subject: [New-bugs-announce] [issue6410] Dictionaries should support __add__
In-Reply-To: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
Message-ID: <1246653238.95.0.314927755738.issue6410@psf.upfronthosting.co.za>
New submission from Michael W. <hotdog003 at gmail.com>:
Summary:
Dictionaries should support being added to other dictionaries instead of
using update(). This should be a relatively easy fix and would make the
language more pythonic.
How to reproduce:
$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> {1: 2, 3: 4} + {5: 6, 7: 8}
What happens:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'dict' and 'dict'
What should happen:
{1: 2, 3: 4, 5: 6, 7: 8}
Temporary workaround:
>>> a = {1: 2, 3: 4}
>>> b = {5: 6, 7: 8}
>>> c = a.copy()
>>> c.update(b)
>>> print c
{1: 2, 3: 4, 5: 6, 7: 8}
This is undesirable because it is not very compact and hard to read. Why
should any language take five lines of code to merge only two dictionaries?
----------
components: Interpreter Core
messages: 90074
nosy: hotdog003
severity: normal
status: open
title: Dictionaries should support __add__
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6410>
_______________________________________
From report at bugs.python.org Fri Jul 3 23:17:48 2009
From: report at bugs.python.org (corban)
Date: Fri, 03 Jul 2009 21:17:48 +0000
Subject: [New-bugs-announce] [issue6411] 3.1 not functional
In-Reply-To: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
Message-ID: <1246655868.68.0.634239679631.issue6411@psf.upfronthosting.co.za>
New submission from corban <element.effect at gmail.com>:
After downloading v. 3.1, I couldnt get it to perform even the most
simple functions. I am somewhat new to the programming so I dont know
if there is something simple that I am missing or if it is a possible
bug with the system.
----------
messages: 90076
nosy: element.effect
severity: normal
status: open
title: 3.1 not functional
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6411>
_______________________________________
From report at bugs.python.org Sat Jul 4 01:14:49 2009
From: report at bugs.python.org (Christoph Burgmer)
Date: Fri, 03 Jul 2009 23:14:49 +0000
Subject: [New-bugs-announce] [issue6412] Titlecase as defined in Unicode
Case Mappings not followed
In-Reply-To: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
Message-ID: <1246662889.32.0.498842923824.issue6412@psf.upfronthosting.co.za>
New submission from Christoph Burgmer <cburgmer at ira.uka.de>:
Titlecase, i.e. istitle() and title(), is buggy when the string
includes combining diacritical marks.
>>> u'H\u0301ngh'.istitle()
False
>>> u'H\u0301ngh'.title()
u'H\u0301Ngh'
>>>
The string given already is in titlecase so that the following result
is expected:
>>> u'H\u0301ngh'.istitle()
True
>>> u'H\u0301ngh'.title()
u'H\u0301ngh'
>>>
UTR#21 Case Mappings defines the following algorithm for titlecase
mapping [1]:
For each character C, find the preceding character B.
ignore any intervening case-ignorable characters when finding B.
If B exists, and is cased
map C to UCD_lower(C)
Otherwise,
map C to UCD_title(C)
The class of 'case-ignorable' is defined under [2] and includes
Nonspacing Marks (Mn) as listed in [3]. This includes diacritcal marks
and others. These should not be handled similar to spaces which they
currently are, thus dividing words.
A patch including the above test case is attached.
[1]
http://unicode.org/reports/tr21/tr21-5.html#Case_Conversion_of_Strings
[2] http://unicode.org/reports/tr21/tr21-5.html#Definitions
[3] http://www.fileformat.info/info/unicode/category/Mn/list.htm
----------
components: Library (Lib)
files: test_unicode.titlecase.diff
keywords: patch
messages: 90086
nosy: christoph
severity: normal
status: open
title: Titlecase as defined in Unicode Case Mappings not followed
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14443/test_unicode.titlecase.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6412>
_______________________________________
From report at bugs.python.org Sat Jul 4 04:00:37 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 04 Jul 2009 02:00:37 +0000
Subject: [New-bugs-announce] [issue6413] incorrect log level in
distutlis.dist for announce
In-Reply-To: <1246672837.63.0.0147126592432.issue6413@psf.upfronthosting.co.za>
Message-ID: <1246672837.63.0.0147126592432.issue6413@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
The correct level should be INFO
----------
assignee: tarek
messages: 90095
nosy: tarek
priority: normal
severity: normal
status: open
title: incorrect log level in distutlis.dist for announce
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6413>
_______________________________________
From report at bugs.python.org Sat Jul 4 09:46:30 2009
From: report at bugs.python.org (Karl Magdsick)
Date: Sat, 04 Jul 2009 07:46:30 +0000
Subject: [New-bugs-announce] [issue6414] struct module : processor
endianness descriptions misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
New submission from Karl Magdsick <kmagdsick at hotmail.com>:
In http://docs.python.org/dev/library/struct.html,
it says
"Native byte order is big-endian or little-endian, depending on the host
system. For example, Motorola and Sun processors are big-endian; Intel
and DEC processors are little-endian."
This is a gross over-generalization at best. Off the top of my head,
current Linux kernels run the Intel Itanium in big-endian mode. (Though,
I don't recall if there's a non-privileged instruction to flip
endianness, system headers and system calls are defined in big-endian
order, which is what's most relevant to the struct module.) Sun SPARC
v9 is bi-endian. Intel Itanium and XScale processors are bi-endian. Dec
Alphas are bi-endian. (Though, I'm only aware of Cray using Alphas in
big-endian mode.)
The quoted paragraph should name specific processors which are single-
endian (Intel Core 2, Sun SPARC v8) and/or provide a Wikipedia
reference, rather than making incorrect statements.
Intel Itanium machines running Linux are probably the most common
systems where this statement's inaccuracy is likely to cause confusion
among developers.
----------
assignee: georg.brandl
components: Documentation
messages: 90107
nosy: georg.brandl, kmag
severity: normal
status: open
title: struct module : processor endianness descriptions misleading
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________
From report at bugs.python.org Sat Jul 4 12:14:04 2009
From: report at bugs.python.org (wiesenth)
Date: Sat, 04 Jul 2009 10:14:04 +0000
Subject: [New-bugs-announce] [issue6415] warnings.warn segfaults on bad
formatted string
In-Reply-To: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
Message-ID: <1246702444.15.0.967525803194.issue6415@psf.upfronthosting.co.za>
New submission from wiesenth <d.wiesenthal at gmx.de>:
The interpreter crashes with an segmentation fault when warnings.warn
shall output a Warning instance, whose string representation is bad
formatted.
Don't know if this is fixed in a minor 2.6 release or in 2.7, I use the
Ubuntu 9.04 python2.6 package.
An easy reproducing example is given.
This is also an issue within python3.0 (python3.1 does not exist in the
repositories)
----------
files: warnsegfault.py
messages: 90111
nosy: wiesenth
severity: normal
status: open
title: warnings.warn segfaults on bad formatted string
type: crash
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14447/warnsegfault.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6415>
_______________________________________
From report at bugs.python.org Sat Jul 4 13:24:35 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 04 Jul 2009 11:24:35 +0000
Subject: [New-bugs-announce] [issue6416] Failed to compile selectmodule.c on
windows (trunk)
In-Reply-To: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
Message-ID: <1246706675.4.0.617951670977.issue6416@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I cannot compile selectmodule.c on windows(trunk). PIPE_BUF will not be
defined if macro _POSIX_ is not defined. But if define _POSIX_ before
"#include <limits.h>" in Include/Python.h another compile error happens.
E:\python-dev\trunk\PC\msvcrtmodule.c(39) : warning C4013: ??
'_heapmin' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(2901) : warning C4013: ??
'_exit' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(2974) : warning C4013: ??
'execv' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3107) : warning C4013: ??
'execve' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3194) : error C2065:
'_OLD_P_OVERLAY' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(3195) : error C2065:
'_P_OVERLAY' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(3198) : warning C4013: ??
'_spawnv' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3343) : warning C4013: ??
'_spawnve' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(3790) : warning C4013: ??
'getpid' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(4918) : warning C4013: ??
'alloca' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(5868) : warning C4013: ??
'_cwait' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(6743) : warning C4013: ??
'putenv' ???????????int ?????????????????
E:\python-dev\trunk\Modules\posixmodule.c(8941) : error C2065: '_P_WAIT'
: ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(8942) : error C2065:
'_P_NOWAIT' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(8944) : error C2065:
'_P_NOWAITO' : ??????????????
E:\python-dev\trunk\Modules\posixmodule.c(8945) : error C2065:
'_P_DETACH' : ??????????????
(snip)
Probaly it's not good define _POSIX_ on windows. Is it reasonable to put
"#ifdef PIPE_BUF" around
PyModule_AddIntConstant(m, "PIPE_BUF", PIPE_BUF);
in selectmodule.c.
----------
components: Build, Windows
messages: 90113
nosy: ocean-city
severity: normal
status: open
title: Failed to compile selectmodule.c on windows (trunk)
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6416>
_______________________________________
From report at bugs.python.org Sat Jul 4 16:58:45 2009
From: report at bugs.python.org (Michael Newman)
Date: Sat, 04 Jul 2009 14:58:45 +0000
Subject: [New-bugs-announce] [issue6417] multiprocessing Process examples:
print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
New submission from Michael Newman <michael.b.newman at gmail.com>:
The "16.6.1.1. The Process class" section of the multiprocessing
documentation:
http://docs.python.org/dev/py3k/library/multiprocessing.html
has errors in both examples.
The first example needs the indentation fixed on the "from" and "if"
lines (remove the leading spaces).
The second example has two issues: print syntax needs be updated from
2.0 to 3.0 syntax. Also, getppid is not available on win32 platforms.
Below is a corrected example, which I tested successfully on on win32
and linux:
# Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
C:\>c:\Python31\python.exe Process_with_more_info.py
main line
module name: __main__
parent process: None
process id: 3216
function f
module name: __main__
parent process: 3216
process id: 3692
hello bob
# Python 3.0.1 (r301:69556, Jun 6 2009, 21:34:43) [GCC 4.3.2] on linux2
mike at www:~/files$ python3.0 Process_with_more_info.py
main line
module name: __main__
parent process: 19853
process id: 22544
function f
module name: __main__
parent process: 22544
process id: 22545
hello bob
# Start of corrected example:
from multiprocessing import Process, current_process
from sys import platform
import os
def info(title):
print(title)
print('module name:', __name__)
if platform == 'win32':
print('parent process:', current_process()._parent_pid)
else:
print('parent process:', os.getppid())
print('process id:', os.getpid())
def f(name):
info('function f')
print('hello', name)
if __name__ == '__main__':
info('main line')
p = Process(target=f, args=('bob',))
p.start()
p.join()
# End of corrected example.
I also saw this online:
"os.getppid on Windows"
http://d.hatena.ne.jp/chrono-meter/20090325/p1
But the license of the code is not clear, and it would make the example
too confusing to insert in.
Another reference:
"Multiprocessing docs are not 3.0-ready"
http://bugs.python.org/issue3256
Looks like some print statements fixed back then, but not sure why the
examples mentioned here were not fixed.
----------
assignee: georg.brandl
components: Documentation
messages: 90118
nosy: georg.brandl, mnewman
severity: normal
status: open
title: multiprocessing Process examples: print and getppid
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________
From report at bugs.python.org Sat Jul 4 22:27:28 2009
From: report at bugs.python.org (Jason Pellerin)
Date: Sat, 04 Jul 2009 20:27:28 +0000
Subject: [New-bugs-announce] [issue6418] unittest.TestProgram change breaks
nose
In-Reply-To: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
Message-ID: <1246739248.73.0.754849239276.issue6418@psf.upfronthosting.co.za>
New submission from Jason Pellerin <jpellerin at gmail.com>:
This changeset:
http://hg.python.org/cpython/rev/c3fb79d1c036
breaks nose, as it changes the behavior of unittest.TestProgram in a
non-backwards-compatible way. Previously, when called like:
TestProgram(testRunner=None)
self.testRunner would be None when runTests() was called. Now, it is
populated with the default TextTestRunner class in TestProgram.__init__.
nose expects self.testRunner to be None or a runner instance in
runTests(), and thus fails immediately with 2.6.3.
If initialization of self.testRunner could be deferred to runTests() as
in unitttest for 2.5 and earlier, that would be ideal for nose.
----------
components: Library (Lib)
messages: 90123
nosy: jpellerin
severity: normal
status: open
title: unittest.TestProgram change breaks nose
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6418>
_______________________________________
From report at bugs.python.org Sat Jul 4 23:23:01 2009
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 04 Jul 2009 21:23:01 +0000
Subject: [New-bugs-announce] [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
New submission from Henry Precheur <henry at precheur.org>:
A kqueue's test doesn't pass on OpenBSD 4.6-beta, 4.4, & 4.5:
FAILED (failures=1)
Traceback (most recent call last):
File "Lib/test/test_kqueue.py", line 186, in <module>
test_main()
File "Lib/test/test_kqueue.py", line 183, in test_main
support.run_unittest(TestKQueue)
File "/home/henry/py3k/Lib/test/support.py", line 882, in run_unittest
_run_suite(suite)
File "/home/henry/py3k/Lib/test/support.py", line 865, in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
File "Lib/test/test_kqueue.py", line 119, in test_queue_event
(server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(6, -2, 5), (7, -2, 5)] != [(6, -2, 0),
(7, -2, 0)]
First differing element 0:
(6, -2, 5)
(6, -2, 0)
- [(6, -2, 5), (7, -2, 5)]
? ^ ^
+ [(6, -2, 0), (7, -2, 0)]
? ^ ^
It looks like OpenBSD behaves like Darwin. The attached patch fixes the
test.
----------
files: patch-Lib_test_test_kqueue_py
messages: 90127
nosy: henry.precheur
severity: normal
status: open
title: Broken test_kqueue.py on OpenBSD
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14449/patch-Lib_test_test_kqueue_py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________
From report at bugs.python.org Sat Jul 4 23:39:27 2009
From: report at bugs.python.org (Henry Precheur)
Date: Sat, 04 Jul 2009 21:39:27 +0000
Subject: [New-bugs-announce] [issue6420] Fix warning in nismodule.c on
OpenBSD
In-Reply-To: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>
Message-ID: <1246743567.03.0.331926957573.issue6420@psf.upfronthosting.co.za>
New submission from Henry Precheur <henry at precheur.org>:
On OpenBSD the file /usr/include/rpcsvc/ypclnt.h contains the following
declaration:
struct ypall_callback {
/* return non-0 to stop getting called */
int (*foreach)(unsigned long, char *, int, char *, int, void *);
char *data; /* opaque pointer for use of callback fn */
};
the 'foreach' function pointer's declaration in Modules/nismodule.c is
different:
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include -I/usr/local/include -IInclude
-I/home/henry/py3k -c /home/henry/py3k/Modules/nismodule.c -o
build/temp.openbsd-4.6-amd64-3.2/home/henry/py3k/Modules/nismodule.o
/home/henry/py3k/Modules/nismodule.c: In function `nis_cat':
/home/henry/py3k/Modules/nismodule.c:208: warning: assignment from
incompatible pointer type
The attached patch fixes this very important issue :)
----------
components: Build, Library (Lib)
files: patch-Modules_nismodule_c
messages: 90128
nosy: henry.precheur
severity: normal
status: open
title: Fix warning in nismodule.c on OpenBSD
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14450/patch-Modules_nismodule_c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6420>
_______________________________________
From report at bugs.python.org Sun Jul 5 00:53:41 2009
From: report at bugs.python.org (Alex Martelli)
Date: Sat, 04 Jul 2009 22:53:41 +0000
Subject: [New-bugs-announce] [issue6421] errors in docs re module
initialization vs self arg to functions
In-Reply-To: <1246748021.93.0.159427637238.issue6421@psf.upfronthosting.co.za>
Message-ID: <1246748021.93.0.159427637238.issue6421@psf.upfronthosting.co.za>
New submission from Alex Martelli <aleaxit at gmail.com>:
http://docs.python.org/3.1/c-api/structures.html#PyMethodDef
says (under METH_VARARGS):
"""The first one is the self object for methods; for module functions,
it has the value given to Py_InitModule4 (or NULL if Py_InitModule was
used)."""
Py_InitModule4 is no more, and the first argument is now in fact a
pointer to the module object. This is quite important, since the module
object is now crucial for the get-state function that's supposed to
replace a module's statics!
http://docs.python.org/3.1/extending/extending.html#a-simple-example
is ever wronger, since it says, after presenting spam_system's code:
"""The self argument is only used when the C function implements a
built-in method, not a function. In the example, self will always be a
NULL pointer, since we are defining a function, not a method. """
It will never be NULL; it will point to the module.
----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90134
nosy: aleax, georg.brandl
priority: normal
severity: normal
status: open
title: errors in docs re module initialization vs self arg to functions
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6421>
_______________________________________
From report at bugs.python.org Sun Jul 5 17:15:12 2009
From: report at bugs.python.org (Scott David Daniels)
Date: Sun, 05 Jul 2009 15:15:12 +0000
Subject: [New-bugs-announce] [issue6422] timeit called from within Python
should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
New submission from Scott David Daniels <Scott.Daniels at Acm.Org>:
timeit.main has a _very_ handy autoranging facility to pick an
appropriate number of repetitions when not specified. The autoranging
code should be lifted to a method on Timer instances (so non-main code
can use it). If number is specified as 0 or None, I would like to use
the results of that autoranging code in Timer.repeat and Timer.timeit.
Patch to follow.
----------
components: Library (Lib)
messages: 90157
nosy: scott_daniels
severity: normal
status: open
title: timeit called from within Python should allow autoranging
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________
From report at bugs.python.org Sun Jul 5 18:05:32 2009
From: report at bugs.python.org (Christoph Zwerschke)
Date: Sun, 05 Jul 2009 16:05:32 +0000
Subject: [New-bugs-announce] [issue6423] The cgi docs should advertize using
"in" instead of "has_key"
In-Reply-To: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
Message-ID: <1246809932.04.0.15312988227.issue6423@psf.upfronthosting.co.za>
New submission from Christoph Zwerschke <cito at online.de>:
The cgi.Fieldstorage class supports the __contains__ method since Py
2.2, but the documentation of Py 2.6 still only mentions the old
fashioned has_key method. See patch.
----------
assignee: georg.brandl
components: Documentation
files: cgi.patch
keywords: patch
messages: 90158
nosy: cito, georg.brandl
severity: normal
status: open
title: The cgi docs should advertize using "in" instead of "has_key"
versions: Python 2.6
Added file: http://bugs.python.org/file14456/cgi.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6423>
_______________________________________
From report at bugs.python.org Sun Jul 5 18:24:52 2009
From: report at bugs.python.org (Thomas Courbon)
Date: Sun, 05 Jul 2009 16:24:52 +0000
Subject: [New-bugs-announce] [issue6424] Idle3 crashing when using completion
In-Reply-To: <1246811092.0.0.225058940814.issue6424@psf.upfronthosting.co.za>
Message-ID: <1246811092.0.0.225058940814.issue6424@psf.upfronthosting.co.za>
New submission from Thomas Courbon <harthie at yahoo.fr>:
Configuration : fedora 11, python3.1 manually compiled and installed
along python 2.6 (provided by the distribution).
Reproducibility : seems to be happening any time
Description : When you try to use the auto-completion (ctrl + space) on
anything (tested with module and custom class), the idle crash with the
message :
Traceback (most recent call last):
File "/usr/local/bin/idle3", line 5, in <module>
main()
File "/usr/local/lib/python3.1/idlelib/PyShell.py", line 1420, in main
root.mainloop()
File "/usr/local/lib/python3.1/tkinter/__init__.py", line 1009, in
mainloop
self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
illegal encoding
----------
components: IDLE
messages: 90159
nosy: tcourbon
severity: normal
status: open
title: Idle3 crashing when using completion
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6424>
_______________________________________
From report at bugs.python.org Mon Jul 6 10:18:38 2009
From: report at bugs.python.org (Sjoerd)
Date: Mon, 06 Jul 2009 08:18:38 +0000
Subject: [New-bugs-announce] [issue6425] imaplib.IMAP4.fetch() is missing
documentation for message_set parameter
In-Reply-To: <1246868318.71.0.0692124898896.issue6425@psf.upfronthosting.co.za>
Message-ID: <1246868318.71.0.0692124898896.issue6425@psf.upfronthosting.co.za>
New submission from Sjoerd <sjoerd-python at linuxonly.nl>:
The message_set parameter imaplib.IMAP4.fetch(message_set,
message_parts) is not a set or list, but a comma-separated string, it
seems. This could use some documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 90165
nosy: Sjoerder, georg.brandl
severity: normal
status: open
title: imaplib.IMAP4.fetch() is missing documentation for message_set parameter
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6425>
_______________________________________
From report at bugs.python.org Mon Jul 6 10:22:59 2009
From: report at bugs.python.org (Sjoerd)
Date: Mon, 06 Jul 2009 08:22:59 +0000
Subject: [New-bugs-announce] [issue6426] imaplib.IMAP4 "command illegal in
this state" is unhelpful error message
In-Reply-To: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>
Message-ID: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>
New submission from Sjoerd <sjoerd-python at linuxonly.nl>:
If you do not IMAP4.select(), you get the following error:
imaplib.error: command SEARCH illegal in state AUTH.
This does not inform the user that he has to do IMAP4.select(). Better
would be:
imaplib.error: command SEARCH illegal in state AUTH, allowed in state
SELECTED.
See also:
http://mail.python.org/pipermail/patches/2006-December/021308.html
----------
components: Library (Lib)
messages: 90166
nosy: Sjoerder
severity: normal
status: open
title: imaplib.IMAP4 "command illegal in this state" is unhelpful error message
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6426>
_______________________________________
From report at bugs.python.org Mon Jul 6 12:30:51 2009
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 06 Jul 2009 10:30:51 +0000
Subject: [New-bugs-announce] [issue6427] Rename float*.[ch] to double.[ch]
In-Reply-To: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>
Message-ID: <1246876251.06.0.606868517099.issue6427@psf.upfronthosting.co.za>
New submission from Jack Diederich <jackdied at gmail.com>:
The core types use doubles, not floats. The file and function names
should reflect that (the docs already do).
----------
components: None
messages: 90169
nosy: jackdied
severity: normal
status: open
title: Rename float*.[ch] to double.[ch]
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6427>
_______________________________________
From report at bugs.python.org Mon Jul 6 16:45:34 2009
From: report at bugs.python.org (SilentGhost)
Date: Mon, 06 Jul 2009 14:45:34 +0000
Subject: [New-bugs-announce] [issue6428] TypeError: __bool__ should return
bool or int, returned int
In-Reply-To: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
Message-ID: <1246891534.57.0.238134342776.issue6428@psf.upfronthosting.co.za>
New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:
According to docs
(http://docs.python.org/3.1/reference/datamodel.html#object.__bool__)
__bool__ can return 1 or 0 instead of True or False.
However, when I ran the following code:
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
>>> class Spam():
def __bool__(self):
return 1
>>> if Spam():
print('ham')
I got the following error:
Traceback (most recent call last):
File "<pyshell#72>", line 1, in <module>
if Spam():
TypeError: __bool__ should return bool or int, returned int
So, do I misunderstand the docs or is it an error in them?
----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 90181
nosy: SilentGhost, georg.brandl
severity: normal
status: open
title: TypeError: __bool__ should return bool or int, returned int
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6428>
_______________________________________
From report at bugs.python.org Mon Jul 6 19:13:15 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 17:13:15 +0000
Subject: [New-bugs-announce] [issue6429] 2to3: fix_future conflicts with
fix_print
In-Reply-To: <1246900395.55.0.0522093786653.issue6429@psf.upfronthosting.co.za>
Message-ID: <1246900395.55.0.0522093786653.issue6429@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
Running 2to3 with the default options on the following code:
from __future__ import print_function
x,y = 1,2
print(x, y)
produces the following diff:
--- future_print.py (original)
+++ future_print.py (refactored)
@@ -1,5 +1,5 @@
-from __future__ import print_function
+
x = 1
y = 2
-print(x, y)
+print((x, y))
If the "--nofix=future" options is specified, 2to3 produces the correct
output.
I found this while working on a fixer for removing future_builtins
imports. It seems that fixer_util.does_tree_import() is unable to find
the __future__ import node and thus causes FixPrint to be run instead of
being skipped.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90183
nosy: alexandre.vassalotti, benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: 2to3: fix_future conflicts with fix_print
type: behavior
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6429>
_______________________________________
From report at bugs.python.org Mon Jul 6 22:40:27 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 06 Jul 2009 20:40:27 +0000
Subject: [New-bugs-announce] [issue6430] array.array falsely advertises
support for 'w' in documentation
In-Reply-To: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>
Message-ID: <1246912827.43.0.704118006779.issue6430@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
It looks like either array's 'w' support got lost in a merge, or the
documentation is just wrong.
>>> import array
>>> array.array('w', "hello")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d)
>>> print(array.__doc__)
This module defines an object type which can efficiently represent
an array of basic values: characters, integers, floating point
numbers. Arrays are sequence types and behave very much like lists,
except that the type of objects stored in them is constrained. The
type is specified at object creation time by using a type code, which
is a single character. The following type codes are defined:
Type code C Type Minimum size in bytes
'b' signed integer 1
'B' unsigned integer 1
'u' Unicode character 2 (see note)
'h' signed integer 2
'H' unsigned integer 2
'i' signed integer 2
'I' unsigned integer 2
'w' unicode character 4
'l' signed integer 4
'L' unsigned integer 4
'f' floating point 4
'd' floating point 8
NOTE: The 'u' typecode corresponds to Python's unicode character. On
narrow builds this is 2-bytes on wide builds this is 4-bytes.
----------
assignee: georg.brandl
components: Documentation, Extension Modules
messages: 90190
nosy: alexandre.vassalotti, georg.brandl
priority: low
severity: normal
status: open
title: array.array falsely advertises support for 'w' in documentation
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6430>
_______________________________________
From report at bugs.python.org Tue Jul 7 07:41:36 2009
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 07 Jul 2009 05:41:36 +0000
Subject: [New-bugs-announce] [issue6431] Fraction fails equality test with a
user-defined type
In-Reply-To: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
Message-ID: <1246945296.27.0.280023368175.issue6431@psf.upfronthosting.co.za>
New submission from Case Van Horsen <casevh at gmail.com>:
I've ported the GMPY module to Python 3 and found a problem comparing
Fraction to gmpy.mpq. mpq is the rational type in gmpy and knows how to
convert a Fraction into an mpq. All operations appear to work properly
except "Fraction == mpq".
"mpq == Fraction" does work correctly. gmpy's rich comparison routine
recognizes the other argument as Fraction and converts to an mpq value
properly. However, when "Fraction == mpq" is done, the Fraction argument
is converted to a float before gmpy's rich comparison is called.
The __eq__ routine in fractions.py is:
def __eq__(a, b):
"""a == b"""
if isinstance(b, numbers.Rational):
return (a._numerator == b.numerator and
a._denominator == b.denominator)
if isinstance(b, numbers.Complex) and b.imag == 0:
b = b.real
if isinstance(b, float):
return a == a.from_float(b)
else:
# XXX: If b.__eq__ is implemented like this method, it may
# give the wrong answer after float(a) changes a's
# value. Better ways of doing this are welcome.
return float(a) == b
Shouldn't __eq__ return NotImplemented if it doesn't know how to handle
the other argument? I changed "return float(a) == b" to "return
NotImplemented" and GMPY and Python's test suite passed all tests.
I used the same logic for comparisons between gmpy.mpf and Decimal and
they all work correctly. Decimal does return NotImplemented when it
can't convert the other argument.
(GMPY 1.10 alpha2 fails due to this issue.)
----------
components: Library (Lib)
messages: 90211
nosy: casevh
severity: normal
status: open
title: Fraction fails equality test with a user-defined type
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6431>
_______________________________________
From report at bugs.python.org Tue Jul 7 12:30:24 2009
From: report at bugs.python.org (=?utf-8?q?Jean-Paul_Mi=C3=A9ville?=)
Date: Tue, 07 Jul 2009 10:30:24 +0000
Subject: [New-bugs-announce] [issue6432] ImageTk.PhotoImage
In-Reply-To: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>
Message-ID: <1246962624.44.0.14182359808.issue6432@psf.upfronthosting.co.za>
New submission from Jean-Paul Mi?ville <jpmieville at gmail.com>:
When using the function ImageTk.PhotoImage. I got the following
traceback.
self.chart = ImageTk.PhotoImage(self.image)
File "C:\Python25\Lib\site-packages\PIL\ImageTk.py", line 116, in
__init__
self.paste(image)
File "C:\Python25\Lib\site-packages\PIL\ImageTk.py", line 181, in
paste
import _imagingtk
ImportError: DLL load failed: The specified module could not be found.
_imagintk exists in the directory C:\Python25\Lib\site-packages\PIL
I have re-installed python (ActivePython 2.5.4.4 (r254:67916, Apr 27
2009, 15:41:14)and PIL and still the same problem.
----------
components: Tkinter
messages: 90225
nosy: jpmieville
severity: normal
status: open
title: ImageTk.PhotoImage
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6432>
_______________________________________
From report at bugs.python.org Tue Jul 7 13:39:04 2009
From: report at bugs.python.org (Eric Eisner)
Date: Tue, 07 Jul 2009 11:39:04 +0000
Subject: [New-bugs-announce] [issue6433] multiprocessing: pool.map hangs on
empty list
In-Reply-To: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
Message-ID: <1246966744.58.0.524623595855.issue6433@psf.upfronthosting.co.za>
New submission from Eric Eisner <ede at mit.edu>:
In multiprocessing, if you give a pool.map a zero-length iterator and
specify a nonzero chunksize, the process hangs indefinitely. Example:
import multiprocessing
pool = multiprocessing.Pool()
pool.map(len, [], chunksize=1)
# hang forever
Attached simple testcase and simple fix. I observed this behavior on 2.6
and 3.1, but only verified the patch on 3.1. Unless the line numbers
changed it will probably fix it on 2.6 as well.
----------
components: Library (Lib)
files: map_testandfix.patch
keywords: patch
messages: 90228
nosy: ede
severity: normal
status: open
title: multiprocessing: pool.map hangs on empty list
type: crash
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14467/map_testandfix.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6433>
_______________________________________
From report at bugs.python.org Tue Jul 7 19:10:59 2009
From: report at bugs.python.org (segfault42)
Date: Tue, 07 Jul 2009 17:10:59 +0000
Subject: [New-bugs-announce] [issue6434] buffer overflow in Zipfile when
wrinting more than 2gig file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
New submission from segfault42 <brice.nahum at free.fr>:
Hello,
I have a problem with the librairy zipfile.py
http://svn.python.org/view/python/trunk/Lib/zipfile.py?revision=73565&view=markup
Zinfo structure limit the size of a file to an int max value with the
ZIP64_LIMIT value ( equal to "(1 << 31) - 1 " so to 2147483647 .
The problem is happening when you write a big file in the line 1095 :
self.fp.write(struct.pack("<lLL", zinfo.CRC, zinfo.compress_size,
zinfo.file_size))
zinfo.file_size is limited to a int size and if you have a file bigger
than ZIP64_LIMIT you make a buffer overflow even if you set the flag
allowZip64 to true.
----------
components: Library (Lib)
files: zipfile.py
messages: 90242
nosy: segfault42
severity: normal
status: open
title: buffer overflow in Zipfile when wrinting more than 2gig file
versions: Python 2.4, Python 3.0
Added file: http://bugs.python.org/file14469/zipfile.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________
From report at bugs.python.org Wed Jul 8 04:18:04 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 08 Jul 2009 02:18:04 +0000
Subject: [New-bugs-announce] [issue6435] logging: cache the traceback text
on formatter, instead of record
In-Reply-To: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
Message-ID: <1247019484.09.0.843372167885.issue6435@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
In Formatter.format():
# Cache the traceback text to avoid converting it multiple
times
# (it's constant anyway)
if not record.exc_text:
record.exc_text = self.formatException(record.exc_info)
The result must ideally be cache on the formatter object (self) itself
rather than the record object. Because, record object is reused in
multiple handlers .. thus multiple formatters. If the first formatter,
caches the traceback text, then subsequent formatters will use the same
even though of them is apparently a custom Formatter with overridden
`formatException`.
----------
components: Library (Lib)
messages: 90247
nosy: srid, vsajip
severity: normal
status: open
title: logging: cache the traceback text on formatter, instead of record
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6435>
_______________________________________
From report at bugs.python.org Wed Jul 8 08:37:37 2009
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 08 Jul 2009 06:37:37 +0000
Subject: [New-bugs-announce] [issue6436] trace module doesn't seem to
produce .cover files for Py3 (but does for Py2)
In-Reply-To: <1247035057.94.0.368292747718.issue6436@psf.upfronthosting.co.za>
Message-ID: <1247035057.94.0.368292747718.issue6436@psf.upfronthosting.co.za>
New submission from Mark Summerfield <mark at qtrac.eu>:
When I execute the following command line (Linux, Fedora 10) using
Python 2.5 or 2.6, I get a .cover file:
python2.5 -m trace --count MyModule.py
But when I do this with Python 3.0 or 3.1, no .cover file is output.
I didn't notice anything in the documentation suggesting a change in
behaviour, but I'm not familiar with this module, so perhaps I've missed
something.
----------
components: Library (Lib)
messages: 90252
nosy: mark
severity: normal
status: open
title: trace module doesn't seem to produce .cover files for Py3 (but does for Py2)
type: behavior
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6436>
_______________________________________
From report at bugs.python.org Wed Jul 8 09:58:53 2009
From: report at bugs.python.org (Manas)
Date: Wed, 08 Jul 2009 07:58:53 +0000
Subject: [New-bugs-announce] [issue6437] Personal invitation from Manas
In-Reply-To: <20090708035849.-1594888511@unyk.com>
Message-ID: <20090708035849.-1594888511@unyk.com>
New submission from Manas <gravitywarrior1 at gmail.com>:
Personal invitation from Manas
----------
files: unnamed
messages: 90257
nosy: gravitywarrior1
severity: normal
status: open
title: Personal invitation from Manas
Added file: http://bugs.python.org/file14471/unnamed
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6437>
_______________________________________
-------------- next part --------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>UNYK</title>
</head>
<body>
<div id="um_container" style="width: 500px; color: #003366; font-family: verdana, arial, geneva, sans-serif;
font-size: 12px; font-style: normal; font-weight: normal; line-height: 14px;
text-align: left; text-decoration: none;">
<div id="um_watermark" style="color: #808080;font-size: 10px; margin-bottom: 5px;">
If you are not able to click these links, click the following: ????Show content???? and try again.<br>
E-mail sent 7/8/2009 3:57:22 AM, by Manas Thapliyal:
</div>
<div id="um_header" style="border-bottom: solid 1px black;">
<table width="100%">
<tr>
<td id="um_subject" style="width: auto; vertical-align: bottom; padding-left: 10px;
padding-bottom: 15px; color: #003366; font-family: verdana, arial, geneva, sans-serif;
font-weight: bold; font-size: 16px;">
Personal invitation from Manas</td>
<td id="um_logo" style="width: 131px;">
<a href="http://www.unyk.com/ml/354/66/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900"><img border="0" src="http://www.unyk.com/img/common/logo_131x76.gif"></a></td>
</tr>
</table>
</div>
<div id="um_content" style="padding: 25px 10px 25px 10px;">
<table cellpadding="0" cellspacing="0" border="0" width="100%">
<tr>
<td style="padding: 5px 0px 5px 5px; background-color: #f3f3f3;"><img src="http://photos.unyk.com/img/common/avatar_H.gif" border="0" /><br /></td>
<td style="padding: 5px; background-color: #f3f3f3;" valign="top" align="left">
Hello,<br />
<br />
To keep all friends together<br />
<br />
Finally, a smart and simple way to manage your contacts!<br />
<br />
With UNYK, I put all my contacts together in <b>one address book</b> that is <b>automatically updated</b>. One of my contacts changes his or her information at UNYK.com: My address book is updated. I change information at UNYK.com: My contacts?? address books are updated. Simple, but life-changing!<br />
<br />
Can I add you as one of my contacts?
<a href="http://www.unyk.com/ml/354/66/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900">To accept, click here!</a><br />
<br />
You too can create your own smart address book. <br />
<br />
</td>
</tr>
</table>
<table cellpadding="0" cellspacing="0" border="0" width="100%">
<tr>
<td style="padding: 10px 5px 0px 5px; background-color: #ffffff; font-size: 11px;">
Manas Thapliyal<br>
UNYK : ASI 610
</td>
</tr>
</table>
</div>
<div id="um_footer" style="border-top: solid 1px black; padding-top: 3px; font-weight: bold;
font-size: 10px; font-family: arial, geneva, sans-serif;">
UNYK, the first smart address book that updates itself!
</div>
<div id="um_unsubscribe" style="color: #808080; font-size: 10px; padding-top: 50px;">
<a href="http://www.unyk.com/ml/354/79/?mid=9E96A4A47B7D839D&email=report at bugs.python.org&s=15202900">Click here</a> if you no longer wish to receive invitations from Manas Thapliyal to try UNYK! <br />
<a href="http://www.unyk.com/ml/354/67/?i=629FDC41B12F4673BBD647F7424EE0E3&s=15202900">Click here</a> if you no longer wish to receive invitations to try UNYK from your contacts!<br />
</div>
</div>
</body>
</html>
From report at bugs.python.org Wed Jul 8 10:15:35 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 08 Jul 2009 08:15:35 +0000
Subject: [New-bugs-announce] [issue6438] cygwincompiler regular expressions
broken
In-Reply-To: <1247040935.54.0.909113570309.issue6438@psf.upfronthosting.co.za>
Message-ID: <1247040935.54.0.909113570309.issue6438@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
The regular expressions used in distutils to build a extension using the
mingw32 compiler are messed up because they try to work with bytes
(since Popen behavior changed) using string patterns.
I have to cleanup these regular expressions before any new 3.x release
----------
assignee: tarek
components: Distutils
messages: 90260
nosy: tarek
priority: critical
severity: normal
status: open
title: cygwincompiler regular expressions broken
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6438>
_______________________________________
From report at bugs.python.org Wed Jul 8 16:11:11 2009
From: report at bugs.python.org (Campbell Barton)
Date: Wed, 08 Jul 2009 14:11:11 +0000
Subject: [New-bugs-announce] [issue6439] Demo/embed/demo.c use of
PySys_SetArgv() is invalid
In-Reply-To: <1247062271.71.0.103757159811.issue6439@psf.upfronthosting.co.za>
Message-ID: <1247062271.71.0.103757159811.issue6439@psf.upfronthosting.co.za>
New submission from Campbell Barton <ideasman42 at gmail.com>:
in python 3.2 (current rev 73893)
Demo/embed/demo.c passes a 'char **' to PySys_SetArgv rather then a
'wsize_t **'
Im also confused as to how this conversion should be made in a portable
way, without copying some farily large static functions from python's code.
----------
components: Demos and Tools
messages: 90267
nosy: ideasman42
severity: normal
status: open
title: Demo/embed/demo.c use of PySys_SetArgv() is invalid
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6439>
_______________________________________
From report at bugs.python.org Wed Jul 8 16:13:19 2009
From: report at bugs.python.org (Eric Eisner)
Date: Wed, 08 Jul 2009 14:13:19 +0000
Subject: [New-bugs-announce] [issue6440] 2to3: convert deprecated
string.maketrans to str.maketrans
In-Reply-To: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
Message-ID: <1247062399.96.0.431147395298.issue6440@psf.upfronthosting.co.za>
New submission from Eric Eisner <ede at mit.edu>:
string.maketrans has been deprecated in 3.x in favor of the more
specific bytes.maketrans and str.maketrans (see issue5675). It would be
nice if 2to3 would automatically translate this to one of those two
(probably str.maketrans).
I briefly looked at lib2to3/fixes/fix_renames.py, but this only seems to
convert things of the form module.X to module.Y. Is there another script
that deals with these jumping-around functions?
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90268
nosy: ede
severity: normal
status: open
title: 2to3: convert deprecated string.maketrans to str.maketrans
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6440>
_______________________________________
From report at bugs.python.org Wed Jul 8 17:05:33 2009
From: report at bugs.python.org (Adam Ginsburg)
Date: Wed, 08 Jul 2009 15:05:33 +0000
Subject: [New-bugs-announce] [issue6441] Tkinter cannot find *64 bit* Tcl/Tk
on Mac OS X
In-Reply-To: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
Message-ID: <1247065533.17.0.251181010063.issue6441@psf.upfronthosting.co.za>
New submission from Adam Ginsburg <keflavich at gmail.com>:
While it is possible to compile 64 bit python on Mac OS X, the default
tcl/tk is NOT 64 bit. If you do install a 64 bit version of tcl/tk,
python still will not find it - lines 1503-1515 prevent it:
if 'x86_64' in archs or 'ppc64' in archs:
try:
archs.remove('x86_64')
except ValueError:
pass
try:
archs.remove('ppc64')
except ValueError:
pass
for a in archs:
frameworks.append('-arch')
frameworks.append(a)
I was able to successfully get 64 bit tkinter working by commenting out
these lines as suggested by Ned Deily.
Ronald Oussoren suggests:
"BTW. The correct fix would be to add a probe to setup.py that detects
if Tcl/Tk was build with 64-bit support or not."
----------
components: Tkinter
messages: 90269
nosy: keflavich, nad, ronaldoussoren
severity: normal
status: open
title: Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6441>
_______________________________________
From report at bugs.python.org Thu Jul 9 00:47:17 2009
From: report at bugs.python.org (Corbin Simpson)
Date: Wed, 08 Jul 2009 22:47:17 +0000
Subject: [New-bugs-announce] [issue6442] Backwards __contains__/has_key in
xml/sax/xmlreader.py
In-Reply-To: <1247093237.58.0.29054416119.issue6442@psf.upfronthosting.co.za>
Message-ID: <1247093237.58.0.29054416119.issue6442@psf.upfronthosting.co.za>
New submission from Corbin Simpson <MostAwesomeDude at gmail.com>:
Not a big deal, but these two methods were backwards in AttributesImpl
in xml/sax/xmlreader.py, and it was causing fun little problems in some
of my code on Python 2.6.0, so I decided to whip up a patch.
(Of course, this is fixed in Py3k since has_key() got nuked.)
~ C.
----------
components: Library (Lib)
files: temp.patch
keywords: patch
messages: 90290
nosy: MostAwesomeDude
severity: normal
status: open
title: Backwards __contains__/has_key in xml/sax/xmlreader.py
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14475/temp.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6442>
_______________________________________
From report at bugs.python.org Thu Jul 9 05:21:10 2009
From: report at bugs.python.org (Andrew Ziem)
Date: Thu, 09 Jul 2009 03:21:10 +0000
Subject: [New-bugs-announce] [issue6443] _winreg.QueryValueEx confused on
double null terminated strings
In-Reply-To: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
Message-ID: <1247109670.35.0.187157773378.issue6443@psf.upfronthosting.co.za>
New submission from Andrew Ziem <ahz001 at gmail.com>:
QueryValueEx only returns one string when the contents are double null
terminated, yet QueryValueEx works when the string is singly null
terminated.
In Python 2.5.4 on Windows XP Sp3, the first key-value only returns the
first part up to \0\0.
-------------------
C:\>reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v
Pending
FileRenameOperations
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
PendingFileRenameOperations REG_MULTI_SZ \??\C:\Documents and
Settings\All Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Program
Files\Google\GoogleToolbarNotifier\5.2.4204.1700\0\0\??\C:\Documents and
Settings\All Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All
Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\??\C:\Documents and Settings\All Users\A
pplication Data\McAfee\Common Framework\UpdateDir\0\0\??\C:\Documents
and Settings\All Users\Application Data\McAfee\Common
Framework\UpdateDir\0\0\0
C:\>reg query "HKLM\SYSTEM\CurrentControlSet\Services\Browser" /v
DependOnService
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser
DependOnService REG_MULTI_SZ LanmanWorkstation\0LanmanServer\0\0
----------
components: Windows
messages: 90300
nosy: AndrewZiem
severity: normal
status: open
title: _winreg.QueryValueEx confused on double null terminated strings
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6443>
_______________________________________
From report at bugs.python.org Thu Jul 9 09:34:00 2009
From: report at bugs.python.org (Max Arnold)
Date: Thu, 09 Jul 2009 07:34:00 +0000
Subject: [New-bugs-announce] [issue6444] multiline exception logging via
syslog handler
In-Reply-To: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
Message-ID: <1247124840.28.0.246529396761.issue6444@psf.upfronthosting.co.za>
New submission from Max Arnold <lwarxx at gmail.com>:
I use syslog message routing mechanism to log high-priority messages
from my python code to separate file. When exceptions are logged, only
first line routed to specified file, and the rest goes in /var/log/messages.
Such problem exists when SyslogHandler instantiated with "/dev/log".
If logging is performed to remote host via udp socket, then exception
logged as one long string with all lines being concatenated.
Probably multiline log messages should be automatically splitted and
logged line-by-line with the same facility, severity and program name.
Also it will be good to have special formatter tag which expands as
empty string in first logged line, and as user-defined string in
remaining ones. This can simplify automated log analysis.
----------
components: Library (Lib)
messages: 90307
nosy: LwarX
severity: normal
status: open
title: multiline exception logging via syslog handler
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6444>
_______________________________________
From report at bugs.python.org Thu Jul 9 11:29:53 2009
From: report at bugs.python.org (OG7)
Date: Thu, 09 Jul 2009 09:29:53 +0000
Subject: [New-bugs-announce] [issue6445] Add check parameter to
subprocess.Popen.communicate
In-Reply-To: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za>
Message-ID: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za>
New submission from OG7 <onyxg7 at users.sourceforge.net>:
communicate is often used in one-liners, but becomes a four-liner if you
want to check the process exit status. Adding a check parameter would
make it more convenient to get things right and write non-buggy code.
The CalledProcessError requires a cmd argument, which means also adding
a cmd member to Popen objects.
----------
messages: 90318
nosy: OG7
severity: normal
status: open
title: Add check parameter to subprocess.Popen.communicate
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6445>
_______________________________________
From report at bugs.python.org Thu Jul 9 13:31:48 2009
From: report at bugs.python.org (Julian Andres Klode)
Date: Thu, 09 Jul 2009 11:31:48 +0000
Subject: [New-bugs-announce] [issue6446] import_spam() in extending python
can fail without setting the error.
In-Reply-To: <1247139108.9.0.128424367437.issue6446@psf.upfronthosting.co.za>
Message-ID: <1247139108.9.0.128424367437.issue6446@psf.upfronthosting.co.za>
New submission from Julian Andres Klode <jak at jak-linux.org>:
The given example function initspam fails if an
Based on some experience with my own code, I have found out that the
function import_spam() fails when the module is not importable. In this
case, it returns 0, although it should return -1 when an error occurs.
This causes a standalone program to crash if it has a main() function like:
Py_Initialize();
if (import_spam() < 0) {
Py_Finalize();
return 1;
}
Py_Finalize();
The function should return -1, so we can know there is an error and are
able to handle it.
----------
assignee: georg.brandl
components: Documentation
messages: 90325
nosy: georg.brandl, jak
severity: normal
status: open
title: import_spam() in extending python can fail without setting the error.
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6446>
_______________________________________
From report at bugs.python.org Thu Jul 9 16:27:33 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Thu, 09 Jul 2009 14:27:33 +0000
Subject: [New-bugs-announce] [issue6447] PATCH: typo (English) in subprocess
module
Message-ID: <1247149653.39.0.921151734241.issue6447@psf.upfronthosting.co.za>
Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:
----------
components: Library (Lib)
files: subprocess.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: PATCH: typo (English) in subprocess module
versions: Python 2.7
Added file: http://bugs.python.org/file14477/subprocess.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6447>
_______________________________________
From report at bugs.python.org Thu Jul 9 17:07:25 2009
From: report at bugs.python.org (Jordan Bettis)
Date: Thu, 09 Jul 2009 15:07:25 +0000
Subject: [New-bugs-announce] [issue6448] imp.find_module() -- be explicity
that 'path' must be a list
In-Reply-To: <1247152045.93.0.157775961524.issue6448@psf.upfronthosting.co.za>
Message-ID: <1247152045.93.0.157775961524.issue6448@psf.upfronthosting.co.za>
New submission from Jordan Bettis <jordanb at hafdconsulting.com>:
Hi. I just spent a while fighting with imp.find_module because I was
trying to pass the path as a string, rather than a string embedded in a
list:
result = find_module('mod', '/path')
rather than
result = find_module('mod', ['/path'])
The issue is compounded by an incredibly unhelpful error message:
ImportError: No frozen submodule named /path.mod
Now the documentation *does* say that path should be a list, if you read
it carefully, so perhaps it was just my reading comprehension. But doing
a google search I found a discussion from 2006 along the same lines:
http://www.techlists.org/archives/programming/pythonlist/2006-01/msg01445.shtml
So I thought it might be good to clarify that a string will not work.
Perhaps the wording could be changed to something like this:
Try to find the module *name* on the search path *path*. The
*path* argument is a list of directory names. Each directory is
searched for files with any of the suffixes returned
by :func:`get_suffixes` above. Invalid names in the list are
silently ignored (but all list items must be strings). If
*path* is omitted or ``None``, the list of directory names
given by ``sys.path`` is searched, but first it searches a few
special places: it tries to find a built-in module with the
given name (:const:`C_BUILTIN`), then a frozen
module (:const:`PY_FROZEN`), and on some systems some other
places are looked in as well (on Windows, it looks in the
registry which may point to a specific file).
I think what is confusing is the conditional about the type of 'path',
The possibilities are 'list' or 'not present' (or None) but when I read
it I think I saw the 'not present' option as being implicit, and the
conditional implying that it could be a string or a list of strings.
>From the discussion above it seems like the other person had the same
trouble, so removing the conditional should be enough to make it clear
that path *must* be a list if it exists.
----------
assignee: georg.brandl
components: Documentation
messages: 90333
nosy: georg.brandl, jordanb
severity: normal
status: open
title: imp.find_module() -- be explicity that 'path' must be a list
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6448>
_______________________________________
From report at bugs.python.org Thu Jul 9 20:43:54 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 09 Jul 2009 18:43:54 +0000
Subject: [New-bugs-announce] [issue6449] Improve/update python.org/dev/
In-Reply-To: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
Message-ID: <1247165034.18.0.173554225695.issue6449@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
Reading python.org/dev/ I noticed a few things that could be
improved/updated:
1) in http://www.python.org/dev/implementations/ Unladen Swallow is missing;
2) in http://www.python.org/dev/contributing/ there's an "any and any"
that should probably be "any and all";
3) in the same page, in the "fixing bugs" section, there are some
**..**, is that some ReST markup that was not supposed to be there?
4) in http://www.python.org/dev/intro/ the IRC channels are not
mentioned (#python, #python-dev, #python-docs);
5) in the same page there's an XXX that should be fixed;
6) in the following line there's a "what ever" that should probably be
"whatever";
7) always there, a link to http://www.python.org/psf/donations/ should
be added in the second last paragraph;
8) in http://www.python.org/dev/buildbot/ there should probably be 3.2
in "(what will become 3.1)";
9) is http://www.python.org/dev/summary/ still alive?
10) in the last list of links in http://www.python.org/dev/ the trailing
'/' are missing, but they are present in the menu on the left;
(I'm not sure this is the right place where to report this.)
----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90340
nosy: ezio.melotti, georg.brandl
priority: low
severity: normal
status: open
title: Improve/update python.org/dev/
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6449>
_______________________________________
From report at bugs.python.org Thu Jul 9 20:49:56 2009
From: report at bugs.python.org (Erik Sandberg)
Date: Thu, 09 Jul 2009 18:49:56 +0000
Subject: [New-bugs-announce] [issue6450] normpath() sometimes maps unicode
to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
New submission from Erik Sandberg <sandberg at virtutech.com>:
On Linux, I get the following:
>>> import os
>>> os.path.normpath(u'/')
'/'
I would expect unicode to be mapped to unicode. os.path.abspath() has
the same problem, see also issue 3426.
This causes problems in my project, where a function requires its
parameters to be Unicode. Do the standard Python library functions that
operate on strings guarantee anything in general with respect to
conserving unicode? Can I make any assumption as to which codec was used
to encode the str returned from normpath?
----------
components: Library (Lib)
messages: 90341
nosy: sandberg
severity: normal
status: open
title: normpath() sometimes maps unicode to str
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6450>
_______________________________________
From martin at v.loewis.de Thu Jul 9 21:02:54 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 09 Jul 2009 21:02:54 +0200
Subject: [New-bugs-announce] [issue6450] normpath() sometimes maps
unicode to str
In-Reply-To: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
References: <1247165396.23.0.921821362773.issue6450@psf.upfronthosting.co.za>
Message-ID: <4A563EDE.4070307@v.loewis.de>
> Do the standard Python library functions that
> operate on strings guarantee anything in general with respect to
> conserving unicode? Can I make any assumption as to which codec was used
> to encode the str returned from normpath?
The bug tracker is not really a place to ask questions. Please ask them
on python-list or elsewhere, or read the source code of normpath.
From report at bugs.python.org Thu Jul 9 22:16:05 2009
From: report at bugs.python.org (Vasiliy)
Date: Thu, 09 Jul 2009 20:16:05 +0000
Subject: [New-bugs-announce] [issue6451] Additional brackets to print
In-Reply-To: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>
Message-ID: <1247170565.19.0.652670356582.issue6451@psf.upfronthosting.co.za>
New submission from Vasiliy <bazooka at megabox.ru>:
from __future__ import print_function
print('Foo','Bar')
print('FooBar')
2to3 translates it to
print(('Foo','Bar'))
print('FooBar')
is it right?
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: test.py
messages: 90349
nosy: bazooka
severity: normal
status: open
title: Additional brackets to print
type: behavior
Added file: http://bugs.python.org/file14479/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6451>
_______________________________________
From report at bugs.python.org Thu Jul 9 22:26:52 2009
From: report at bugs.python.org (Jamal Fanaian)
Date: Thu, 09 Jul 2009 20:26:52 +0000
Subject: [New-bugs-announce] [issue6452] urllib2.Request() will not work
with long authorization headers
In-Reply-To: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
Message-ID: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
New submission from Jamal Fanaian <jfanaian at gmail.com>:
While testing this bug report in Gwibber
https://bugs.launchpad.net/gwibber/+bug/397297 I found that using
urllib2.Request() with a long authorization would cause it to error and
not authenticate. I'm not sure if it is because the header wasn't being
passed or any other issue.
The header would fail when the value part of the authorization string
was 89 characters.
I was able to resolve the issue by using urllib2.HTTPBasicAuthHandler()
and urllib2.install_opener() to install it, instead of passing the
Authorization header directly to urllib2.Request().
Please let me know if I can provide more information to test the issue.
----------
components: Library (Lib)
messages: 90351
nosy: jamal
severity: normal
status: open
title: urllib2.Request() will not work with long authorization headers
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6452>
_______________________________________
From report at bugs.python.org Thu Jul 9 23:21:29 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Jul 2009 21:21:29 +0000
Subject: [New-bugs-announce] [issue6453] Improve bool TypeError message
In-Reply-To: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
Message-ID: <1247174489.94.0.772158623478.issue6453@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
>>> cc=c()
>>> bool(cc)
Traceback (most recent call last):
File "<pyshell#5>", line 1, in <module>
bool(cc)
TypeError: __bool__ should return bool or int, returned int
This is slightly jarring.
Adding ' 0 or 1' after 'or int' would be nice (and trivial).
Adding str(val) at the end after type(val) would be even nicer.
----------
components: Interpreter Core
keywords: easy
messages: 90355
nosy: tjreedy
severity: normal
status: open
title: Improve bool TypeError message
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6453>
_______________________________________
From report at bugs.python.org Fri Jul 10 01:54:20 2009
From: report at bugs.python.org (Daniel Waylonis)
Date: Thu, 09 Jul 2009 23:54:20 +0000
Subject: [New-bugs-announce] [issue6454] Add "example" keyword argument to
optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
New submission from Daniel Waylonis <danw at nekotech.com>:
It's useful to see and example or two detailing how a program should be
invoked and the expected results.
I'd like to add the "example" keyword which will be printed below the
"options:" when the usage is displayed. It would not be formatted like
the "description" string.
----------
components: Library (Lib)
messages: 90364
nosy: waylonis
severity: normal
status: open
title: Add "example" keyword argument to optparse constructor
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________
From report at bugs.python.org Fri Jul 10 08:16:06 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 10 Jul 2009 06:16:06 +0000
Subject: [New-bugs-announce] [issue6455]
Lib/distutils/tests/test_build_ext.py fails on windows
In-Reply-To: <1247206566.47.0.851600165432.issue6455@psf.upfronthosting.co.za>
Message-ID: <1247206566.47.0.851600165432.issue6455@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Extention name of shared object is ".pyd" not ".so" on windows.
I hope attached patch will fix this issue.
----------
assignee: tarek
components: Distutils, Windows
files: fix_distutils_test.patch
keywords: patch
messages: 90376
nosy: ocean-city, tarek
severity: normal
status: open
title: Lib/distutils/tests/test_build_ext.py fails on windows
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14481/fix_distutils_test.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6455>
_______________________________________
From report at bugs.python.org Fri Jul 10 12:27:37 2009
From: report at bugs.python.org (dauerbaustelle)
Date: Fri, 10 Jul 2009 10:27:37 +0000
Subject: [New-bugs-announce] [issue6456] locale.D_* and .T_* are int,
not string
In-Reply-To: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
Message-ID: <1247221657.02.0.83286673792.issue6456@psf.upfronthosting.co.za>
New submission from dauerbaustelle <jonas at lophus.org>:
The locale.D_* and locale.T_* attributes are ints with weird values
instead of strings (see documentation[1]).
Example:
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.utf8')
'en_US.utf8'
>>> locale.D_T_FMT
131112
>>> locale.D_FMT
131113
>>> locale.T_FMT
131114
>>> locale.T_FMT_AMPM
131115
It seems like the .DAY_* stuff is also broken:
>>> locale.DAY_1
131079
>>> locale.DAY_2
131080
>>> locale.DAY_7
131085
And many other variables:
>>> locale.THOUSEP
65537
The documentation says that every of these variables should be strings.
Regards,
db
[1]http://docs.python.org/library/locale.html#locale.D_T_FMT
----------
components: Library (Lib)
messages: 90384
nosy: dauerbaustelle
severity: normal
status: open
title: locale.D_* and .T_* are int, not string
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6456>
_______________________________________
From report at bugs.python.org Fri Jul 10 14:36:05 2009
From: report at bugs.python.org (Dariusz Walczak)
Date: Fri, 10 Jul 2009 12:36:05 +0000
Subject: [New-bugs-announce] [issue6457] subprocess.Popen.communicate can
lose data from output/error streams when broken input pipe occures
In-Reply-To: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
Message-ID: <1247229365.37.0.486388451669.issue6457@psf.upfronthosting.co.za>
New submission from Dariusz Walczak <dariusz.walczak at gmail.com>:
It's possible to lose data piped through standard output and/or error
streams when large ammounts of data are transfered.
Reproduction:
1) Process A spawns process B with all standard I/O pipes and transfers
large ammount of data to it (100kB in my sample).
2) Process B exits very early (doesn't process all stdin data) and puts
large amount of data into its stderr or stdout streams.
3) IOError/OSError exception if errno variable set to errno.EPIPE is
raised on process A side.
Bug:
When the exception is catched Popen object's stdout and stderr members
may not contain data put into stderr/stdout streams by process B.
Note:
Described behaviour can be observed in Python 2.6.1 on FreeBSD 7.2 as
well as on Windows XP (Pro x64, SP2, up to date).
Real life example of such early end of process B:
openssl smime -verify -CApath /some/dir with large, unsigned email.
I attach simple reproduction code (execute sender.py script).
----------
components: Library (Lib)
files: subprocess.Popen.communicate_problem_reproduction.zip
messages: 90391
nosy: dwalczak
severity: normal
status: open
title: subprocess.Popen.communicate can lose data from output/error streams when broken input pipe occures
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14482/subprocess.Popen.communicate_problem_reproduction.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6457>
_______________________________________
From report at bugs.python.org Fri Jul 10 15:28:46 2009
From: report at bugs.python.org (Sean)
Date: Fri, 10 Jul 2009 13:28:46 +0000
Subject: [New-bugs-announce] [issue6458] With logging.config.fileConfig
can't create logger without handler
In-Reply-To: <1247232526.2.0.244135072278.issue6458@psf.upfronthosting.co.za>
Message-ID: <1247232526.2.0.244135072278.issue6458@psf.upfronthosting.co.za>
New submission from Sean <sean.davis15 at googlemail.com>:
Using "logging" module I can do the following:
f = logging.Formatter("%(levelname)s: %(name)s: %(message)s")
h = logging.StreamHandler()
h.setLevel(logging.NOTSET)
h.setFormatter(f)
l = logging.getLogger()
l.addHandler(h)
l2 = logging.getLogger('x.y.z')
l2.setLevel(logging.INFO)
print len(l2.handlers)
l2.critical('critical')
l2.error('error')
l2.warning('warning')
l2.info('info')
l2.debug('debug')
Note, the l2(x.y.z) logger does not have a handler (it just propagates
to the l(root) logger's handler) but the l2 logger does have a different
level set.
When I try to do this with logging.config.fileConfig it fails saying I
have not specified a handler for the x.y.z logger. But I don't want to
specify a handler, I just want to set the level and have it propagate up
the hierarchy.
Am I doing something wrong?
Sean.
P.S. Here is the config file:
[loggers]
keys=root,xyz
[handlers]
keys=consoleStderr
[formatters]
keys=simpleFormatter
[logger_root]
level=NOTSET
handlers=consoleStderr
[logger_xyz]
level=DEBUG
qualname=x.y.z
[handler_consoleStderr]
class=StreamHandler
level=NOTSET
formatter=simpleFormatter
args=(sys.stderr,)
[formatter_simpleFormatter]
%(levelname)s: %(name)s: %(message)s
----------
messages: 90392
nosy: sean
severity: normal
status: open
title: With logging.config.fileConfig can't create logger without handler
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6458>
_______________________________________
From report at bugs.python.org Sat Jul 11 03:20:10 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 11 Jul 2009 01:20:10 +0000
Subject: [New-bugs-announce] [issue6459]
Lib/distutils\tests\test_build_ext.py fails on VC6
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
I got distutils error on Lib/distutils\tests\test_build_ext.py. I hope
attached file will fix this issue. (This should complete r64127)
E:\python-dev\py3k>py3k Lib\distutils\tests\test_build_ext.py
test_build_ext (__main__.BuildExtTestCase) ... xxmodule.c
Library c:\docume~1\whiter~1\locals~1\temp\tmpbj3fb0\Debug\docume~1
\whiter~1\l
ocals~1\temp\tmpbj3fb0\xx_d.lib ????????? c:\docume~1\whiter~1\locals~1
\temp\tm
pbj3fb0\Debug\docume~1\whiter~1\locals~1\temp\tmpbj3fb0\xx_d.exp is now
being created
ok
test_check_extensions_list (__main__.BuildExtTestCase) ... ok
test_compiler_deprecation_warning (__main__.BuildExtTestCase) ... ok
test_compiler_option (__main__.BuildExtTestCase) ... ok
test_ext_fullpath (__main__.BuildExtTestCase) ... ok
test_finalize_options (__main__.BuildExtTestCase) ... ok
test_get_outputs (__main__.BuildExtTestCase) ... foo.c
LINK : error LNK2001: External symbol "PyInit_foo" is not resolved
c:\docume~1\whiter~1\locals~1\temp\tmp1bfgxq\tempt\docume~1\whiter~1
\locals~1\te
mp\tmpnttk0b\foo_d.lib : fatal error LNK1120: External symbol 1 is not
resolved
LINK : fatal error LNK1141: Got trouble in building export file
ERROR
test_get_source_files (__main__.BuildExtTestCase) ... ok
test_optional_extension (__main__.BuildExtTestCase) ... ok
test_solaris_enable_shared (__main__.BuildExtTestCase) ... ok
test_user_site (__main__.BuildExtTestCase) ... ok
======================================================================
ERROR: test_get_outputs (__main__.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "e:\python-dev\py3k\lib\distutils\msvccompiler.py", line 524, in
link
self.spawn([self.linker] + ld_args)
File "e:\python-dev\py3k\lib\distutils\ccompiler.py", line 981, in
spawn
spawn(cmd, dry_run=self.dry_run)
File "e:\python-dev\py3k\lib\distutils\spawn.py", line 36, in spawn
_spawn_nt(cmd, search_path, dry_run=dry_run)
File "e:\python-dev\py3k\lib\distutils\spawn.py", line 77, in
_spawn_nt
"command '%s' failed with exit status %d" % (cmd[0], rc))
distutils.errors.DistutilsExecError: command '"C:\Program
Files\Microsoft Visual
Studio\VC98\BIN\link.exe"' failed with exit status 1141
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "Lib\distutils\tests\test_build_ext.py", line 323, in
test_get_outputs
cmd.run()
File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line
394, in run
self.build_extensions()
File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line
503, in bui
ld_extensions
self.build_extension(ext)
File "e:\python-dev\py3k\lib\distutils\command\build_ext.py", line
590, in bui
ld_extension
target_lang=language)
File "e:\python-dev\py3k\lib\distutils\ccompiler.py", line 791, in
link_shared
_object
extra_preargs, extra_postargs, build_temp, target_lang)
File "e:\python-dev\py3k\lib\distutils\msvccompiler.py", line 526, in
link
raise LinkError(msg)
distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual
Studio\V
C98\BIN\link.exe"' failed with exit status 1141
----------------------------------------------------------------------
Ran 11 tests in 1826.566s
FAILED (errors=1)
Traceback (most recent call last):
File "Lib\distutils\tests\test_build_ext.py", line 432, in <module>
----------
assignee: tarek
components: Distutils, Windows
files: fix_distutils_test.patch
keywords: patch
messages: 90400
nosy: ocean-city, tarek
severity: normal
status: open
title: Lib/distutils\tests\test_build_ext.py fails on VC6
versions: Python 3.2
Added file: http://bugs.python.org/file14483/fix_distutils_test.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________
From report at bugs.python.org Sat Jul 11 05:09:42 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 03:09:42 +0000
Subject: [New-bugs-announce] [issue6460] test failure in test_xmlrpc on
Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
Another apparent fallout from r73638 (issue 6267). On my gentoo system
I am currently seeing a consistent failure in test_xmlrpc of 'test_two'
in KeepaliveServerTestCase (as is the Gentoo buildbot). I made the
assert the new GreaterEqual and stuck just a tad bit of extra tracing in
(printing the contents of myRequests to stderr) and this is what I see:
rdmurray at partner:~/python/trunk>./python -m test.regrtest test_xmlrpc
Could not find '/home/rdmurray/python/trunk/Lib/test' in sys.path to
remove it
test_xmlrpc
[['POST /RPC2 HTTP/1.1\r\n']]
test test_xmlrpc failed -- Traceback (most recent call last):
File "/home/rdmurray/python/trunk/Lib/test/test_xmlrpc.py", line 550,
in test_two
self.assertGreaterEqual(len(self.RequestHandler.myRequests[-1]), 2)
AssertionError: 1 not greater than or equal to 2
1 test failed:
test_xmlrpc
The test appears to hit a time out.
If there are any tests you want me to run let me know. Oddly enough I'm
not seeing this one on 3.2.
----------
assignee: krisvale
components: Library (Lib), Tests
messages: 90402
nosy: krisvale, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test failure in test_xmlrpc on Gentoo in trunk
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________
From report at bugs.python.org Sat Jul 11 08:08:28 2009
From: report at bugs.python.org (Stuart Mentzer)
Date: Sat, 11 Jul 2009 06:08:28 +0000
Subject: [New-bugs-announce] [issue6461] multiprocessing: freezing apps on
Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
New submission from Stuart Mentzer <sgm at objexx.com>:
Freezing apps with multiprocessing on Windows seems to be broken.
First, in get_command_line in multiprocessing/forking.py I find that
this code:
if getattr(sys, 'frozen', False):
return [sys.executable, '--multiprocessing-fork']
else:
prog = 'from multiprocessing.forking import main; main()'
return [_python_exe, '-c', prog, '--multiprocessing-fork']
should be:
elif getattr(sys, 'frozen', False) and not WINEXE:
return [sys.executable, '--multiprocessing-fork']
else:
prog = 'from multiprocessing.forking import main; main()'
return [_python_exe, '-c', prog, '--multiprocessing-fork']
in order for the _python_exe set with multiprocessing.set_executable to
be used rather than your app's exe.
Second, I can then get a working "frozen" package if I include
pythonw.exe (and use set_executable to point to it) and a subset of
Python's Lib directory that my process needs to call. If this is as
intended then it needs to be documented. This may just be a flaw in py2exe.
Third, the multiprocessing documentation page description for
set_executable has example code with the older setExecutable call.
----------
components: Library (Lib)
messages: 90405
nosy: sgm
severity: normal
status: open
title: multiprocessing: freezing apps on Windows
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6461>
_______________________________________
From report at bugs.python.org Sat Jul 11 18:32:13 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 16:32:13 +0000
Subject: [New-bugs-announce] [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The buildbots periodically report failures in the bsddb3 test suite.
These are not reproducible and presumably are timing-based. It would be
best if the tests could be made to pass consistently, to make the
buildbot output more useful.
Here is one such failure that I see on a semi-regular basis on trunk
(this happens in my own tests runs as well, also not consistently):
test_bsddb3
Berkeley DB 4.7.25: (June 30, 2009)
Test path prefix: /tmp/z-test_bsddb3-11362
test test_bsddb3 failed -- Traceback (most recent call last):
File "/home/rdmurray/python/trunk/Lib/bsddb/test/test_replication.py",
line 134, in test01_basic_replication
self.assertTrue(time.time()<timeout)
AssertionError: False is not True
I will add others here as I capture examples.
----------
assignee: jcea
components: Tests
messages: 90426
nosy: jcea, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: bsddb3 intermittent test failures
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6462>
_______________________________________
From report at bugs.python.org Sat Jul 11 20:31:54 2009
From: report at bugs.python.org (Kevin Walzer)
Date: Sat, 11 Jul 2009 18:31:54 +0000
Subject: [New-bugs-announce] [issue6463] IDLE with Tk-Cocoa: Edit,
format menus hang
In-Reply-To: <1247337114.05.0.431997282863.issue6463@psf.upfronthosting.co.za>
Message-ID: <1247337114.05.0.431997282863.issue6463@psf.upfronthosting.co.za>
New submission from Kevin Walzer <wordtech at users.sourceforge.net>:
In running IDLE against a build of Tk-Cocoa (8.5.7) on OS X, the edit and
format menus sometimes hang and require a force-quit of IDLE. This happens
when I try to paste text, and also when trying to format selections of
text with indentation, etc. I've looked closely at the code for
Bindings.py, EditorWindow.py, PyShell.py, and macOSXSupport.py, and can
find no obvious reason for these problems. I am confident that the problem
is not with Tk-Cocoa itself, as copy, pasting, etc. in a basic Tkinter
text widget presents no problems, but resides instead somewhere in IDLE's
code and how it interacts with the Tk-Cocoa build. I'm testing against
Python 2.6.2.
----------
components: IDLE
messages: 90431
nosy: wordtech
severity: normal
status: open
title: IDLE with Tk-Cocoa: Edit, format menus hang
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6463>
_______________________________________
From report at bugs.python.org Sat Jul 11 20:46:58 2009
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Jul 2009 18:46:58 +0000
Subject: [New-bugs-announce] [issue6464] test_normalization failures due to
truncated NormalizationTest.txt file
In-Reply-To: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>
Message-ID: <1247338018.12.0.711917855883.issue6464@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
I worked for a while tracking down a mysterious failure in
test_normalization on my machine. I eventually discovered that a clean
checkout did not exhibit the problem. A distclean on my original
checkout did not fix the problem. By doing a diff I finally figured out
that the NormalizationTest.txt file is (a) downloaded the first time the
test is run and (b) not removed afterward and (c) not removed by distclean.
How I wound up with a truncated file I don't know, nor am I quite sure
what the best solution to this little confusion is. It seems very odd
that a file is dumped and left in the CWD by a test.
----------
components: Tests
keywords: easy
messages: 90432
nosy: r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: test_normalization failures due to truncated NormalizationTest.txt file
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6464>
_______________________________________
From report at bugs.python.org Sat Jul 11 21:58:40 2009
From: report at bugs.python.org (jkg)
Date: Sat, 11 Jul 2009 19:58:40 +0000
Subject: [New-bugs-announce] [issue6465] email.feedparser regular expression
bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
New submission from jkg <python at slashbot.com>:
If the parser is fed a chunk which ends with '\r' and the next chunk
begins with '\n', it incorrectly parses this into a line ending with
'\r' and an empty line ending with '\n' instead of a single line ending
with '\r\n'.
Test attached. Patch to follow.
----------
components: Library (Lib)
files: test_nlcre.py
messages: 90433
nosy: barry, jkg, tony_nelson
severity: normal
status: open
title: email.feedparser regular expression bug (NLCRE_crack)
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
Added file: http://bugs.python.org/file14484/test_nlcre.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6465>
_______________________________________
From report at bugs.python.org Sun Jul 12 10:20:41 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 12 Jul 2009 08:20:41 +0000
Subject: [New-bugs-announce] [issue6466] duplicate get_version() code
between cygwinccompiler and emxccompiler
In-Reply-To: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
Message-ID: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
Duplicate code, will create a single get_version() function in
distutils.util and make both commands use it + deprecate
cygwinccompiler.get_version and emxccompiler.get_version
----------
assignee: tarek
components: Distutils
messages: 90441
nosy: tarek
priority: normal
severity: normal
status: open
title: duplicate get_version() code between cygwinccompiler and emxccompiler
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6466>
_______________________________________
From report at bugs.python.org Sun Jul 12 13:57:25 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Sun, 12 Jul 2009 11:57:25 +0000
Subject: [New-bugs-announce] [issue6467] raw_input() doesn't work as
expected when it gets multiple ^D
In-Reply-To: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za>
Message-ID: <1247399845.7.0.918611986455.issue6467@psf.upfronthosting.co.za>
New submission from Lucas Prado Melo <lucaspradomelo at gmail.com>:
----------------------------------
$ cat raw_input_test.py
s = ''
try:
while True:
c = raw_input()
print c
s += c
except EOFError:
pass
$ python raw_input_test.py
test^D^Dtes
^D
$ python --version
Python 2.7a0
$ bash --version
GNU bash, version 3.2.48(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
----------------------------------
Surprisingly, though:
----------------------------------
$ python raw_input_test.py > output
test^D^D^D
$ cat output
test
----------------------------------
^D = Press Ctrl+D
I am using Ubuntu 9.04 (Jaunty Jackalope).
----------
components: IO
messages: 90443
nosy: lucaspmelo
severity: normal
status: open
title: raw_input() doesn't work as expected when it gets multiple ^D
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6467>
_______________________________________
From report at bugs.python.org Sun Jul 12 18:50:50 2009
From: report at bugs.python.org (Bosko Vukov)
Date: Sun, 12 Jul 2009 16:50:50 +0000
Subject: [New-bugs-announce] [issue6468] __missing__ not completely
implemented in dictobject.c
In-Reply-To: <1247417450.47.0.16848043509.issue6468@psf.upfronthosting.co.za>
Message-ID: <1247417450.47.0.16848043509.issue6468@psf.upfronthosting.co.za>
New submission from Bosko Vukov <bvukov at users.sourceforge.net>:
For some reason functions PyDict_GetItem ( and PyDict_GetItemString )
don't try to check for '__missing__' on subclass, but
dict_subscript(dictobject *mp, register PyObject *key) does.
Only in this function a failure to get a value using
ma_lookup checks afterwards using !PyDict_CheckExact for subclass
definition of '__missing__', and then returns a value.
Is this intended or just a half implementation ?
----------
components: None
messages: 90450
nosy: bvukov
severity: normal
status: open
title: __missing__ not completely implemented in dictobject.c
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6468>
_______________________________________
From report at bugs.python.org Sun Jul 12 21:47:10 2009
From: report at bugs.python.org (Chris Perkins)
Date: Sun, 12 Jul 2009 19:47:10 +0000
Subject: [New-bugs-announce] [issue6469] Function definition expressions
feature
In-Reply-To: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>
Message-ID: <1247428030.55.0.162346159839.issue6469@psf.upfronthosting.co.za>
New submission from Chris Perkins <chrisperkins99 at gmail.com>:
Proposed feature - function definition expressions, superficially
similar to Ruby blocks.
To be proposed on Python-ideas list.
----------
files: blocks.patch
keywords: patch
messages: 90455
nosy: grammati
severity: normal
status: open
title: Function definition expressions feature
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14487/blocks.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6469>
_______________________________________
From report at bugs.python.org Sun Jul 12 22:22:44 2009
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 12 Jul 2009 20:22:44 +0000
Subject: [New-bugs-announce] [issue6470] Tkinter import fails when running
Python.exe from a network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
New submission from Christoph Gohlke <cgohlke at uci.edu>:
On Windows Vista 64-bit, when running Python 2.6.2 (32 or 64 bit) from a
network share, e.g. \\Server\Share\python26\python.exe,
importing Tkinter fails with "WindowsError: [Error 3] The system cannot
find the path specified". See session output below for traceback.
This is due to incomplete support for long UNC (UNCW) paths such as
\\?\UNC\Server\Share\File in FixTk.py.
The attached patch solves this issue.
-Christoph
C:\>\\server\share\python26\python.exe
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "\\server\share\python26\lib\lib-tk\Tkinter.py", line 38, in <module>
import FixTk
File "\\server\share\python26\lib\lib-tk\FixTk.py", line 59, in <module>
for name in os.listdir(prefix):
WindowsError: [Error 3] The system cannot find the path specified:
u'UNC\\server\\share\\Python26\\tcl\\*.*'
----------
components: Tkinter, Windows
files: Tkinter-import-UNCW.patch
keywords: patch
messages: 90457
nosy: cgohlke
severity: normal
status: open
title: Tkinter import fails when running Python.exe from a network share
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file14488/Tkinter-import-UNCW.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6470>
_______________________________________
From report at bugs.python.org Sun Jul 12 22:54:34 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 12 Jul 2009 20:54:34 +0000
Subject: [New-bugs-announce] [issue6471] errno and strerror attributes
incorrectly set on socket.error
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
In Python 2.6, socket.error was changed to be a child class of IOError
[1]. IOError derives from EnvironmentError [2], and EnvironmentError
accepts a 2-tuple used to set the values of the errno and strerror
attributes respectively [3].
Apparently the IOError raised by the socket module are instantiated
passing (always?) 'socket error' as first arg and an instance of
socket.gaierror, socket.timeout or socket.herror (and maybe others) as
second arg.
The errno attributes ends up being a string (and not a number) and the
strerror another exception (and not a str):
>>> import socket
>>> from urllib import urlopen
>>> socket.setdefaulttimeout(0.01)
>>> try: urlopen('http://www.python.org')
... except Exception, e: err1 = e
...
>>> err1
IOError('socket error', timeout('timed out',))
>>> err1.errno
'socket error'
>>> err1.strerror
timeout('timed out',)
>>> err1.strerror.errno
>>> err1.strerror.strerror
>>>
>>> try: urlopen('http://www.pythonfoobarbaz.org')
... except Exception, e: err2 = e
...
>>> err2
IOError('socket error', gaierror(11001, 'getaddrinfo failed'))
>>> err1.errno
'socket error'
>>> err1.strerror
timeout('timed out',)
>>> err1.strerror.errno
>>> err2.errno
'socket error'
>>> err2.strerror
gaierror(11001, 'getaddrinfo failed')
>>> err2.strerror.errno
11001
>>> err2.strerror.strerror
'getaddrinfo failed'
The 'socket error' strings doesn't provide any useful information
(herror, gaierror and timeout are already subclasses of socket.error)
and it results in confusing messages like:
IOError: [Errno socket error] [Errno 11001] getaddrinfo failed
The relevant information is not accessible directly on the error but it
is in err.strerror/err.args[1].
IMHO the first arg should be the errno (if it's available) and the
second the message (e.g. 'getaddrinfo failed' or 'timed out').
The doc of socket.error [1] should be also changed because it says:
"The accompanying value is either a string telling what went wrong or a
pair (errno, string) representing an error returned by a system call,
similar to the value accompanying os.error." (and this is actually what
I'd like it to be, but right now it's something different.)
[1]: http://docs.python.org/library/socket.html#socket.error
[2]: http://docs.python.org/library/exceptions.html#exceptions.IOError
[3]:
http://docs.python.org/library/exceptions.html#exceptions.EnvironmentError
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 90458
nosy: ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: errno and strerror attributes incorrectly set on socket.error
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________
From report at bugs.python.org Mon Jul 13 02:55:53 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 13 Jul 2009 00:55:53 +0000
Subject: [New-bugs-announce] [issue6472] Inconsistent use of "iterator" in
ElementTree doc & diff between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
I can't quite sort this out, because it's difficult to see what is
intended. The documentation of xml.etree.ElementTree (19.11 in the
Library doc) uses terms like "iterator", "tree iterator", "iterable",
"list" in vague and perhaps not quite accurate ways. I can't tell from
the documentation which functions/methods return lists, which return a
generator, which return an unspecified kind of iterable, and so on.
Moreover, the results are different using ElementTree than they are
using cElementTree. In particular, getiterator() returns a list in
ElementTree and a generator in cElementTree. This can make a substantial
difference in performance when iterating over a large number of nodes
(in addition to cElementTree's parsing being what appears to be about
10x faster).
I think someone should go over the page and sort this out and make it
clear what the user can expect. (I don't think it's fair to
overgeneralize to things like "iterables" if the module is really meant
to be making a commitment to a list or a generator.) I also think that
the differences in the results of methods returned in the Python and C
versions of the module should be highlighted.
I stumbled on this trying to parses and extract individual bits of
information out of large XML files. I full well realize there are better
ways to do this (SAX, e.g.) and better ways to search than just iterate
over all the tags of the type I'm interested in, but I should still know
what to expect from ElementTree, especially because it is so wonderful!
----------
assignee: georg.brandl
components: Documentation
messages: 90465
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________
From report at bugs.python.org Mon Jul 13 05:56:51 2009
From: report at bugs.python.org (Iain Wade)
Date: Mon, 13 Jul 2009 03:56:51 +0000
Subject: [New-bugs-announce] [issue6473] hmac sha384/sha512 fails test
vectors
In-Reply-To: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
Message-ID: <1247457411.29.0.0335702117949.issue6473@psf.upfronthosting.co.za>
New submission from Iain Wade <iwade at optusnet.com.au>:
Test vectors are in the following draft rfc:
http://tools.ietf.org/html/draft-nystrom-smime-hmac-sha
The problem is that hmac.py has a hard-coded block size of 64, while
SHA-384 and SHA-512 have a 128-byte block size.
Suggested fix is either:
a/ have the various hashlib libraries export block size (like they
currently do for digest_size).
b/ parameterize blocksize to the constructor so that users can override.
c/ I have no third suggestion.
I have made available a codified version of the test vectors for your
convenience.
----------
components: Library (Lib)
files: test_vectors.py
messages: 90467
nosy: iwade
severity: normal
status: open
title: hmac sha384/sha512 fails test vectors
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14492/test_vectors.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6473>
_______________________________________
From report at bugs.python.org Mon Jul 13 16:36:45 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 13 Jul 2009 14:36:45 +0000
Subject: [New-bugs-announce] [issue6474] Inconsistent TypeError message on
function calls with wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
I think the following error messages are inconsistent and confusing:
>>> def f(a, b): pass
...
>>> f(a=1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 2 non-keyword positional arguments (1 given)
>>> f(b=1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 2 non-keyword positional arguments (0 given)
Strictly speaking, no positional arguments are given in either case, so
it should say "(0 given)" in both cases. On the other hand, the given
keyword arguments are filled into the positional argument slots, so
stating something like "(1 missing)" or "(1 unspecified)" in both cases
seems to make more sense. Any opinions?
----------
components: Interpreter Core
messages: 90485
nosy: hagen
severity: normal
status: open
title: Inconsistent TypeError message on function calls with wrong number of arguments
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________
From report at bugs.python.org Mon Jul 13 16:57:40 2009
From: report at bugs.python.org (Retro)
Date: Mon, 13 Jul 2009 14:57:40 +0000
Subject: [New-bugs-announce] [issue6475] Documentation > Tutorial > List
Comprehensions
In-Reply-To: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
Message-ID: <1247497060.84.0.358633724956.issue6475@psf.upfronthosting.co.za>
New submission from Retro <vinetouu at gmail.com>:
There's a mistake in the code snippet:
>>> freshfruit = [' banana', ' loganberry ', 'passion fruit ']
>>> [weapon.strip() for weapon in freshfruit]
['banana', 'loganberry', 'passion fruit']
The second line should be:
>>> [fruit.strip() for fruit in freshfruit]
['banana', 'loganberry', 'passion fruit']
The old code snippet had weapons as items which many people didn't like,
so the code snippet was changed into a friendlier version. Please fix
this code snippet so that weapons are not involved here, even though the
code is not broken. Thank you.
----------
assignee: georg.brandl
components: Documentation
messages: 90486
nosy: Retro, georg.brandl
severity: normal
status: open
title: Documentation > Tutorial > List Comprehensions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6475>
_______________________________________
From report at bugs.python.org Mon Jul 13 19:11:08 2009
From: report at bugs.python.org (Jose Fonseca)
Date: Mon, 13 Jul 2009 17:11:08 +0000
Subject: [New-bugs-announce] [issue6476] MSVCRT's spawnve/spawnvpe are not
thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
New submission from Jose Fonseca <jose.r.fonseca at gmail.com>:
MSVCRT's implementation of _spawnve, _spawnvpe, or any version that
takes an environ as paramater is not thread-safe, because it stores a
temporary environment string into a global variable.
_spawnve, _spawnvpe, and friends call a function named _cenvarg which
concatenate the environment strings into a global variable called
_aenvptr, which gets free'd and zero'd after each invocation.
This was causing random build failures in scons when parallel build (-j)
was enabled.
The sample application evidences this problem. It also includes a simple
workaround in python, by acquiring a global lock around os.spawnve, and
simulating P_WAIT with P_NOWAIT to avoid holding the global lock while
the child process is running. I believe something along these lines
should be done for CPython on Windows.
----------
components: Interpreter Core
files: spawnve.py
messages: 90495
nosy: jfonseca
severity: normal
status: open
title: MSVCRT's spawnve/spawnvpe are not thread safe
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14495/spawnve.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________
From report at bugs.python.org Mon Jul 13 19:20:41 2009
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 13 Jul 2009 17:20:41 +0000
Subject: [New-bugs-announce] [issue6477] Pickling of NoneType raises
PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
New submission from July Tikhonov <july.tikh at gmail.com>:
Python 3.2a0 (py3k:73749M, Jul 1 2009, 23:17:59)
[GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
[40072 refs]
>>> pickle.dumps(type(None))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.2/pickle.py", line 1358, in dumps
Pickler(f, protocol, fix_imports=fix_imports).dump(obj)
_pickle.PicklingError: Can't pickle <class 'NoneType'>: attribute
lookup builtins.NoneType failed
[40137 refs]
>>>
----------
components: Library (Lib)
messages: 90496
nosy: July
severity: normal
status: open
title: Pickling of NoneType raises PicklingError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________
From report at bugs.python.org Mon Jul 13 19:33:45 2009
From: report at bugs.python.org (Mihai Ibanescu)
Date: Mon, 13 Jul 2009 17:33:45 +0000
Subject: [New-bugs-announce] [issue6478] time.tzset does not reset
_strptime's locale time cache
In-Reply-To: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>
Message-ID: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>
New submission from Mihai Ibanescu <mihai.ibanescu at gmail.com>:
If one changes from one timezone to another within the same python
process, and if one tries to parse a time string that includes the
timezone, the library malfunctions.
See attached script for a reproducer.
The problem is that, even though time.tzset() is called, the LocaleTime
persisted in the TimeRE global is not reset. In my example, the EDT
timezone name, compiled from the previous TZ variable, is not valid
anymore in the 'Pacific/Fiji' timezone.
To witness the behavior, run the attached script with no arguments. It
will parse the time in the America/New_York timezone just fine.
Then run it with an argument (like python ttime.py 1). It will first
prime the _strptime cache in the Pacific/Fiji timezone, then attempt to
parse the same time string in the America/New_York timezone.
Finally, you can change the "if 0" to "if 1" for working around the problem.
This has been verified in 2.4.4 and 2.6.1 (did not have a chance to
verify it against python 2.6.2 yet).
----------
components: Library (Lib)
files: ttime.py
messages: 90497
nosy: mibanescu
severity: normal
status: open
title: time.tzset does not reset _strptime's locale time cache
type: behavior
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file14496/ttime.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6478>
_______________________________________
From report at bugs.python.org Mon Jul 13 21:38:15 2009
From: report at bugs.python.org (John Burnett)
Date: Mon, 13 Jul 2009 19:38:15 +0000
Subject: [New-bugs-announce] [issue6479] platform.py writes to hard coded
platform dependant "dev/null"
In-Reply-To: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
Message-ID: <1247513895.35.0.806339405592.issue6479@psf.upfronthosting.co.za>
New submission from John Burnett <python at johnburnett.com>:
The functions _syscmd_uname and _syscmd_file are hard-coded to pipe
stderr to "/dev/null", as opposed to os.devnull. On Windows, this has
the effect of creating a file called "null" to a local "dev" directory
(if the directory exists).
Attached is a fix. While the _syscmd_uname change isn't entirely
necessary on Windows due to its sys.platform check, I changed both
functions for consistency (and I'm not sure what other platforms might
not have a "/dev/null" either).
----------
components: Library (Lib)
files: devnull.patch
keywords: patch
messages: 90499
nosy: john.burnett
severity: normal
status: open
title: platform.py writes to hard coded platform dependant "dev/null"
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14497/devnull.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6479>
_______________________________________
From report at bugs.python.org Tue Jul 14 07:19:58 2009
From: report at bugs.python.org (Sean)
Date: Tue, 14 Jul 2009 05:19:58 +0000
Subject: [New-bugs-announce] [issue6480] code.runsource() parsing bug
In-Reply-To: <1247548798.14.0.468793071466.issue6480@psf.upfronthosting.co.za>
Message-ID: <1247548798.14.0.468793071466.issue6480@psf.upfronthosting.co.za>
New submission from Sean <smcallis at gmail.com>:
I'm writing a little pre-processor that just parses python snippets out
of a file and passes them to a code.InteractiveInterpreter, and I'm
noticing some somewhat nasty stuff in how runsource handles some code.
sys.version:
'2.6.2 (r262:71600, Jul 12 2009, 11:52:33) \n[GCC 4.0.1 (Apple Inc.
build 5465)]'
Doesn't work:
interpreter.runsource('print("Foo")\nprint "Bar"')
Works:
interpreter.runsource('print("Foo");print "Bar"')
Doesn't work:
interpreter.runsource('print("Foo");\nprint "Bar"')
Exact output:
>>> interpreter.runsource('print("Foo")\nprint "Bar"')
Foo
False
>>> interpreter.runsource('print("Foo");print "Bar"')
Foo
Bar
False
>>> interpreter.runsource('print("Foo");\nprint "Bar"')
Foo
False
>>>
Is this a known issue? I didn't see it while searching the bug database...
----------
components: None
messages: 90511
nosy: smcallis
severity: normal
status: open
title: code.runsource() parsing bug
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6480>
_______________________________________
From report at bugs.python.org Tue Jul 14 07:41:25 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Tue, 14 Jul 2009 05:41:25 +0000
Subject: [New-bugs-announce] [issue6481] PATCH: typo in subprocess
documentation
In-Reply-To: <1247550085.73.0.0615590411126.issue6481@psf.upfronthosting.co.za>
Message-ID: <1247550085.73.0.0615590411126.issue6481@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:
os.waitpid returns a tuple (pid, status)
----------
assignee: georg.brandl
components: Documentation
files: subprocess.patch
keywords: patch
messages: 90513
nosy: Yinon, georg.brandl
severity: normal
status: open
title: PATCH: typo in subprocess documentation
versions: Python 2.6
Added file: http://bugs.python.org/file14498/subprocess.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6481>
_______________________________________
From report at bugs.python.org Tue Jul 14 08:24:13 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Tue, 14 Jul 2009 06:24:13 +0000
Subject: [New-bugs-announce] [issue6482] PATCH: tiny simplification for
subprocess
Message-ID: <1247552653.1.0.820711824987.issue6482@psf.upfronthosting.co.za>
Changes by Yinon Ehrlich <yinoneh at users.sourceforge.net>:
----------
files: subprocess.patch
keywords: patch
nosy: Yinon
severity: normal
status: open
title: PATCH: tiny simplification for subprocess
versions: Python 2.7
Added file: http://bugs.python.org/file14499/subprocess.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6482>
_______________________________________
From report at bugs.python.org Tue Jul 14 14:03:55 2009
From: report at bugs.python.org (Julian Andres Klode)
Date: Tue, 14 Jul 2009 12:03:55 +0000
Subject: [New-bugs-announce] [issue6483] Modules are not deallocated
correctly if m_size = -1
In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
Message-ID: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za>
New submission from Julian Andres Klode <jak at jak-linux.org>:
The documentation states that m_size should be -1 if no additional
memory is needed. But this causes the objects inside the module to not
be deallocated at all.
The attached module (test) stores an object of a type 'Test', which
prints "Deallocation is happening" in it's tp_dealloc. If m_size in the
TestModule is set to -1, this is never reached. If it is 0, it is reached.
----------
components: Interpreter Core
files: test.c
messages: 90514
nosy: jak
severity: normal
status: open
title: Modules are not deallocated correctly if m_size = -1
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14500/test.c
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6483>
_______________________________________
From report at bugs.python.org Tue Jul 14 20:39:07 2009
From: report at bugs.python.org (Greg)
Date: Tue, 14 Jul 2009 18:39:07 +0000
Subject: [New-bugs-announce] [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
New submission from Greg <crackityjones2004-p at yahoo.com>:
There is currently no test_mailcap or any other standalone unit test for
the mailcap module. The only existing test is a self-test at the end of
the module.
I would like to be assigned to work on this patch.
(Why am I assigning myself to write tests for a small, older module? I'm
a complete noob to the Python-Dev community and I'm getting my feet wet
with this. Let me know if you have any advice or if I'm doing something
wrong.)
----------
components: Tests
messages: 90516
nosy: gnofi
severity: normal
status: open
title: No unit test for mailcap module
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________
From report at bugs.python.org Wed Jul 15 00:30:23 2009
From: report at bugs.python.org (Travis H.)
Date: Tue, 14 Jul 2009 22:30:23 +0000
Subject: [New-bugs-announce] [issue6485] is_finished not exported by zlib
In-Reply-To: <1247610623.98.0.0463299283071.issue6485@psf.upfronthosting.co.za>
Message-ID: <1247610623.98.0.0463299283071.issue6485@psf.upfronthosting.co.za>
New submission from Travis H. <travis+w-python.org at subspacefield.org>:
The zlib C library has the capability to indicate the end of a
compressed stream by returning a Z_STREAM_END from a call to inflate.
This allows uncompressed data to follow some compressed data. It is
necessary to know when the end of the compressed stream has been reached
so that one can query the "unused_data" attribute.
However, there is no way for python to know that the end of a compressed
stream has been reached.
I will shortly be submitting a small patch that creates a python integer
attribute called "is_finished" which evaluates to 1 when the end of a
compressed stream has been reached.
----------
components: Extension Modules
messages: 90521
nosy: solinym
severity: normal
status: open
title: is_finished not exported by zlib
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6485>
_______________________________________
From report at bugs.python.org Wed Jul 15 00:50:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 14 Jul 2009 22:50:20 +0000
Subject: [New-bugs-announce] [issue6486] Library doc introduction strangely
points to "Built-in Objects" as a starting point
In-Reply-To: <1247611820.68.0.522695154729.issue6486@psf.upfronthosting.co.za>
Message-ID: <1247611820.68.0.522695154729.issue6486@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
At the end of the introduction page of the library documentation there
is a strange suggestion to begin with "Built-in Objects" as a starting
point. The "Built-in Objects" page consists of two paragraphs that will
surely mystify people new to Python. I'm not sure where it was supposed
to point -- built-in functions? built-in types? But surely not "Built-in
Objects"?
Or another interpretation, which on deeper investigation, strikes me as
the correct one: "Built-in Objects", which references tables, operators,
etc. that don't appear on that page, is simply an introduction to
"Built-in Types", or an introduction to all the subsequent chapters. In
that case, I see the challenge for structuring the top-level chapters of
the library documentation, but perhaps these two paragraphs could simply
be moved to the introduction and the "Built-in Objects" eliminated.
Besides, aren't built-in functions and constants, which come before this
page, built-in objects too?
----------
assignee: georg.brandl
components: Documentation
messages: 90524
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Library doc introduction strangely points to "Built-in Objects" as a starting point
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6486>
_______________________________________
From report at bugs.python.org Wed Jul 15 00:52:55 2009
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 14 Jul 2009 22:52:55 +0000
Subject: [New-bugs-announce] [issue6487] Some index entries appear in black
In-Reply-To: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
Message-ID: <1247611975.16.0.815449149574.issue6487@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Some index entries appear in black. I think this happens only with
top-level entries. I can't find any pattern to which ones are in black,
so it doesn't look like black has any actual significance. The C general
index page is rich with examples.
----------
messages: 90525
nosy: MLModel
severity: normal
status: open
title: Some index entries appear in black
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6487>
_______________________________________
From report at bugs.python.org Wed Jul 15 02:55:29 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 15 Jul 2009 00:55:29 +0000
Subject: [New-bugs-announce] [issue6488] ElementTree documentation refers to
"path" with no explanation, and inconsistently
In-Reply-To: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
Message-ID: <1247619329.11.0.425030564778.issue6488@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The documentation of ElementTree mentions "path" in describing the
arguments to certain methods. However, "path" is never defined. I
realize that a "path" is (at least a partial implementation of) an
XPath, but there's nothing in the documentation to suggest that to
someone who is not aware of XPath. I also realize that there is a
reference to the external ElementTree documentation, and that
ElementTree support for XPath is documented there. I think "path" should
at least be clarified with a reference that says something like "As used
here the term 'path' refers to ElementTree's support for the XML Path
Language (XPath); see
see http://effbot.org/zone/element-xpath.htm fordetails"
Next, a swarm of nits:
The documentation of the Element methods find, findall, and findtext say
that their arguments can be a tag name or path. (Using the same wording,
which makes it strange that the argument to findtext is called
"condition" while the argument to the other two methods are called
"match". I'm sure there's something important about this distinction,
but I can't figure it out from the documentation.
The documentation of the corresponding methods of ElementTree call the
arguments "path", rather than "tag" or "condition". The real problem is
that these methods are documented with respect to the element(s) "with
the given tag". [The "the" is missing from the documentation of
ElementTree.find and findall.] The documentation says these methods are
the same as calling the corresponding method on getroot(), but whereas
the Element methods refer to tag name or path, the ElementTree methods,
although they call their arguments "path", only mention tag names.
Finally, the ElementTree methods say "path is the [top-level] element to
look for", which, it seems to me, is redundant given the first sentence
of each of each method's documentation.
----------
assignee: georg.brandl
components: Documentation
messages: 90528
nosy: MLModel, georg.brandl
severity: normal
status: open
title: ElementTree documentation refers to "path" with no explanation, and inconsistently
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6488>
_______________________________________
From report at bugs.python.org Wed Jul 15 04:02:20 2009
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 15 Jul 2009 02:02:20 +0000
Subject: [New-bugs-announce] [issue6489] Documentation of
ElementTree.Element.getiterator implies element will always
be included
In-Reply-To: <1247623340.07.0.957339027178.issue6489@psf.upfronthosting.co.za>
Message-ID: <1247623340.07.0.957339027178.issue6489@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Documentation of ElementTree.Element.getiterator implies element will
always be included, but it is only included if it matches. (It says
"creates a tree iterator with the current element as the root" and also
says, ambiguously, "iterates over this element and all the elements
below it that match the given tag".)
I also feel that it is unclear to leave the term "match" undescribed.
Especially with '*' explicitly mentioned as a possibility, it looks like
one could specify, say, 'Thing*' and get all elements whose tag names
begin with 'Thing', which does not appear to be the case. Also, using
the term "match" is confusing if one understands the term to mean match
an XPath, as (implicitly) used elsewhere in the document, unless match
also means an XPath here too, which I don't think it does. I think
"match" should be reserved for XPath matching in this documentation, and
"equals" for when that is the actual test performed, such as, I think,
in getiterator.
----------
assignee: georg.brandl
components: Documentation
messages: 90529
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of ElementTree.Element.getiterator implies element will always be included
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6489>
_______________________________________
From report at bugs.python.org Wed Jul 15 10:35:39 2009
From: report at bugs.python.org (krawyoti)
Date: Wed, 15 Jul 2009 08:35:39 +0000
Subject: [New-bugs-announce] [issue6490] os.popen documentation in 2.6 is
probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
New submission from krawyoti <krawyoti at yahoo.com>:
The documentation in Python 2.6 claims os.popen is deprecated [1]. This
is probably a false claim. I think that at some point os.popen got
confused with os.popen2, os.popen3, os.popen4 and the popen2 module, all
of which are correctly deprecated.
I bring three forward three pieces of evidence that os.popen is *not*
deprecated:
i) In Python 3.1, unlike the others, os.popen is still present and is
not even deprecated. [2]
ii) Unlike the others, using os.popen does not raise a DeprecationWarning;
iii) Unlike the others, its implementation is lifted straight from the
posix module.
--
[1] http://docs.python.org/2.6/library/os.html#os.popen
[2] http://docs.python.org/3.1/library/os.html#os.plock
----------
assignee: georg.brandl
components: Documentation
messages: 90532
nosy: georg.brandl, krawyoti
severity: normal
status: open
title: os.popen documentation in 2.6 is probably wrong
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________
From report at bugs.python.org Wed Jul 15 19:18:07 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 15 Jul 2009 17:18:07 +0000
Subject: [New-bugs-announce] [issue6491] Improve --with-dbmliborder option
In-Reply-To: <1247678287.04.0.431591668248.issue6491@psf.upfronthosting.co.za>
Message-ID: <1247678287.04.0.431591668248.issue6491@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
--with-dbmliborder option doesn't allow to specify that no dbm modules
are requested. It also doesn't affect "Anthony Baxter's gdbm module".
The attached patch allows to specify "--with-dbmliborder=" which should
disable building of all dbm modules.
----------
components: Build
files: python-dbmliborder.patch
keywords: patch
messages: 90539
nosy: Arfrever
severity: normal
status: open
title: Improve --with-dbmliborder option
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14501/python-dbmliborder.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6491>
_______________________________________
From report at bugs.python.org Thu Jul 16 00:23:08 2009
From: report at bugs.python.org (Devon)
Date: Wed, 15 Jul 2009 22:23:08 +0000
Subject: [New-bugs-announce] [issue6492] xml.etree does not escape CR,
LF and TAB characters within attribute values
In-Reply-To: <1247696588.32.0.942237333428.issue6492@psf.upfronthosting.co.za>
Message-ID: <1247696588.32.0.942237333428.issue6492@psf.upfronthosting.co.za>
New submission from Devon <devon.rueckner at temboo.com>:
similar minidom as reported in in #5752
----------
components: XML
files: test_tostring.py
messages: 90547
nosy: devon
severity: normal
status: open
title: xml.etree does not escape CR, LF and TAB characters within attribute values
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14503/test_tostring.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6492>
_______________________________________
From report at bugs.python.org Thu Jul 16 03:11:59 2009
From: report at bugs.python.org (higstar)
Date: Thu, 16 Jul 2009 01:11:59 +0000
Subject: [New-bugs-announce] [issue6493] Can not set value for structure
members larger than 32 bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
New submission from higstar <adrian at higstar.com>:
Added a test to test_bitfields.py:
def test_uint32(self):
class X(Structure):
_fields_ = [("a", c_uint32, 32)]
x = X()
x.a = 10
self.failUnlessEqual(x.a, 10)
Run in Python 2.5.2 and 2.6.2:
======================================================================
FAIL: test_uint32 (__main__.BitFieldTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_bitfields.py", line 73, in test_uint32
self.failUnlessEqual(x.a, 10)
AssertionError: 0L != 10
----------
assignee: theller
components: ctypes
messages: 90549
nosy: higstar, theller
severity: normal
status: open
title: Can not set value for structure members larger than 32 bits
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________
From report at bugs.python.org Thu Jul 16 04:05:56 2009
From: report at bugs.python.org (Leo)
Date: Thu, 16 Jul 2009 02:05:56 +0000
Subject: [New-bugs-announce] [issue6494] xmlrpc client does not support HTTPS
In-Reply-To: <1247709956.54.0.66653244399.issue6494@psf.upfronthosting.co.za>
Message-ID: <1247709956.54.0.66653244399.issue6494@psf.upfronthosting.co.za>
New submission from Leo <thelists at optusnet.com.au>:
I just downloaded and installed V3.1 on Ubuntu and get the following error.
File "/usr/local/lib/python3.1/xmlrpc/client.py", line 1183, in send_request
"your version of http.client doesn't support HTTPS")
Thanks,
Leo
----------
messages: 90551
nosy: lister171254
severity: normal
status: open
title: xmlrpc client does not support HTTPS
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6494>
_______________________________________
From report at bugs.python.org Thu Jul 16 10:46:11 2009
From: report at bugs.python.org (tq0fqeu)
Date: Thu, 16 Jul 2009 08:46:11 +0000
Subject: [New-bugs-announce] [issue6495] particular variable's name case
exception attributeError
In-Reply-To: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>
Message-ID: <1247733971.96.0.782275709389.issue6495@psf.upfronthosting.co.za>
New submission from tq0fqeu <tq0fqeu at gmail.com>:
To create a instance of Class Person
[code]
rosss = Person('ross')
rosss.sayHi()
rosss.howMany()
[/code]
It's OK
But
[code]
ross = Person('ross')
ross.sayHi()
ross.howMany()
[/code]
It has exception, get that:
Exception AttributeError: "'NoneType' object has no attribute
'population'" in <bound method Person.__del__ of <__main__.Person
instance at 0xb7e0b34c>> ignored
python 2.6.2 + gcc 4.3.3 + kernel 2.6.28-13-generic
----------
files: objvar.py
messages: 90564
nosy: tq0fqeu
severity: normal
status: open
title: particular variable's name case exception attributeError
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14505/objvar.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6495>
_______________________________________
From report at bugs.python.org Thu Jul 16 22:59:47 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 16 Jul 2009 20:59:47 +0000
Subject: [New-bugs-announce] [issue6496] 2to3 generates "from urllib.parse
import pathname2url"
In-Reply-To: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
Message-ID: <1247777987.6.0.0614003313413.issue6496@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Both pathname2url and url2pathname are in the urllib.request module,
but 2to3 thinks they are in urllib.parse module.
sridharr at double:~/tmp/eric1$ cat foo.py
from urllib import pathname2url, url2pathname
sridharr at double:~/tmp/eric1$ /opt/ActivePython-3.1/bin/2to3 foo.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- foo.py (original)
+++ foo.py (refactored)
@@ -1,2 +1,2 @@
-from urllib import pathname2url, url2pathname
+from urllib.parse import pathname2url, url2pathname
RefactoringTool: Files that need to be modified:
RefactoringTool: foo.py
sridharr at double:~/tmp/eric1$
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90585
nosy: srid
severity: normal
status: open
title: 2to3 generates "from urllib.parse import pathname2url"
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6496>
_______________________________________
From report at bugs.python.org Thu Jul 16 23:28:49 2009
From: report at bugs.python.org (Walter Arrighetti)
Date: Thu, 16 Jul 2009 21:28:49 +0000
Subject: [New-bugs-announce] [issue6497] Support for digital Cinema/film DPX
and Kodak Cineon image file formats in imghdr module
In-Reply-To: <1247779729.41.0.45019789349.issue6497@psf.upfronthosting.co.za>
Message-ID: <1247779729.41.0.45019789349.issue6497@psf.upfronthosting.co.za>
New submission from Walter Arrighetti <riemann.chaos at gmail.com>:
In the Digital Intermediate (DI) post-production world, as well as in
digital cinema/film technologies, video frames -especially those coming
from a film scanner- are stored in sequences of image files, whose two
primary formats are the Digital Picture Exchange (DPX,
http://en.wikipedia.org/wiki/DPX) and the Kodak Cineon
(http://en.wikipedia.org/wiki/Cineon).
This proposal of lines addiction only to imghdr module allows to
properly test DPX and Cineon files for validity, with imghdr.what()
returning either 'dpx' or 'cin' strings if either is found.
----------
components: Library (Lib)
files: imghdr_dpx_cineon_support.py
messages: 90587
nosy: waltermb
severity: normal
status: open
title: Support for digital Cinema/film DPX and Kodak Cineon image file formats in imghdr module
type: behavior
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14510/imghdr_dpx_cineon_support.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6497>
_______________________________________
From report at bugs.python.org Fri Jul 17 01:30:23 2009
From: report at bugs.python.org (Rogi)
Date: Thu, 16 Jul 2009 23:30:23 +0000
Subject: [New-bugs-announce] [issue6498] Py_Main() does not return on
SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
New submission from Rogi <rogi at linuxmail.org>:
>From teh docs:
http://docs.python.org/c-api/veryhigh.html
int Py_Main(int argc, char **argv)?
The main program for the standard interpreter. This is made
available for programs which embed Python. The argc and argv parameters
should be prepared exactly as those which are passed to a C program?s
main() function. It is important to note that the argument list may be
modified (but the contents of the strings pointed to by the argument
list are not). The return value will be the integer passed to the
sys.exit() function, 1 if the interpreter exits due to an exception, or
2 if the parameter list does not represent a valid Python command line.
Note that if an otherwise unhandled SystemError is raised, this
function will not return 1, but exit the process, as long as
Py_InspectFlag is not set.
Py_Main() still does not return on SystemExit.
----------
assignee: georg.brandl
components: Documentation
messages: 90596
nosy: Rogi, georg.brandl
severity: normal
status: open
title: Py_Main() does not return on SystemExit
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________
From report at bugs.python.org Fri Jul 17 04:20:08 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jul 2009 02:20:08 +0000
Subject: [New-bugs-announce] [issue6499] Can't import xmlrpclib,
DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
In-Reply-To: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
Message-ID: <1247797208.72.0.744238846554.issue6499@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
I'm working on #6026 and I noticed that the patch for #6267 introduced
an "import gzip" in Lib/xmlrpclib.py in r73638.
gzip tries to import zlib, and if it's not available the import fails.
This led to 3 new tests failures in the trunk: test_xmlrpc,
test_docxmlrpc and test_multiprocessing.
This also mean that the modules xmlrpclib, DocXMLRPCServer and
SimpleXMLRPCServer (and possibly others) cannot be imported anymore if
zlib is not available (they used to work on 2.6).
xmlrpclib should check if the "import gzip" fails and disable the new
gzip-related features (raising an error only when someone tries to use
them).
I don't know if this check can be moved directly on gzip but it seems
unlikely.
----------
assignee: krisvale
messages: 90599
nosy: ezio.melotti, krisvale
priority: normal
severity: normal
stage: needs patch
status: open
title: Can't import xmlrpclib, DocXMLRPCServer and SimpleXMLRPCServer when zlib is not available
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6499>
_______________________________________
From report at bugs.python.org Fri Jul 17 10:26:14 2009
From: report at bugs.python.org (simon)
Date: Fri, 17 Jul 2009 08:26:14 +0000
Subject: [New-bugs-announce] [issue6500] urllib2 maximum recursion depth
exceeded
In-Reply-To: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
Message-ID: <1247819174.12.0.0313325803352.issue6500@psf.upfronthosting.co.za>
New submission from simon <nkucyd at gmail.com>:
def __getattr__(self, attr):
# XXX this is a fallback mechanism to guard against these
# methods getting called in a non-standard order. this may be
# too complicated and/or unnecessary.
# XXX should the __r_XXX attributes be public?
if attr[:12] == '_Request__r_':
name = attr[12:]
if hasattr(Request, 'get_' + name):
getattr(self, 'get_' + name)()
return getattr(self, attr)
raise AttributeError, attr
this may cause "maximum recursion depth exceeded"
>>> import urllib2
>>> req = urllib2.Request('http://www.nbc.com')
>>> req._Request__r_method
RuntimeError: maximum recursion depth exceeded
"return getattr(self, attr)"? should it be removed?
----------
components: Library (Lib)
messages: 90612
nosy: nako521
severity: normal
status: open
title: urllib2 maximum recursion depth exceeded
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6500>
_______________________________________
From report at bugs.python.org Fri Jul 17 12:21:45 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Fri, 17 Jul 2009 10:21:45 +0000
Subject: [New-bugs-announce] [issue6501] Fatal LookupError: unknown
encoding: cp0 on Windows embedded startup.
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:
When using Python 3.1 for Apache/mod_wsgi (3.0c4) on Windows, Apache will
crash on startup because Python is forcing the process to exit with:
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp0
I first mentioned this on issue6393, but have now created it as a separate
issue as appears to be distinct from the issue on MacOS X, athough possibly
related.
In the Windows case there is actually an encoding, that of 'cp0' where as on
MacOS X, the encoding name was empty.
The same mod_wsgi code works fine under Python 3.1 on MacOS X.
----------
components: Interpreter Core, Windows
messages: 90616
nosy: grahamd
severity: normal
status: open
title: Fatal LookupError: unknown encoding: cp0 on Windows embedded startup.
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________
From report at bugs.python.org Fri Jul 17 13:27:02 2009
From: report at bugs.python.org (kai zhu)
Date: Fri, 17 Jul 2009 11:27:02 +0000
Subject: [New-bugs-announce] [issue6502] documentation error: missing comma
between kwonlyargcount & nlocals
In-Reply-To: <1247830022.67.0.951938723623.issue6502@psf.upfronthosting.co.za>
Message-ID: <1247830022.67.0.951938723623.issue6502@psf.upfronthosting.co.za>
New submission from kai zhu <kaizhu256 at gmail.com>:
missing comma between kwonlyargcount & nlocals
class code(object)
| code(argcount, kwonlyargcount nlocals, stacksize, flags, codestring,
| constants, names, varnames, filename, name, firstlineno,
| lnotab[, freevars[, cellvars]])
----------
assignee: georg.brandl
components: Documentation
messages: 90619
nosy: georg.brandl, kaizhu
severity: normal
status: open
title: documentation error: missing comma between kwonlyargcount & nlocals
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6502>
_______________________________________
From report at bugs.python.org Fri Jul 17 15:14:36 2009
From: report at bugs.python.org (Michael Kesper)
Date: Fri, 17 Jul 2009 13:14:36 +0000
Subject: [New-bugs-announce] [issue6503] Python Docs: 6.6.4. Mutable
Sequence Types
In-Reply-To: <1247836476.38.0.640968840899.issue6503@psf.upfronthosting.co.za>
Message-ID: <1247836476.38.0.640968840899.issue6503@psf.upfronthosting.co.za>
New submission from Michael Kesper <mkesper at schokokeks.org>:
In http://docs.python.org/library/stdtypes.html#mutable-sequence-types
s.pop([i]) is listed. Correct would be:
s.pop(i)
----------
assignee: georg.brandl
components: Documentation
messages: 90623
nosy: georg.brandl, mkesper
severity: normal
status: open
title: Python Docs: 6.6.4. Mutable Sequence Types
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6503>
_______________________________________
From report at bugs.python.org Fri Jul 17 17:36:09 2009
From: report at bugs.python.org (kai zhu)
Date: Fri, 17 Jul 2009 15:36:09 +0000
Subject: [New-bugs-announce] [issue6504] infinite recursion from calling
builtins.open()
In-Reply-To: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
Message-ID: <1247844969.58.0.287534577391.issue6504@psf.upfronthosting.co.za>
New submission from kai zhu <kaizhu256 at gmail.com>:
# copy this to test.py
# > touch foo.txt
# > python3.1 -c "import test; import collections"
# > ...
# > File "test.py", line 5, in find_module
# > def find_module(self, mname, path = None): open("foo.txt")
# > File "test.py", line 5, in find_module
# > def find_module(self, mname, path = None): open("foo.txt")
# > File "test.py", line 5, in find_module
# > def find_module(self, mname, path = None): open("foo.txt")
# > File "test.py", line 5, in find_module
# > def find_module(self, mname, path = None): open("foo.txt")
# > RuntimeError: maximum recursion depth exceeded while calling a
# > Python object
class importer(object):
def find_module(self, mname, path = None): open("foo.txt")
import sys; sys.meta_path.append(importer)
***
# note recursion behavior stops if we don't call open()
class importer(object):
def find_module(self, mname, path = None): pass
import sys; sys.meta_path.append(importer)
----------
components: IO, Interpreter Core
messages: 90627
nosy: kaizhu
severity: normal
status: open
title: infinite recursion from calling builtins.open()
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6504>
_______________________________________
From report at bugs.python.org Fri Jul 17 17:39:10 2009
From: report at bugs.python.org (csmayfield)
Date: Fri, 17 Jul 2009 15:39:10 +0000
Subject: [New-bugs-announce] [issue6505] Minor typos in tutorial (i/o
chapter)
In-Reply-To: <1247845150.31.0.529218461562.issue6505@psf.upfronthosting.co.za>
Message-ID: <1247845150.31.0.529218461562.issue6505@psf.upfronthosting.co.za>
New submission from csmayfield <csmayfield at gmail.com>:
In tutorial/inputoutput.html:
"This also greater control over how the value is formatted. The
following example truncates the Pi to three places after the decimal."
Should be:
"This allows greater control over how the value is formatted. The
following example truncates pi to three places after the decimal."
Next subsection:
"However, because this old style of formatting will eventually removed
from the language str.format() should generally be used."
Should be:
"However, because this old style of formatting will eventually be
removed from the language, str.format() should generally be used."
----------
assignee: georg.brandl
components: Documentation
messages: 90628
nosy: csmayfield, georg.brandl
severity: normal
status: open
title: Minor typos in tutorial (i/o chapter)
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6505>
_______________________________________
From report at bugs.python.org Fri Jul 17 19:54:19 2009
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 17 Jul 2009 17:54:19 +0000
Subject: [New-bugs-announce] [issue6506] lib2to3 fails to convert 'thread'
when not followed by a period
In-Reply-To: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
Message-ID: <1247853259.26.0.126472143198.issue6506@psf.upfronthosting.co.za>
New submission from Eric Promislow <ericp at activestate.com>:
Given this code:
import thread
print thread
$ python
ActivePython 2.6.1.1 (ActiveState Software Inc.) based on
Python 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit
(Intel)] on
win32
>>> from lib2to3.main import main
>>> print open("flip2.py").read()
import thread
print thread
>>> main('lib2to3.fixes', ['flip2.py'])
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
--- flip2.py (original)
+++ flip2.py (refactored)
@@ -1,2 +1,2 @@
-import thread
-print thread
+import _thread
+print(thread)
RefactoringTool: Files that need to be modified:
RefactoringTool: flip2.py
0
Note how "thread" in the print statement is not converted.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 90635
nosy: ericp
severity: normal
status: open
title: lib2to3 fails to convert 'thread' when not followed by a period
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6506>
_______________________________________
From report at bugs.python.org Fri Jul 17 21:06:15 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jul 2009 19:06:15 +0000
Subject: [New-bugs-announce] [issue6507] Enhance dis.dis to autocompile
codestrings
In-Reply-To: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
Message-ID: <1247857575.21.0.389925271165.issue6507@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
dis.dis(ob) currently accepts "a module, a class, a method, a function,
or a code object." But for most uses I have seen on python-list, people
start with a code snippet. They must then wrap that in a function or
remember (or lookup) a call such as compile(code, '', 'exec') to make a
code object. I propose that dis do the latter automatically. Dis already
has to branch on the input class, so I assume adding another branch
should not be difficult.
On the Python ideas list, Steven D'Aprano raised the issue of 'exec'
versus 'single' versus 'eval'. As far as dis is concerned, there seems
to be no difference between 'exec' and 'single'.
>>> dis(compile('x = x+1', '', 'single'))
1 0 LOAD_NAME 0 (x)
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 STORE_NAME 0 (x)
10 LOAD_CONST 1 (None)
13 RETURN_VALUE
>>> dis(compile('x = x+1', '', 'exec'))
1 0 LOAD_NAME 0 (x)
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 STORE_NAME 0 (x)
10 LOAD_CONST 1 (None)
13 RETURN_VALUE
Using 'exec' instead of 'eval' adds two spurious, but easily ignored, lines.
>>> dis(compile('x+1','', 'eval'))
1 0 LOAD_NAME 0 (x)
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 RETURN_VALUE
>>> dis(compile('x+1', '', 'exec'))
1 0 LOAD_NAME 0 (x)
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 POP_TOP
8 LOAD_CONST 1 (None)
11 RETURN_VALUE
Between the current doc sentences "For a single code sequence, it prints
one line per bytecode instruction." and "If no object is provided, it
disassembles the last traceback." I propose adding the following two
sentences.
"Strings are first compiled as statements to code objects with
compile(string,'','exec'). For expressions, this adds a spurious POP_TOP
and LOAD_CONST at the end."
'compile' should be cross-referenced to its listing under built-in
functions.
----------
components: Library (Lib)
messages: 90637
nosy: tjreedy
severity: normal
status: open
title: Enhance dis.dis to autocompile codestrings
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6507>
_______________________________________
From report at bugs.python.org Sat Jul 18 00:25:32 2009
From: report at bugs.python.org (Travis H.)
Date: Fri, 17 Jul 2009 22:25:32 +0000
Subject: [New-bugs-announce] [issue6508] expose setresuid
In-Reply-To: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
Message-ID: <1247869532.62.0.249757468331.issue6508@psf.upfronthosting.co.za>
New submission from Travis H. <travis+w-python.org at subspacefield.org>:
Python should expose setresuid in the same module that exposes setuid.
The reason why is complicated, but is best explained here:
http://www.eecs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
I might work on a patch to implement this.
----------
components: Extension Modules
messages: 90642
nosy: solinym
severity: normal
status: open
title: expose setresuid
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6508>
_______________________________________
From report at bugs.python.org Sat Jul 18 02:27:26 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 18 Jul 2009 00:27:26 +0000
Subject: [New-bugs-announce] [issue6509] re.py - <compiled byte-object
regular expr> encounter unexpected str-object
In-Reply-To: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
Message-ID: <1247876846.09.0.430669746251.issue6509@psf.upfronthosting.co.za>
New submission from kai zhu <kaizhu256 at gmail.com>:
>>> import re
>>> compiled = re.compile(b"a(\w)")
>>> s = b"aa"
>>> s = compiled.sub(b"a\\1", s)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File ".../lib/python3.1/re.py", line 303, in filter
return sre_parse.expand_template(template, match)
File ".../lib/python3.1/sre_parse.py", line 810, in expand_template
return sep.join(literals)
TypeError: sequence item 0: expected bytes, str found
----------
components: Library (Lib)
messages: 90650
nosy: kaizhu
severity: normal
status: open
title: re.py - <compiled byte-object regular expr> encounter unexpected str-object
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6509>
_______________________________________
From report at bugs.python.org Sat Jul 18 03:54:03 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 01:54:03 +0000
Subject: [New-bugs-announce] [issue6510] zipfile: OSError File exists
In-Reply-To: <1247882043.78.0.940486778067.issue6510@psf.upfronthosting.co.za>
Message-ID: <1247882043.78.0.940486778067.issue6510@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
sridharr at whymac:/tmp/i > wget http://google-chartwrapper.googlecode.com/
files/GChartWrapper-0.8.osx-10.5.zip
Saving to: `GChartWrapper-0.8.osx-10.5.zip'
sridharr at whymac:/tmp/i > apy -c "import zipfile; zipfile.ZipFile
('GChartWrapper-0.8.osx-10.5.zip').extractall()"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 935, in extractall
self.extract(zipinfo, path, pwd)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 923, in extract
return self._extract_member(member, path, pwd)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 960, in _extract_member
os.mkdir(targetpath)
OSError: [Errno 17] File exists: '/private/tmp/i/GChartWrapper/charts/
templatetags'
sridharr at whymac:/tmp/i >
----------
components: Library (Lib)
messages: 90652
nosy: srid
severity: normal
status: open
title: zipfile: OSError File exists
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6510>
_______________________________________
From report at bugs.python.org Sat Jul 18 05:05:25 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sat, 18 Jul 2009 03:05:25 +0000
Subject: [New-bugs-announce] [issue6511] zipfile: Invalid argument when
opening zero-sized files
In-Reply-To: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
Message-ID: <1247886325.93.0.371232374153.issue6511@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Ideally, zipfile.BadZipFile should be thrown when trying to open files
that are zero-sized.
sridharr at whymac:/tmp/i > apy -c "import zipfile; zipfile.ZipFile
('empty.zip').extractall()"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 693, in __init__
self._GetContents()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 713, in _GetContents
self._RealGetContents()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 723, in _RealGetContents
endrec = _EndRecData(fp)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/
zipfile.py", line 189, in _EndRecData
fpin.seek(-sizeEndCentDir, 2)
IOError: [Errno 22] Invalid argument
sridharr at whymac:/tmp/i >
----------
components: Library (Lib)
messages: 90653
nosy: srid
severity: normal
status: open
title: zipfile: Invalid argument when opening zero-sized files
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6511>
_______________________________________
From report at bugs.python.org Sat Jul 18 10:00:20 2009
From: report at bugs.python.org (Winfried Plappert)
Date: Sat, 18 Jul 2009 08:00:20 +0000
Subject: [New-bugs-announce] [issue6512] UnicodeDecodeError: 'utf8' codec
can't decode bytes in position 0-1: illegal encoding
In-Reply-To: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
Message-ID: <1247904020.39.0.783448767489.issue6512@psf.upfronthosting.co.za>
New submission from Winfried Plappert <Winfried.Plappert at gmx.de>:
When running the attached program, it will fail with above message on
Control-2 only! All other control keys work happily.
The same program under MS-Windows seems to work (I am under Linux, so I
can't switch easily).
My version of Python:
Python 3.1 (r31:73572, Jul 18 2009, 08:33:59)
[GCC 4.3.3] on linux2
uname -a: Linux lin-wpl 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30
19:49:51 UTC 2009 i686 GNU/Linux
Do I have to replace the line:
self.c.bind('<Control-Key-' + str(i) + '>',
lambda x=str(i): self.key_control_num(x))
with something different? str->unicode, bytes???
This does not help either:
bytes("<Control-Key-" + str(i) + ">", 'utf-8')
This program has been converted via 2to3.
----------
components: Tkinter
files: tkpy_70.py
messages: 90656
nosy: wplappert
severity: normal
status: open
title: UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding
versions: Python 3.1
Added file: http://bugs.python.org/file14517/tkpy_70.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6512>
_______________________________________
From report at bugs.python.org Sat Jul 18 10:23:43 2009
From: report at bugs.python.org (Jason Tiller)
Date: Sat, 18 Jul 2009 08:23:43 +0000
Subject: [New-bugs-announce] [issue6513] Standard Library, Warnings, 28.5.4,
example fails
In-Reply-To: <1247905423.14.0.152000712905.issue6513@psf.upfronthosting.co.za>
Message-ID: <1247905423.14.0.152000712905.issue6513@psf.upfronthosting.co.za>
New submission from Jason Tiller <jason at sonos.org>:
The example provided in section 28.5.4 (warnings) of the Standard
Library documentation fails. This example assumes that the context
manager instance ('w' in "warnings.catch_warnings(record=True) as w")
supplies a list of objects, each of which has a data attribute
'.category' that is an instance. However, the '.category' data
attribute is actually a class.
The example code fails in this way on 2.6.2:
-----
Traceback (most recent call last):
File "bob.py", line 14, in <module>
assert isinstance(w[-1].category, DeprecationWarning)
AssertionError
-----
Replacing 'isinstance' with 'issubclass' appears to satisfy the assertion.
----------
assignee: georg.brandl
components: Documentation
messages: 90658
nosy: georg.brandl, jasontiller
severity: normal
status: open
title: Standard Library, Warnings, 28.5.4, example fails
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6513>
_______________________________________
From report at bugs.python.org Sat Jul 18 16:51:26 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 18 Jul 2009 14:51:26 +0000
Subject: [New-bugs-announce] [issue6514] "python -m unittest <testmodule>"
does not run any tests
In-Reply-To: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
Message-ID: <1247928686.78.0.475658449787.issue6514@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
exarkun at boson:~$ cat > test_foo.py
from unittest import TestCase
class SomeTests(TestCase):
def test_foo(self):
pass
exarkun at boson:~$ python -m unittest test_foo
----------------------------------------------------------------------
Ran 0 tests in 0.000s
OK
exarkun at boson:~$ python -m unittest test_foo.SomeTests
Traceback (most recent call last):
File "/usr/lib/python2.5/runpy.py", line 95, in run_module
filename, loader, alter_sys)
File "/usr/lib/python2.5/runpy.py", line 52, in _run_module_code
mod_name, mod_fname, mod_loader)
File "/usr/lib/python2.5/runpy.py", line 32, in _run_code
exec code in run_globals
File "/usr/lib/python2.5/unittest.py", line 816, in <module>
main(module=None)
File "/usr/lib/python2.5/unittest.py", line 767, in __init__
self.parseArgs(argv)
File "/usr/lib/python2.5/unittest.py", line 794, in parseArgs
self.createTests()
File "/usr/lib/python2.5/unittest.py", line 800, in createTests
self.module)
File "/usr/lib/python2.5/unittest.py", line 565, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python2.5/unittest.py", line 553, in loadTestsFromName
test = obj()
File "/usr/lib/python2.5/unittest.py", line 209, in __init__
(self.__class__, methodName)
ValueError: no such test method in <class 'test_foo.SomeTests'>: runTest
exarkun at boson:~$ python -m unittest test_foo.SomeTests.test_foo
.
----------------------------------------------------------------------
Ran 1 test in 0.000s
OK
exarkun at boson:~$
I don't really know what's happening in the middle case. The first case
seems to fail because the test loader goes around looking for subclasses
of __main__.TestCase. It only finds subclasses of unittest.TestCase,
though, which it rejects.
----------
components: Library (Lib)
messages: 90681
nosy: exarkun
severity: normal
status: open
title: "python -m unittest <testmodule>" does not run any tests
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6514>
_______________________________________
From report at bugs.python.org Sat Jul 18 17:11:12 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 18 Jul 2009 15:11:12 +0000
Subject: [New-bugs-announce]
[issue6515] http://docs.python.org/dev/library/unittest.html#load-tests-protocol doesn't
make it clear when load_tests support was introduced
In-Reply-To: <1247929872.52.0.506618276219.issue6515@psf.upfronthosting.co.za>
Message-ID: <1247929872.52.0.506618276219.issue6515@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
The load_tests feature will be new in 2.7. Earlier in the unittest
documentation, there's a mention that loadTestsFromModule was changed in
2.7 to add support for load_tests. However, the main documentation for
load_tests doesn't say anything about this. It would be good to have a
note in section 26.3.7.3.1 saying load_tests was introduced in 2.7.
----------
assignee: georg.brandl
components: Documentation
messages: 90682
nosy: exarkun, georg.brandl
severity: normal
status: open
title: http://docs.python.org/dev/library/unittest.html#load-tests-protocol doesn't make it clear when load_tests support was introduced
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6515>
_______________________________________
From report at bugs.python.org Sat Jul 18 18:14:59 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 16:14:59 +0000
Subject: [New-bugs-announce] [issue6516] reset owner/group to root for
distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
New submission from Till Maas <opensource at till.name>:
Please allow to create tarballs with owner/group of files be set to root.
One possible fix is to change cmd in distutils/archive_util.py to this:
cmd = ["tar", "-cf", archive_name, "--owner=root", "--group=root", base_dir]
----------
assignee: tarek
components: Distutils
messages: 90685
nosy: tarek, till
severity: normal
status: open
title: reset owner/group to root for distutils tarballs
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________
From report at bugs.python.org Sat Jul 18 22:36:39 2009
From: report at bugs.python.org (Till Maas)
Date: Sat, 18 Jul 2009 20:36:39 +0000
Subject: [New-bugs-announce] [issue6517] configparser: add possibility to
escape formatstrings
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
New submission from Till Maas <opensource at till.name>:
There seems to be no way to add a config item with a value containing a
formatstring without this formatstring beeing handled by configparser.
A possible way to escape the formatstrings could be to double the
%-sign, e.g.:
[foo]
bar = %%(string)s
The value of the bar item should then be "%(string)s".
----------
components: Library (Lib)
messages: 90689
nosy: till
severity: normal
status: open
title: configparser: add possibility to escape formatstrings
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________
From report at bugs.python.org Sun Jul 19 03:07:46 2009
From: report at bugs.python.org (Jerzy Jalocha N)
Date: Sun, 19 Jul 2009 01:07:46 +0000
Subject: [New-bugs-announce] [issue6518] Enable 'with' statement in
ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
New submission from Jerzy Jalocha N <jjalocha at gmail.com>:
Actually, it is not possible to use the 'with' statement in the
ossaudiodev module:
>>> import ossaudiodev
>>> with ossaudiodev.open('/dev/dsp', 'r') as device:
... pass
...
Traceback (most recent call last):
File "<stdin>", line 1 in <module>
AttributeError: 'ossaudodev.oss_audio_device' object has no attribute
'__exit__'
In order to provide a similar interface as standard Python files, and
encourage safe coding practices, the 'with' statement should be
supported in the ossaudiodev module.
Thanks.
----------
components: Extension Modules
messages: 90697
nosy: jjalocha
severity: normal
status: open
title: Enable 'with' statement in ossaudiodev module
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________
From report at bugs.python.org Sun Jul 19 03:19:29 2009
From: report at bugs.python.org (Jerzy Jalocha N)
Date: Sun, 19 Jul 2009 01:19:29 +0000
Subject: [New-bugs-announce] [issue6519] Reorder 'with' statement for files
in Python Tutorial
In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za>
Message-ID: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za>
New submission from Jerzy Jalocha N <jjalocha at gmail.com>:
Actually, the Python Tutorial recommends the use of the 'with' statement
in Section 7.2.1. "Methods of File Objects":
> It is good practice to use the with keyword when dealing with file
> objects. [etc.]
But the example and description are at the very bottom of this very
large section, and are easily missed by new Python users.
If this suggestion is to be taken seriously, I suggest putting this
information at a more prominent place, somewhere at the top of the short
section 7.2. "Reading and Writing Files".
----------
assignee: georg.brandl
components: Documentation
messages: 90698
nosy: georg.brandl, jjalocha
severity: normal
status: open
title: Reorder 'with' statement for files in Python Tutorial
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6519>
_______________________________________
From report at bugs.python.org Sun Jul 19 04:52:21 2009
From: report at bugs.python.org (Senthil)
Date: Sun, 19 Jul 2009 02:52:21 +0000
Subject: [New-bugs-announce] [issue6520] urllib.urlopen does not have
timeout parameter where as urllib2.urlopen has
In-Reply-To: <1247971941.19.0.568398315734.issue6520@psf.upfronthosting.co.za>
Message-ID: <1247971941.19.0.568398315734.issue6520@psf.upfronthosting.co.za>
New submission from Senthil <orsenthil at gmail.com>:
Just noticed this while fixing another bug issue5102.
Need to figure out why urllib.urlopen does not have timeout in the first
account and if it was due to some overlook, then:
1) add timeout parameter to urllib.urlopen
2) propage it across redirects.
It may not have high implications in Py2.x, but might lead us to
problems in future in Py3.x where urlopen is a combined function.
----------
assignee: orsenthil
components: Library (Lib)
keywords: easy
messages: 90703
nosy: orsenthil
priority: normal
severity: normal
status: open
title: urllib.urlopen does not have timeout parameter where as urllib2.urlopen has
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6520>
_______________________________________
From report at bugs.python.org Sun Jul 19 15:19:41 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 19 Jul 2009 13:19:41 +0000
Subject: [New-bugs-announce] [issue6521] Contradictory documentation for
email.mime.text.MIMEText
In-Reply-To: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
Message-ID: <1248009581.26.0.315231370095.issue6521@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
It is not obvious whether encoding of an unicode argument will happen or
not:
? [...] No guessing or encoding is performed on the text data.
Changed in version 2.4: The previously deprecated _encoding argument has
been removed. Encoding happens implicitly based on the _charset argument. ?
http://docs.python.org/library/email.mime.html#email.mime.text.MIMEText
----------
assignee: georg.brandl
components: Documentation
messages: 90711
nosy: georg.brandl, pitrou
severity: normal
stage: needs patch
status: open
title: Contradictory documentation for email.mime.text.MIMEText
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6521>
_______________________________________
From report at bugs.python.org Mon Jul 20 03:15:10 2009
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Jul 2009 01:15:10 +0000
Subject: [New-bugs-announce] [issue6522] docs for unittest.expectedFailure
do not syntactically show it's a decorator
In-Reply-To: <1248052510.55.0.186681984589.issue6522@psf.upfronthosting.co.za>
Message-ID: <1248052510.55.0.186681984589.issue6522@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
If you look at the docs for the unittest.expectedFailure decorator you
will notice it shows a set of empty parentheses since it is set with a
function directive. But since it's a decorator those empty parentheses
are not accurate.
If you want to view the docs as showing common usage -- like the docs
for the other decorators in unittest -- then those empty parentheses
need to go. An @ should also probably be added as well.
But if you view it more as how the decorator is called -- like with
importlib.util.module_for_loader does -- then it should have an argument
for the callable being passed in. This would also mean that all the
other decorators in unittest need a second set of parentheses taking a
callable as their argument as well.
Perhaps it's time we added a decorator directive that adds the @ sign
and does not insert empty parentheses?
----------
assignee: georg.brandl
components: Documentation
messages: 90718
nosy: brett.cannon, georg.brandl
priority: low
severity: normal
stage: needs patch
status: open
title: docs for unittest.expectedFailure do not syntactically show it's a decorator
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6522>
_______________________________________
From report at bugs.python.org Mon Jul 20 08:12:19 2009
From: report at bugs.python.org (Leonard Kevin McGuire Jr)
Date: Mon, 20 Jul 2009 06:12:19 +0000
Subject: [New-bugs-announce] [issue6523] smtplib exception smtp.connect
TypeError encode_plain
In-Reply-To: <1248070339.45.0.0640518982252.issue6523@psf.upfronthosting.co.za>
Message-ID: <1248070339.45.0.0640518982252.issue6523@psf.upfronthosting.co.za>
New submission from Leonard Kevin McGuire Jr <kmcguire at kmcguire.org>:
------ SYSTEM INFORMATION -----
module: smtplib
system: linux
python3.0 -V
Python 3.0.1+
----- TEST CASE PYTHON SOURCE -----
import smtplib
smtp = smtplib.SMTP()
smtp.connect('mail.myserver.org')
smtp.login('myusername', 'mypassword')
----- TEST CASE EXECUTION RESULTS -----
python3.0 testcase.py
Traceback (most recent call last):
File "testcase.py", line 4, in <module>
smtp.login('myusername', 'mypassword')
File "/home/kevin/Projects/ftpwatch/smtplib.py", line 580, in login
AUTH_PLAIN + " " + encode_plain(user, password))
File "/home/kevin/Projects/ftpwatch/smtplib.py", line 545, in encode_plain
return encode_base64("\0%s\0%s" % (user, password))
File "/usr/lib/python3.0/email/base64mime.py", line 96, in body_encode
enc = b2a_base64(s[i:i + max_unencoded]).decode("ascii")
TypeError: b2a_base64() argument 1 must be bytes or buffer, not str
----------
components: Library (Lib), Unicode
messages: 90723
nosy: kmcguire
severity: normal
status: open
title: smtplib exception smtp.connect TypeError encode_plain
type: behavior
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6523>
_______________________________________
From report at bugs.python.org Mon Jul 20 08:48:31 2009
From: report at bugs.python.org (Henrik ravn)
Date: Mon, 20 Jul 2009 06:48:31 +0000
Subject: [New-bugs-announce] [issue6524] tarfile module missing
decompression support?
In-Reply-To: <1248072511.11.0.843825773543.issue6524@psf.upfronthosting.co.za>
Message-ID: <1248072511.11.0.843825773543.issue6524@psf.upfronthosting.co.za>
New submission from Henrik ravn <hravnx at gmail.com>:
When doing the following with python 2.6.2 on Windows Vista SP1:
>>> import tarfile
>>> tf = tarfile.TarFile("sometarfile.tar.bz2")
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
tf = tarfile.TarFile("sometarfile.tar.bz2")
File "C:\Python26\lib\tarfile.py", line 1570, in __init__
self.firstmember = self.next()
File "C:\Python26\lib\tarfile.py", line 2322, in next
raise ReadError(str(e))
ReadError: invalid header
This would, of course, suggest that the file was corrupted, but all
archiving tools (tar, winrar and 7-zip) handle the file without
problems.
Also:
>>> tf = tarfile.TarFile("sometarfile.tar.bz2", "r:bz2")
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
tf = tarfile.TarFile("e:/mono/mono-2.4.2.2.tar.bz2", "r:bz2")
File "C:\Python26\lib\tarfile.py", line 1510, in __init__
raise ValueError("mode must be 'r', 'a' or 'w'")
ValueError: mode must be 'r', 'a' or 'w'
which suggests that the compression support is not compiled into the
tarfile module.
----------
components: Library (Lib)
messages: 90724
nosy: hravnx
severity: normal
status: open
title: tarfile module missing decompression support?
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6524>
_______________________________________
From report at bugs.python.org Mon Jul 20 18:43:42 2009
From: report at bugs.python.org (Peter Landgren)
Date: Mon, 20 Jul 2009 16:43:42 +0000
Subject: [New-bugs-announce] [issue6525] Problem with string.lowercase in
Windows XP
In-Reply-To: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
Message-ID: <1248108222.18.0.565207839087.issue6525@psf.upfronthosting.co.za>
New submission from Peter Landgren <peter.talken at telia.com>:
string.lowercase is changed after locale.setlocale(locale.LC_ALL,'') in
Windows XP but not in Linux.
This little test script on Windows XP and Linux explains the problem:
import locale
import string
print string.lowercase
print locale.setlocale(locale.LC_ALL,'C')
print string.lowercase
print locale.setlocale(locale.LC_ALL,'')
print string.lowercase
Result on Win XP with Python 2.5.1:
abcdefghijklmnopqrstuvwxyz
C
abcdefghijklmnopqrstuvwxyz
Swedish_Sweden.1252
abcdefghijklmnopqrstuvwxyz??????????????????????????????????????
Result on Linux with Python 2.5.2:
abcdefghijklmnopqrstuvwxyz
C
abcdefghijklmnopqrstuvwxyz
sv_SE.UTF-8
abcdefghijklmnopqrstuvwxyz
----------
components: Extension Modules
messages: 90733
nosy: PeterL
severity: normal
status: open
title: Problem with string.lowercase in Windows XP
type: crash
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6525>
_______________________________________
From report at bugs.python.org Mon Jul 20 20:45:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 18:45:23 +0000
Subject: [New-bugs-announce] [issue6526] importlib.import_module affects
permissions of .pyc files subsequently created by import
In-Reply-To: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
Message-ID: <1248115523.66.0.058614511154.issue6526@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
In debugging an intermittent test failure we discovered that if '.' is
in the path and import_module is called, then what happens when
__import__ causes the creation of a .pyc file changes. Without the
forgoing, the permissions of the .py file are copied to the .pyc file
(although the fix for issue 6070 removes the execute bits if set). With
the forgoing, the write bit is set on the .pyc file even if it was not
set on the .py file.
The second behavior is how things always worked before 2.6. (Why it
changed in 2.6 I don't know, and I'm not convinced it was a change for
the better; see also issue 6074).
I will upload a test as soon as I create the issue and get an issue
number to label it with.
Note that this issue exists only 3.x, even though trunk uses the
backported import_module function from importlib.
----------
assignee: brett.cannon
components: Library (Lib)
messages: 90738
nosy: brett.cannon, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: importlib.import_module affects permissions of .pyc files subsequently created by import
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6526>
_______________________________________
From report at bugs.python.org Mon Jul 20 23:30:24 2009
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2009 21:30:24 +0000
Subject: [New-bugs-announce] [issue6527] test_ttk_guionly buildbot test
crash: Tcl_FinalizeNotifier: notifier pipe not initialized
In-Reply-To: <1248125424.97.0.178196969881.issue6527@psf.upfronthosting.co.za>
Message-ID: <1248125424.97.0.178196969881.issue6527@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The buildbots occasionally crash in test_ttk_guionly with the following
output:
test_ttk_guionly
Tcl_FinalizeNotifier: notifier pipe not initialized
make: *** [buildbottest] Abort trap
program finished with exit code 2
Here is an example:
http://www.python.org/dev/buildbot/all/x86%20osx.5%203.x/builds/1209
----------
components: Library (Lib), Tests
messages: 90741
nosy: gpolo, r.david.murray
priority: normal
severity: normal
stage: test needed
status: open
title: test_ttk_guionly buildbot test crash: Tcl_FinalizeNotifier: notifier pipe not initialized
type: crash
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6527>
_______________________________________
From report at bugs.python.org Mon Jul 20 23:39:31 2009
From: report at bugs.python.org (Freiddie)
Date: Mon, 20 Jul 2009 21:39:31 +0000
Subject: [New-bugs-announce] [issue6528] builtins colored as keyword at
beginning of line
In-Reply-To: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>
Message-ID: <1248125971.41.0.191814152476.issue6528@psf.upfronthosting.co.za>
New submission from Freiddie <fei.yuanbw at gmail.com>:
I noticed in that whenever I enter "None" at the beginning of the line
in IDLE 3.1, the word is colored orange (for keywords) rather than
purple. If I insert a space right before the "None", it returns to its
normal purple color (for builtins), so it only seems to occur at the
beginning of a line. The same thing occurs to "True" and "False", but
not "list", "int", etc. This did not occur in 2.6.
----------
components: IDLE
messages: 90742
nosy: Freiddie
severity: normal
status: open
title: builtins colored as keyword at beginning of line
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6528>
_______________________________________
From report at bugs.python.org Tue Jul 21 00:54:46 2009
From: report at bugs.python.org (Danek Duvall)
Date: Mon, 20 Jul 2009 22:54:46 +0000
Subject: [New-bugs-announce] [issue6529] get{pw, gr}{nam,
[ug]id}() calls are not re-entrant
In-Reply-To: <1248130486.1.0.677109329447.issue6529@psf.upfronthosting.co.za>
Message-ID: <1248130486.1.0.677109329447.issue6529@psf.upfronthosting.co.za>
New submission from Danek Duvall <duvall at comfychair.org>:
In tracking down
6861990 getgrnam_r() str2group() function makes decisions based
on return value before it's set
(viewable on bugs.opensolaris.org), I noted that the pwd and grp modules
don't use the MT-safe interfaces to the password and group name service
tables. The _r() interfaces have been around for a long time, are
standard, and should be used if at all possible. That said, I can't
imagine it's terribly likely that people will go to the lengths
necessary to actually put multiple calls in flight at the same time in
CPython, but should it ever become easy to put this code into concurrent
threads, it'll likely fall over.
----------
components: Library (Lib)
messages: 90743
nosy: dhduvall
severity: normal
status: open
title: get{pw,gr}{nam,[ug]id}() calls are not re-entrant
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6529>
_______________________________________
From report at bugs.python.org Tue Jul 21 06:00:03 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 21 Jul 2009 04:00:03 +0000
Subject: [New-bugs-announce] [issue6530] Regression on "python -Wi" crash
In-Reply-To: <1248148803.55.0.651976757693.issue6530@psf.upfronthosting.co.za>
Message-ID: <1248148803.55.0.651976757693.issue6530@psf.upfronthosting.co.za>
New submission from Kurt B. Kaiser <kbk at shore.net>:
Rev 73196
http://svn.python.org/
view?view=rev&revision=73196
Caused regression on
http://bugs.python.org/issue1503294
when running build.sh:
(gdb) r -Wi
Starting program: /home/neal/python/trunk/
python -Wi
warning: Unable to find dynamic linker
breakpoint function.
GDB will be unable to debug shared library
initializers
and track explicitly loaded dynamic code.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1190)]
Fatal Python error: PyThreadState_Get: no
current thread
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 1190)]
0xb7e80021 in kill () from /lib/libc.so.6
(gdb) bt
#0 0xb7e80021 in kill () from /lib/libc.so.6
#1 0xb7f9cce1 in pthread_kill () from /lib/
libpthread.so.0
#2 0xb7f9d05b in raise () from /lib/
libpthread.so.0
#3 0xb7e7fc54 in raise () from /lib/
libc.so.6
#4 0xb7e8140d in abort () from /lib/libc.so.6
#5 0x08112084 in Py_FatalError (
msg=0x818d1c4 "PyThreadState_Get: no
current
thread")
at Python/pythonrun.c:1660
#6 0x0810e56c in PyThreadState_Get () at
Python/
pystate.c:310
#7 0x0808b5e4 in PyDict_GetItem
(op=0xb7e19034, key=0xb7e18028)
at Objects/dictobject.c:718
#8 0x080aa542 in PyString_InternInPlace
(p=0xbffff900)
at Objects/stringobject.c:5143
#9 0x0809df48 in PyString_FromString
(str=0xbffffbc2 "i")
at Objects/stringobject.c:163
#10 0x081180d5 in PySys_AddWarnOption
(s=0xbffffbc2 "i")
at Python/sysmodule.c:985
#11 0x08058b8c in Py_Main (argc=2,
argv=0xbffffa84) at Modules/main.c:415
#12 0x0805811e in main (argc=2,
argv=0xbffffa84) at Modules/python.c:23
----------
assignee: benjamin.peterson
components: Interpreter Core
keywords: needs review
messages: 90748
nosy: benjamin.peterson, kbk
priority: normal
severity: normal
status: open
title: Regression on "python -Wi" crash
type: crash
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6530>
_______________________________________
From report at bugs.python.org Tue Jul 21 13:19:29 2009
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 21 Jul 2009 11:19:29 +0000
Subject: [New-bugs-announce] [issue6531] atexit_callfuncs() crashing within
Py_Finalize() when using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
New submission from Graham Dumpleton <Graham.Dumpleton at gmail.com>:
I am seeing a crash within Py_Finalize() with Python 3.0 in mod_wsgi. It looks like the
patches for issue-4200 were not adequate and that this wasn't picked up at the time.
This new problem I am seeing looks like it may be linked to where the 'atexit' module is
initialised/imported in a sub interpreter but never imported in the main interpreter. I can
avoid the crash by having:
PyImport_ImportModule("atexit");
Py_Finalize();
At a guess, the problem is because in atexit_callfuncs():
module = PyState_FindModule(&atexitmodule);
if (module == NULL)
return;
still returns a module for case where imported in a sub interpreter but not in main
interpreter, so doesn't return, but then code which follows:
modstate = GET_ATEXIT_STATE(module);
if (modstate->ncallbacks == 0)
return;
returns NULL for modstate for the main interpreter as PyInit_atexit() had never been called
for the main interpreter as the 'atexit' module was never imported within that interpreter.
The fix would appear to be to check modstate for being NULL and return. Ie.,
module = PyState_FindModule(&atexitmodule);
if (module == NULL)
return;
modstate = GET_ATEXIT_STATE(module);
if (modstate == NULL)
return;
if (modstate->ncallbacks == 0)
return;
The only thing I am uncertain about is why PyState_FindModule() would return an object. I
cant find any documentation about that function so not entirely sure what it is meant to do.
I would have thought it would be returning data specific to the interpreter, but if never
imported in that interpreter, why would there still be an object recorded.
BTW, I have marked this as for Python 3.1 as well, but haven't tested it on that. The code in
'atexit' module doesn't appear to have changed though so assuming it will die there as well.
For now am using the workaround in mod_wsgi.
----------
components: Interpreter Core
messages: 90753
nosy: grahamd
severity: normal
status: open
title: atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters.
type: crash
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6531>
_______________________________________
From report at bugs.python.org Tue Jul 21 16:25:25 2009
From: report at bugs.python.org (Wojciech Lichota)
Date: Tue, 21 Jul 2009 14:25:25 +0000
Subject: [New-bugs-announce] [issue6532] thread.get_ident() should return
unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
New submission from Wojciech Lichota <wojciech at lichota.pl>:
In glibc library (on linux) pthread_t is defined as:
typedef unsigned long int pthread_t;
But python thread module interprets this value as signed long.
Reproduce:
>>> import thread
>>> thread.get_ident()
In some cases it returns negative value.
Checked in python 2.4, 2.5, 2.6
Proposal:
In my opinion code that cast value returned by pthread_self() should be
changed (see: Python/thread_pthread.h).
Other possibility is to change only returned value by get_ident
function. In this case it should use PyLong_FromUnsignedLong (see:
Modules/threadmodule.c).
Background:
logging module uses 'thread.get_ident()' to save thread_id in logs. If
the same application uses some C library that also writes in log file
some info with thread_id, in some situations this numbers are diffrent.
This complicate logs analyze.
----------
components: Library (Lib)
messages: 90761
nosy: sargo
severity: normal
status: open
title: thread.get_ident() should return unsigned value
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6532>
_______________________________________
From report at bugs.python.org Tue Jul 21 18:01:19 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 16:01:19 +0000
Subject: [New-bugs-announce] [issue6533] Make test_xmlrpc_net functional in
the absence of time.xmlrpc.com
In-Reply-To: <1248192079.14.0.84793941186.issue6533@psf.upfronthosting.co.za>
Message-ID: <1248192079.14.0.84793941186.issue6533@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
It seems like time.xmlrpc.com is gone (again?). That service was
provided by userland.com, who have an xmlrpc server that they mention in
their documentation examples (see for example
http://frontier.userland.com/changes/kernel71) which argues that they
will probably keep the service alive.
The attached patch adds a second test to test_xmlrpc_net to access the
example service directly at userland, and changes both tests to raise
unittest.SkipTest if the service is not accessible.
----------
assignee: r.david.murray
components: Tests
files: test_xmlrpc_net.patch
keywords: easy, patch, patch
messages: 90763
nosy: r.david.murray
priority: low
severity: normal
stage: patch review
status: open
title: Make test_xmlrpc_net functional in the absence of time.xmlrpc.com
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14528/test_xmlrpc_net.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6533>
_______________________________________
From report at bugs.python.org Tue Jul 21 19:03:22 2009
From: report at bugs.python.org (Luke-Jr)
Date: Tue, 21 Jul 2009 17:03:22 +0000
Subject: [New-bugs-announce] [issue6534] os.makedirs returns EACCES for "C:\"
In-Reply-To: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>
Message-ID: <1248195802.84.0.161288296569.issue6534@psf.upfronthosting.co.za>
New submission from Luke-Jr <luke-jr at users.sourceforge.net>:
Should return EEXIST or EISDIR provided C:\ actually exists
----------
components: Windows
messages: 90764
nosy: luke-jr
severity: normal
status: open
title: os.makedirs returns EACCES for "C:\"
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6534>
_______________________________________
From report at bugs.python.org Tue Jul 21 21:27:49 2009
From: report at bugs.python.org (Daniel Kaplun)
Date: Tue, 21 Jul 2009 19:27:49 +0000
Subject: [New-bugs-announce] [issue6535] optparse required field for Options
In-Reply-To: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
Message-ID: <1248204469.91.0.747237681609.issue6535@psf.upfronthosting.co.za>
New submission from Daniel Kaplun <min at dvir.us>:
In the second example to allow usage of the required field for options,
it seems as if you already have all you need to implement the feature
into optparse. I modified it a bit to allow OptionGroups:
class Option(optparse.Option):
ATTRS = optparse.Option.ATTRS + ['required']
def _check_required(self):
if self.required and not self.takes_value():
raise OptionError(
"required flag set for option that doesn't take a value",
self)
# Make sure _check_required() is called from the constructor!
CHECK_METHODS = optparse.Option.CHECK_METHODS + [_check_required]
def process(self, opt, value, values, parser):
optparse.Option.process(self, opt, value, values, parser)
parser.option_seen[self] = 1
class OptionParser(optparse.OptionParser):
def _init_parsing_state(self):
optparse.OptionParser._init_parsing_state(self)
self.option_seen = {}
def check_values(self, values, args):
for option in self.option_list + sum((optiongroup.option_list for
optiongroup in self.option_groups), []):
if isinstance(option, Option) and option.required and not
self.option_seen.has_key(option):
self.error("%s not supplied" % (option, ))
return (values, args)
The question: why hasn't your existing example been merged with the
OptionParse code to allow the required field for options?
----------
components: Extension Modules
messages: 90767
nosy: mindvirus
severity: normal
status: open
title: optparse required field for Options
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6535>
_______________________________________
From report at bugs.python.org Tue Jul 21 21:57:23 2009
From: report at bugs.python.org (Kurt McKee)
Date: Tue, 21 Jul 2009 19:57:23 +0000
Subject: [New-bugs-announce] [issue6536] urllib2 howto contains typo
In-Reply-To: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>
Message-ID: <1248206243.89.0.549186072656.issue6536@psf.upfronthosting.co.za>
New submission from Kurt McKee <contactme at kurtmckee.org>:
At <http://docs.python.org/dev/howto/urllib2.html>,
"HHTPBasicAuthHandler" should of course be "HTTP..."
----------
assignee: georg.brandl
components: Documentation
messages: 90769
nosy: georg.brandl, kurtmckee
severity: normal
status: open
title: urllib2 howto contains typo
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6536>
_______________________________________
From report at bugs.python.org Tue Jul 21 22:00:51 2009
From: report at bugs.python.org (Eric Promislow)
Date: Tue, 21 Jul 2009 20:00:51 +0000
Subject: [New-bugs-announce] [issue6537] string.split shouldn't split on
non-breaking spaces
In-Reply-To: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>
Message-ID: <1248206451.65.0.201066321826.issue6537@psf.upfronthosting.co.za>
New submission from Eric Promislow <ericp at activestate.com>:
ActivePython 2.6.1.1 ...
>>> a = u"abc\x0adef"
>>> a.split()
[u'abc', u'def']
>>>
"\x0a" is a non-breaking space. This behavior means we can't
easily use split() to reflow text.
----------
components: Interpreter Core
messages: 90770
nosy: ericp
severity: normal
status: open
title: string.split shouldn't split on non-breaking spaces
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6537>
_______________________________________
From report at bugs.python.org Wed Jul 22 00:29:23 2009
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2009 22:29:23 +0000
Subject: [New-bugs-announce] [issue6538] MatchObject is not a hyperlink in
the 're' module documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
In the re documentation MatchObject is marked up as a class, but since
there's no declaration of it as a class (it's a section instead) it
doesn't get turned into a hyperlink. It would be useful if it did link
to the appropriate section.
----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 90776
nosy: georg.brandl, r.david.murray
priority: low
severity: normal
stage: needs patch
status: open
title: MatchObject is not a hyperlink in the 're' module documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________
From report at bugs.python.org Wed Jul 22 01:08:18 2009
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 21 Jul 2009 23:08:18 +0000
Subject: [New-bugs-announce] [issue6539] unittest dir not created during
install
In-Reply-To: <1248217698.37.0.436469328297.issue6539@psf.upfronthosting.co.za>
Message-ID: <1248217698.37.0.436469328297.issue6539@psf.upfronthosting.co.za>
New submission from Kurt B. Kaiser <kbk at shore.net>:
rev 74095
http://svn.python.org/view?view=rev&revision=74095
didn't create the unittest dir during installation.
unittest isn't installed in its final location.
----------
assignee: benjamin.peterson
components: Build
files: Makefile.pre.in.patch
keywords: needs review, patch
messages: 90778
nosy: benjamin.peterson, kbk
priority: high
severity: normal
stage: patch review
status: open
title: unittest dir not created during install
versions: Python 2.7
Added file: http://bugs.python.org/file14531/Makefile.pre.in.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6539>
_______________________________________
From report at bugs.python.org Wed Jul 22 02:14:52 2009
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2009 00:14:52 +0000
Subject: [New-bugs-announce] [issue6540] bytearray.translate(): error in
error handling
In-Reply-To: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
Message-ID: <1248221692.97.0.916983162972.issue6540@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
bytearray.translate() crash if:
* first argument was converted to a buffer but the buffer length is not 256
bytes
* first argument is valid, but the second argument can not be converted to a
buffer
The crash occurs because PyBuffer_Release(&vdel) is called whereas vdel
buffer is not initialized.
Example with Python3:
lisa$ ./python
Python 3.2a0 (py3k:74029M, Jul 17 2009, 02:29:48)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x=bytearray(b'xyz')
>>> x.translate(b'x', 1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: translation table must be 256 characters long
>>> x.translate(b'x', 1)
Erreur de segmentation
Attached patch fixes the two cases and add an unit test for the first case. As
you can see in the example, it's an Heisenbug :-) (compile in debug bug to get
reproductible crash)
----------
components: Interpreter Core
files: bytearray.patch
keywords: patch
messages: 90786
nosy: haypo
severity: normal
status: open
title: bytearray.translate(): error in error handling
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14532/bytearray.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6540>
_______________________________________
From report at bugs.python.org Wed Jul 22 03:54:23 2009
From: report at bugs.python.org (Leon Matthews)
Date: Wed, 22 Jul 2009 01:54:23 +0000
Subject: [New-bugs-announce] [issue6541] SpooledTemporaryFile operates
differently to TemporaryFile
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
New submission from Leon Matthews <leon at lost.co.nz>:
According the docs for the tempfile module, SpooledTemporaryFile()
should operate "exactly as TemporaryFile() does". However, while
playing around trying to learn the module I found a couple of places
where this is not the case:
import tempfile
hello = bytes('Hello World!', encoding='utf-8')
tf = tempfile.TemporaryFile()
stf = tempfile.SpooledTemporaryFile()
tf.write(hello)
stf.write(hello)
# (1) Read after write behaviour differs...
>>> print(tf.read())
b'Hello World'
>>> print(stf.read())
b''
# ...unless you seek first
>>> tf.seek(0)
>>> stf.seek(0)
>>> print(tf.read())
b'Hello World'
>>> print(stf.read())
b'Hello World'
# (2) Name attribute is fragile...
>>> print(tf.name)
3
print(stf.name)
AttributeError: '_io.BytesIO' object has no attribute 'name'
# ...until StringIO object replaced
stf.rollover()
print(stf.name) # 4
I'm not sure if this should be categorised as a documentation or code
issue. In either case please be gentle -- I'm still just learning Python
(evaluating it as a [now likely] replacement for PHP for web application
development in our company). I'm filing this bug because, as a
beginner, I was confused by the inconsistency between the docs and the
actual behaviour.
I'd be happy to try and write documentation and/or unit tests about
this, if somebody would be willing to review them for me... :-)
----------
components: Library (Lib)
messages: 90789
nosy: leonov
severity: normal
status: open
title: SpooledTemporaryFile operates differently to TemporaryFile
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________
From report at bugs.python.org Wed Jul 22 04:32:04 2009
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2009 02:32:04 +0000
Subject: [New-bugs-announce] [issue6542] test_os
TestInvalidFD.test_closerange causes test_pipes hang in
certain circumstances on linux
In-Reply-To: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
Message-ID: <1248229924.23.0.0654995179292.issue6542@psf.upfronthosting.co.za>
New submission from R. David Murray <rdmurray at bitdance.com>:
The test sequence "test_ttk_guionly test_os test_pipes" hangs almost
every time when run on Gentoo x86 and Ubuntu x86_64 (at least). Note
that this is without the gui resource, so the ttk tests aren't being run.
Commenting out test_closerange in TestInvalidFD in test_os clears the
hang. Playing around with which module imports are commented out in
test_ttk_guionly can clear the hang, but test_pipes then produces the
following errors:
======================================================================
ERROR: testSimplePipe1 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/rdmurray/python/py3k/Lib/test/test_pipes.py", line 23, in
testSimplePipe1
f = t.open(TESTFN, 'w')
File "/home/rdmurray/python/py3k/Lib/pipes.py", line 148, in open
return self.open_w(file)
File "/home/rdmurray/python/py3k/Lib/pipes.py", line 168, in open_w
return os.popen(cmd, 'w')
File "/home/rdmurray/python/py3k/Lib/os.py", line 636, in popen
bufsize=buffering)
File "/home/rdmurray/python/py3k/Lib/subprocess.py", line 646, in __init__
errread, errwrite)
File "/home/rdmurray/python/py3k/Lib/subprocess.py", line 1138, in
_execute_child
os.close(errpipe_read)
OSError: [Errno 9] Bad file descriptor
======================================================================
FAIL: testSimplePipe2 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/rdmurray/python/py3k/Lib/test/test_pipes.py", line 33, in
testSimplePipe2
self.assertEqual(open(TESTFN2).read(), 'HELLO WORLD #2')
AssertionError: '' != 'HELLO WORLD #2'
The first of these appears almost every time, the second one seldom.
Occasinally both tests pass.
----------
components: Tests
messages: 90791
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_os TestInvalidFD.test_closerange causes test_pipes hang in certain circumstances on linux
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6542>
_______________________________________
From report at bugs.python.org Wed Jul 22 09:31:56 2009
From: report at bugs.python.org (Fan Decheng)
Date: Wed, 22 Jul 2009 07:31:56 +0000
Subject: [New-bugs-announce] [issue6543] traceback presented in wrong
encoding
In-Reply-To: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
Message-ID: <1248247915.99.0.198197502387.issue6543@psf.upfronthosting.co.za>
New submission from Fan Decheng <fandecheng at gmail.com>:
traceback information is wrongly encoded.
Steps to reproduce:
1. Use a version of Windows that supports CP936 (Simplified Chinese) as
the default encoding.
2. Create a directory containing Chinese characters. Such as C:\??
3. In the directory create a python file such as C:\??\test.py
4. In the python file enter the following lines
import traceback
try:
aaa # create a non-existent name
except Exception as ex:
traceback.print_exc()
5. Run the program with this command line (remember to use full path to
the test.py file):
C:\Python31\python.exe C:\??\test.py
6. See the output.
Expected result:
There is correct output without encoding problems. Such as:
Traceback (most recent call last):
File "C:\??\test.py", line 3, in <module>
NameError: name 'aaa' is not defined
Actual result:
UTF-8 encoded string is decoded using CP936 so the output is incorrect.
Traceback (most recent call last):
File "C:\???\test.py", line 3, in <module>
NameError: name 'aaa' is not defined
Additional information:
In Python 3.0, such test would generate:
File "<decoding error>", line 221, in main
In Python 3.1, the test generates the output mentioned in the repro
steps. As I tried traceback.format_exc(), it seems the original
characters ?? have become three Unicode characters when returned by
format_exc().
----------
components: Interpreter Core
messages: 90803
nosy: r_mosaic
severity: normal
status: open
title: traceback presented in wrong encoding
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6543>
_______________________________________
From report at bugs.python.org Wed Jul 22 09:52:47 2009
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Jul 2009 07:52:47 +0000
Subject: [New-bugs-announce] [issue6544] Fix refleak in kqueue implementation
In-Reply-To: <1248249167.8.0.187501055293.issue6544@psf.upfronthosting.co.za>
Message-ID: <1248249167.8.0.187501055293.issue6544@psf.upfronthosting.co.za>
New submission from Georg Brandl <georg at python.org>:
This patch should fix leaking "it" in some error conditions. Christian,
can you please review?
----------
assignee: christian.heimes
components: Extension Modules
files: select-refleak.diff
keywords: patch
messages: 90804
nosy: christian.heimes, georg.brandl
severity: normal
status: open
title: Fix refleak in kqueue implementation
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14536/select-refleak.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6544>
_______________________________________
From report at bugs.python.org Wed Jul 22 10:51:31 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 22 Jul 2009 08:51:31 +0000
Subject: [New-bugs-announce] [issue6545] test fails in
distutils.tests.test_extensions if -O is used
In-Reply-To: <1248252691.19.0.260657402484.issue6545@psf.upfronthosting.co.za>
Message-ID: <1248252691.19.0.260657402484.issue6545@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
That's because the Extension class has some assert statement, I'll
remove them.
----------
assignee: tarek
components: Distutils
messages: 90806
nosy: tarek
severity: normal
status: open
title: test fails in distutils.tests.test_extensions if -O is used
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6545>
_______________________________________
From report at bugs.python.org Wed Jul 22 16:06:56 2009
From: report at bugs.python.org (OG7)
Date: Wed, 22 Jul 2009 14:06:56 +0000
Subject: [New-bugs-announce] [issue6546] [Distutils][PATCH] Add bdist_rpm
option to select the name of the resulting package
In-Reply-To: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>
Message-ID: <1248271616.22.0.938348287661.issue6546@psf.upfronthosting.co.za>
New submission from OG7 <onyxg7 at users.sourceforge.net>:
This simple Distutils patch allows choosing the name of the rpm built by
bdist_rpm.
It leaves the name of the source tarball alone, and changes the name of
the resulting spec file and rpm.
It was tested with distutils nightlies, and applies to at least python
2.5 through 2.7dev .
----------
assignee: tarek
components: Distutils
files: 0001-Add-bdist_rpm-option-to-select-the-name-of-the-resul.patch
keywords: patch
messages: 90814
nosy: OG7, tarek
severity: normal
status: open
title: [Distutils][PATCH] Add bdist_rpm option to select the name of the resulting package
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file14537/0001-Add-bdist_rpm-option-to-select-the-name-of-the-resul.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6546>
_______________________________________
From report at bugs.python.org Wed Jul 22 22:50:23 2009
From: report at bugs.python.org (Timothee Besset)
Date: Wed, 22 Jul 2009 20:50:23 +0000
Subject: [New-bugs-announce] [issue6547] shutil.copytree fails on dangling
symlinks
In-Reply-To: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
Message-ID: <1248295823.71.0.624674043377.issue6547@psf.upfronthosting.co.za>
New submission from Timothee Besset <ttimo at idsoftware.com>:
shutil.copytree fails if there is a dangling symlink and symlink is set
to False (which is the default). It will raise an exception when trying
to get to the content of the symlink.
Tested on Debian Etch amd64, python 2.5.2
File "/usr/lib/python2.5/shutil.py", line 138, in copytree
raise Error, errors
shutil.Error: [('/opt/daemons/gameslave/.#fabfile.py',
'/tmp/tmphxInsp/gameslave/.#fabfile.py', "[Errno 2] No such file or
directory: '/opt/daemons/gameslave/.#fabfile.py'")]
$ ls -1l /opt/daemons/gameslave/.#fabfile.py
lrwxrwxrwx 1 timo quakelive 20 Jul 22 14:32
/opt/daemons/gameslave/.#fabfile.py -> timo at localhost.12341
(the link is created by emacs - means file being edited I'm guessing)
----------
components: Library (Lib)
messages: 90821
nosy: TTimo
severity: normal
status: open
title: shutil.copytree fails on dangling symlinks
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6547>
_______________________________________
From report at bugs.python.org Wed Jul 22 23:54:58 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Jul 2009 21:54:58 +0000
Subject: [New-bugs-announce] [issue6548] cmath documentation misleading:
suggests existence of real() and imag() functions
In-Reply-To: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
Message-ID: <1248299698.0.0.920100025533.issue6548@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The wording of the first section of the cmath module documentation is
confusing: the displayed blocks seem to suggest that there are real() and
imag() functions.
This first section really needs a serious rewrite. While we're at it, it
might also be nice to separate out the cmath functions into categories, in
the same way that the math module documentation is organized.
Also, 'complex plain' -> 'complex plane'.
----------
assignee: marketdickinson
components: Documentation
messages: 90824
nosy: marketdickinson
priority: normal
severity: normal
status: open
title: cmath documentation misleading: suggests existence of real() and imag() functions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6548>
_______________________________________
From report at bugs.python.org Thu Jul 23 00:10:51 2009
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 22 Jul 2009 22:10:51 +0000
Subject: [New-bugs-announce] [issue6549] ttk.Style not translating some Tcl
options
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
New submission from Mark Roseman <mark at markroseman.com>:
Just a couple of minor things which this terminal session points out
s = ttk.Style()
s.element_options('Button.label')
('-compound', '-space', '-text', '-font', '-foreground', '-underline',
'-width', '-anchor', '-justify', '-wraplength', '-embossed', '-image',
'-stipple', '-background')
s.configure('TButton', font='helvetica 24')
{}
b = ttk.Button(root)
b.configure(text='blah')
The 'element_options' call presumably shouldn't include the dashes, i.e.
'compound' rather than '-compound'
The configure call shouldn't be returning anything, akin to how configuring
a button works.
Again, just little things..
----------
components: Tkinter
messages: 90827
nosy: gpolo, markroseman
severity: normal
status: open
title: ttk.Style not translating some Tcl options
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6549>
_______________________________________
From report at bugs.python.org Thu Jul 23 00:42:51 2009
From: report at bugs.python.org (Nir Soffer)
Date: Wed, 22 Jul 2009 22:42:51 +0000
Subject: [New-bugs-announce] [issue6550] asyncore incorrect failure when
connection is refused and using async_chat channel
In-Reply-To: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
Message-ID: <1248302571.21.0.910158552759.issue6550@psf.upfronthosting.co.za>
New submission from Nir Soffer <nirsof at gmail.com>:
When using asynchat.async_chat channel, and connection is refused,
asyncore fail incorrectly.
First, instead of ECONNREFUSED, you get EPIPE, second, you also get a
EBADF exception, and finally, the channel handle_close is called twice.
The problem is the way asyncore detect a connect event. On the first
read event, asyncore set the connected flag to true, and invoke the
channel handle_connect method. Typically, the channel will try to push
something to the remote endpoint at this point. Since "connected" is
true, push() will try to send to the socket, and fail with EPIPE,
because the socket is not connected.
The socket error in push will invoke the channel handle_error, which
typically will call handle_close to close the socket.
handle_connect_event will return without any error, because the error
was handled inside push.
Now asyncore will invoke the channel handle_read method, which fails
with bad file descriptor, since the channel closed the socket on the
previous error.
How should this work correctly?
1. We want to get a connection refused error in this case
2. The failure should cause only single exception
3. The channel should be close once
I added these test to test_asyncore.py, and all of them fail with
current code.
Turns out that single line change fix all the failing tests: set the
"connected" state after the call to handle_connect, just like it used to
be in 2.5.
With this change, when the channel try to push something to the remote
endpoint, it will keep it in the fifo, since connected is false. This is
also correct, since we will know that we are connected only after
handle_read is called. In handle_read, we fail with ECONNREFUSED and
close the channel.
The fix is tested currently only on Mac OS X 10.5. I have seen this
issue also on Ubuntu 9.04.
----------
components: Library (Lib)
files: asyncore-handle-connect-event.patch
keywords: patch
messages: 90830
nosy: nirs
severity: normal
status: open
title: asyncore incorrect failure when connection is refused and using async_chat channel
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14543/asyncore-handle-connect-event.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6550>
_______________________________________
From report at bugs.python.org Thu Jul 23 07:55:54 2009
From: report at bugs.python.org (Martien Friedeman)
Date: Thu, 23 Jul 2009 05:55:54 +0000
Subject: [New-bugs-announce] [issue6552] Build Applet.app
In-Reply-To: <1248328554.77.0.248074125198.issue6552@psf.upfronthosting.co.za>
Message-ID: <1248328554.77.0.248074125198.issue6552@psf.upfronthosting.co.za>
New submission from Martien Friedeman <martien.friedeman at gmail.com>:
Hi Python maintainer!
I did not see a "Build Applet.app" in
http://www.python.org/ftp/python/3.1/python-3.1.dmg.
Could you add one please? They're great to start programs with.
Cheers
Martien Friedeman
----------
assignee: ronaldoussoren
components: Macintosh
messages: 90839
nosy: MartienF, ronaldoussoren
severity: normal
status: open
title: Build Applet.app
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6552>
_______________________________________
From report at bugs.python.org Thu Jul 23 05:04:33 2009
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 23 Jul 2009 03:04:33 +0000
Subject: [New-bugs-announce] [issue6551] test_codecs fails when ran after
test_zipimport and test_mailbox.
In-Reply-To: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
Message-ID: <1248318273.86.0.60176603488.issue6551@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti <alexandre at peadrop.com>:
For some yet unknown reason, test_codecs fails when it is run after
test_zipimport and subsequently test_mailbox:
./python Lib/test/regrtest.py -w test_zipimport test_mailbox test_codecs
[SNIP]
======================================================================
ERROR: test_basics (test.test_codecs.BasicUnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/alex/src/python.org/py3k/Lib/test/test_codecs.py", line
1360, in test_basics
encodedresult += encoder.encode(c)
File "/home/alex/src/python.org/py3k/Lib/encodings/ascii.py", line 22,
in encode
return codecs.ascii_encode(input, self.errors)[0]
AttributeError: 'NoneType' object has no attribute 'ascii_encode'
======================================================================
ERROR: test_decoder_state (test.test_codecs.BasicUnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/alex/src/python.org/py3k/Lib/test/test_codecs.py", line
1445, in test_decoder_state
self.check_state_handling_decode(encoding, u, u.encode(encoding))
File "/home/alex/src/python.org/py3k/Lib/test/test_codecs.py", line
30, in check_state_handling_decode
part1 = d.decode(s[:i])
File "/home/alex/src/python.org/py3k/Lib/encodings/ascii.py", line 26,
in decode
return codecs.ascii_decode(input, self.errors)[0]
AttributeError: 'NoneType' object has no attribute 'ascii_decode'
----------------------------------------------------------------------
Ran 121 tests in 0.204s
FAILED (errors=2)
test test_codecs failed -- errors occurred; run in verbose mode for details
----------
components: Tests
messages: 90837
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: test_codecs fails when ran after test_zipimport and test_mailbox.
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6551>
_______________________________________
From report at bugs.python.org Thu Jul 23 17:15:19 2009
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 23 Jul 2009 15:15:19 +0000
Subject: [New-bugs-announce] [issue6553] cPickle "binunicode" segmentation
fault
In-Reply-To: <1248362119.25.0.536343582132.issue6553@psf.upfronthosting.co.za>
Message-ID: <1248362119.25.0.536343582132.issue6553@psf.upfronthosting.co.za>
New submission from Patrick Strawderman <patrick at zope.com>:
When reading from a file-like object (like StringIO), cPickle uses the
read_other function, which doesn't check that the number of bytes
requested is the actual number of bytes read (like the read_cStringIO
function does).
Functions like load_binunicode falsely assume that the number of bytes
specified after the BINUNICODE instruction are the actual number of
bytes read. This can eventually lead to a segmentation fault, as
demonstrated in the following example:
import cPickle, StringIO
cPickle.Unpickler(StringIO.StringIO("X''.")).load()
I have tested and reproduced this on Python 2.4.6 (OS X 32-bit), 2.5.1
(OS X 32-bit), and 2.6.2 (Linux 64-bit).
I have not tested Python 3.x, but I believe this problem may be akin to
the one in issue4298.
----------
messages: 90847
nosy: boogenhagn
severity: normal
status: open
title: cPickle "binunicode" segmentation fault
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6553>
_______________________________________
From report at bugs.python.org Thu Jul 23 20:28:35 2009
From: report at bugs.python.org (Patricio Mariano Molina)
Date: Thu, 23 Jul 2009 18:28:35 +0000
Subject: [New-bugs-announce] [issue6554] Do we have something like
os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
New submission from Patricio Mariano Molina <patriciomolina at gmail.com>:
I couldn't find anything like os.pid_exists() in Python 2.5/2.6, neither
in bugs.python.org (this *could* be a dupe)
Do we have something like that?
Right now I'm doing this:
try:
os.kill(int(pid), 0)
return True
except OSError:
return False
I'd love to do the same without catching an exception (they're
expensive!), maybe in C?
Thanks!
----------
components: Library (Lib)
messages: 90850
nosy: pmolina
severity: normal
status: open
title: Do we have something like os.pid_exists()?
type: feature request
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6554>
_______________________________________
From report at bugs.python.org Thu Jul 23 22:07:15 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 23 Jul 2009 20:07:15 +0000
Subject: [New-bugs-announce] [issue6555] distutils config file should have
the same name on both platforms and all scopes
In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
Message-ID: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
Currently we have this:
http://docs.python.org/install/#location-and-names-of-config-files
The distutils config file can have one of four different names depending
on which platform and which location. This makes it harder for people
to remember the file's name and location, and more complicated for
programs that want to detect it. Why not give it the same name on both
platforms and all locations?
----------
assignee: tarek
components: Distutils
messages: 90860
nosy: tarek, zooko
severity: normal
status: open
title: distutils config file should have the same name on both platforms and all scopes
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6555>
_______________________________________
From report at bugs.python.org Thu Jul 23 22:09:21 2009
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Thu, 23 Jul 2009 20:09:21 +0000
Subject: [New-bugs-announce] [issue6556] "HOME" is not a standard
environment variable on Windows
In-Reply-To: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
Message-ID: <1248379761.36.0.601035706586.issue6556@psf.upfronthosting.co.za>
New submission from Zooko O'Whielacronx <zooko at zooko.com>:
The distutils looks in an environment variable named "HOME" on Windows:
http://docs.python.org/install/#location-and-names-of-config-files
Windows does not by default create such a variable, so only if a user
has manually configured one will it work. The standard variable for
this purpose on Windows appears to be spelled "USERPROFILE":
http://en.wikipedia.org/wiki/Environment_variable
----------
assignee: tarek
components: Distutils
messages: 90861
nosy: tarek, zooko
severity: normal
status: open
title: "HOME" is not a standard environment variable on Windows
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6556>
_______________________________________
From report at bugs.python.org Thu Jul 23 23:52:49 2009
From: report at bugs.python.org (Till Maas)
Date: Thu, 23 Jul 2009 21:52:49 +0000
Subject: [New-bugs-announce] [issue6557] urllib.urlopen creates bad requests
when location header of 301 redirects contain spaces
In-Reply-To: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
Message-ID: <1248385969.73.0.0313821964129.issue6557@psf.upfronthosting.co.za>
New submission from Till Maas <opensource at till.name>:
If urllib.urlopen is pointed to an url that returns a redirection with a
location header that points to a url containing spaces, that are
properly urlencoded, then it creates a bad request with the spaces not
encoded in the url. Here is an example/test case:
In [1]: import urllib
In [2]:
u=urllib.urlopen("http://sourceforge.net/project/showfiles.php?group_id=16847&package_id=13374")
In [3]: u.url
Out[3]: 'http://sourceforge.net/projects/xmlrpc-c/files/Xmlrpc-c Super
Stable/download'
In [4]: u.read()
Out[4]: '<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body
bgcolor="white">\r\n<center><h1>400 Bad
Request</h1></center>\r\n<hr><center>nginx/0.7.60</center>\r\n</body>\r\n</html>\r\n'
In [5]:
u=urllib.urlopen("http://sourceforge.net/projects/xmlrpc-c/files/Xmlrpc-c%20Super%20Stable/download")
In [6]: u.read()[0:100]
Out[6]: '\n\n<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xh'
In [7]:
----------
components: Library (Lib)
messages: 90864
nosy: till
severity: normal
status: open
title: urllib.urlopen creates bad requests when location header of 301 redirects contain spaces
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6557>
_______________________________________
From martin at v.loewis.de Fri Jul 24 01:28:52 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 24 Jul 2009 01:28:52 +0200
Subject: [New-bugs-announce] [issue6554] Do we have something
like os.pid_exists()?
In-Reply-To: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
References: <1248373715.48.0.616687111663.issue6554@psf.upfronthosting.co.za>
Message-ID: <4A68F234.6070602@v.loewis.de>
> I'd love to do the same without catching an exception (they're
> expensive!)
Why do you say that? I don't believe that exceptions are expensive
(e.g. compared to the system call)
From report at bugs.python.org Fri Jul 24 03:17:54 2009
From: report at bugs.python.org (Garrett Cooper)
Date: Fri, 24 Jul 2009 01:17:54 +0000
Subject: [New-bugs-announce] [issue6558] #ifdef linux is incorrect;
should be #ifdef __linux__ (preferred standard)
In-Reply-To: <1248398274.01.0.259740550657.issue6558@psf.upfronthosting.co.za>
Message-ID: <1248398274.01.0.259740550657.issue6558@psf.upfronthosting.co.za>
New submission from Garrett Cooper <yanegomi at gmail.com>:
The following files are looking for the `linux' constant, when it fact
they should be looking for `__linux__' (from 2.6.2 release's sources):
Modules/_ctypes/libffi/src/mips/ffitarget.h:#ifdef linux
Modules/socketmodule.c:#ifdef linux
Modules/socketmodule.c:#ifdef linux
The correct check is being made for FreeBSD (__FreeBSD__), for instance.
This is a defacto standard set by gcc, as discussed here:
<http://lists.debian.org/debian-devel/2001/01/msg00951.html>. You can
dump out all of the available constants for any given gcc compiler via:
[garrcoop at sjc-lds-102 ~/Python-2.6.2]$ echo "" | gcc -E -dM -c - | grep
linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1
I point this out because one of our compilers, doesn't have this
definition and it's tossing up errors with the linuxaudiodev and oss
modules periodically when cross-compiling, as shown below :(:
/nobackup/shujagan/tmp/contrib/python/Modules/linuxaudiodev.c:31: error:
conflicting types for 'uint32_t'
/nobackup/shujagan/tmp/linkfarm/mips32/usr/include/stdint.h:52: error:
previous declaration of 'uint32_t' was here
/nobackup/shujagan/tmp/contrib/python/Modules/ossaudiodev.c:37: error:
conflicting types for 'uint32_t'
/nobackup/shujagan/tmp/linkfarm/mips32/usr/include/stdint.h:52: error:
previous declaration of 'uint32_t' was here
We've suggested using --without-audio, but this is a standard which
should be adhered to as __linux__ is the constant of choice when looking
for the Linux compiler...
Thanks!
-Garrett
----------
assignee: theller
components: Build, Extension Modules, ctypes
messages: 90868
nosy: theller, yaneurabeya
severity: normal
status: open
title: #ifdef linux is incorrect; should be #ifdef __linux__ (preferred standard)
type: compile error
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6558>
_______________________________________
From report at bugs.python.org Fri Jul 24 09:56:37 2009
From: report at bugs.python.org (Zhigang Wang)
Date: Fri, 24 Jul 2009 07:56:37 +0000
Subject: [New-bugs-announce] [issue6559] [PATCH]add pass_fds paramter to
subprocess.Popen()
In-Reply-To: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
Message-ID: <1248422197.05.0.784368367425.issue6559@psf.upfronthosting.co.za>
New submission from Zhigang Wang <w1z2g3 at gmail.com>:
The current subprocess.Popen() has a boolean close_fds parameter, which
cannot satisfy all the requirements. Eg. want to pass specific fd to
child process, but close others.
This patch adds a extra parameter pass_fds to subprocess.Popen's
__init__(). This parameter only effect when close_fds=True. When
close_fds=True, all fds in pass_fds will not closed before exec.
----------
components: Library (Lib)
files: python-subprocess-add-pass-fds.patch
keywords: patch
messages: 90871
nosy: zhigang
severity: normal
status: open
title: [PATCH]add pass_fds paramter to subprocess.Popen()
versions: Python 3.2
Added file: http://bugs.python.org/file14555/python-subprocess-add-pass-fds.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6559>
_______________________________________
From report at bugs.python.org Fri Jul 24 10:30:19 2009
From: report at bugs.python.org (=?utf-8?q?K=C3=A1lm=C3=A1n_Gergely?=)
Date: Fri, 24 Jul 2009 08:30:19 +0000
Subject: [New-bugs-announce] [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
New submission from K?lm?n Gergely <kalman.gergely at duodecad.hu>:
This is the rewritten-from-scratch implementation of the
sendmsg()/recvmsg() methods.
Any comments / suggestions / flames are very welcome. Currently it
supports what I need
and I'm only releasing it because I don't have much time to develop it
further in the
forseeable future (1-2 months). It is rewritten from scratch, using the
python c-api
documents. I've tried my best, but I wouldn't bet that it works
error-free. I'd be glad
if someone could give me a review on what I've might done wrong.
The features that are missing:
- using scatter/gather
- using it with non-stream oriented sockets (doesn't support addresses
/msg_name/)
These should be very easy to implement. If no one takes up the task of
implementing the
missing features than I'll do it of course, you just have to wait a
little while. Of
course any errors present in the code right now will be fixed.
Thanks
Kalman Gergely
----------
components: Library (Lib)
files: srmsg.patch
keywords: patch
messages: 90875
nosy: synapse
severity: normal
status: open
title: socket sendmsg(), recvmsg() methods
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file14556/srmsg.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________
From report at bugs.python.org Fri Jul 24 12:48:01 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 24 Jul 2009 10:48:01 +0000
Subject: [New-bugs-announce] [issue6561] Regex '\d' should not match unicode
category 'No'.
In-Reply-To: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
Message-ID: <1248432481.83.0.138486397936.issue6561@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
In Python 3, or in Python 2 with the re.UNICODE flag, it appears that
the regex r'\d' matches all unicode characters with category either 'Nd'
(Number, Decimal Digit) or 'No' (Number, Other), but not characters in
category 'Nl' (Number, Letter):
Python 3.2a0 (py3k:74188, Jul 23 2009, 16:01:29)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> import unicodedata
>>> x = '\u2781'
>>> unicodedata.category(x)
'No'
>>> unicodedata.name(x)
'DINGBAT CIRCLED SANS-SERIF DIGIT TWO'
>>> re.match(r'\d', '\u2781')
<_sre.SRE_Match object at 0x3d5d08>
I believe (but am not 100% sure) that r'\d' should only match characters
in category 'Nd'. To back up this belief:
(1) int and float currently accept characters in category 'Nd' but not
'No'; it would seem useful for '\d' to match those characters that are
accepted by int, so that e.g., something matched with '\d+' could be
directly passed to int. (This came up in a #python-dev discussion
about whether the Decimal type should accept other unicode digits;
that's a separate issue, though.)
(2) In Perl 5.10 (and possibly some earlier versions too), '\d' matches
only characters in category 'Nd'
(3) Unicode Technical Standard #18 ("Unicode Regular Expressions") at
http://unicode.org/unicode/reports/tr18/ recommends that '\d' should
correspond to \p{gc=Decimal_Number}
Marc-Andr?, do you have any opinion on this?
It's probably slightly dangerous to change this in 2.6 or 3.1; I'm
proposing that '\d' should be modified to accept only characters of
category 'Nd' in 2.7 and 3.2.
(Thanks Ezio Melotti for finding all the references above and doing Perl
testing!)
----------
components: Extension Modules
messages: 90878
nosy: ezio.melotti, lemburg, marketdickinson
severity: normal
stage: test needed
status: open
title: Regex '\d' should not match unicode category 'No'.
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6561>
_______________________________________
From report at bugs.python.org Fri Jul 24 13:26:35 2009
From: report at bugs.python.org (David Roberts)
Date: Fri, 24 Jul 2009 11:26:35 +0000
Subject: [New-bugs-announce] [issue6562] OverflowError in RLock.acquire()
In-Reply-To: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
Message-ID: <1248434795.41.0.567943786679.issue6562@psf.upfronthosting.co.za>
New submission from David Roberts <d at vidr.cc>:
I'm getting the following error on Windows in an application I've
written (the error does not occur on Linux):
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python26\lib\threading.py", line 525, in __bootstrap_inner
self.run()
File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tileprovider.py", line 97, in run
self.__tilecache[tile_id] = Tile(tile)
File "C:\Documents and Settings\David\My
Documents\pyzui\pyzui\tilecache.py", line 165, in __setitem__
with self.__lock:
File "C:\Python26\lib\threading.py", line 115, in acquire
me = current_thread()
File "C:\Python26\lib\threading.py", line 803, in currentThread
return _active[_get_ident()]
OverflowError: can't convert negative value to unsigned long
Where __lock is an RLock object.
The odd thing is that it only affects a single class (which is derived
from the TileProvider class in tileprovider.py, which in turn is derived
from threading.Thread). This led me to believe there was an error in my
code, but I asked on the mailing list and was told that it is likely a
bug in the threading module.
The Python version is 2.6.2.
----------
components: Library (Lib), Windows
messages: 90879
nosy: davidar
severity: normal
status: open
title: OverflowError in RLock.acquire()
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6562>
_______________________________________
From report at bugs.python.org Fri Jul 24 20:11:55 2009
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jul 2009 18:11:55 +0000
Subject: [New-bugs-announce] [issue6563] inserting None into sys.modules
does not raise ImportError with importlib
In-Reply-To: <1248459115.79.0.0648644877351.issue6563@psf.upfronthosting.co.za>
Message-ID: <1248459115.79.0.0648644877351.issue6563@psf.upfronthosting.co.za>
New submission from Brett Cannon <brett at python.org>:
When you insert None into sys.modules, the built-in import raises an
ImportError, but importlib does not.
See http://mail.python.org/pipermail/python-dev/2009-July/090780.html for
the discussion that brought this up.
----------
assignee: brett.cannon
components: Library (Lib)
messages: 90889
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: inserting None into sys.modules does not raise ImportError with importlib
type: behavior
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6563>
_______________________________________
From report at bugs.python.org Fri Jul 24 20:24:22 2009
From: report at bugs.python.org (Gaelen Marsden)
Date: Fri, 24 Jul 2009 18:24:22 +0000
Subject: [New-bugs-announce] [issue6564] Error in Sec. 8.4 of Tutorial
In-Reply-To: <1248459862.63.0.495728002028.issue6564@psf.upfronthosting.co.za>
Message-ID: <1248459862.63.0.495728002028.issue6564@psf.upfronthosting.co.za>
New submission from Gaelen Marsden <gaelen.marsden at gmail.com>:
In Section 8.4 of the Tutorial, "Raising Exceptions", the text following
the first example states "Alternatively, the above could be written as
raise NameError('HiThere')." Perhaps I am being dense, but I can see no
difference between the two.
----------
assignee: georg.brandl
components: Documentation
messages: 90890
nosy: georg.brandl, gmarsden
severity: normal
status: open
title: Error in Sec. 8.4 of Tutorial
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6564>
_______________________________________
From report at bugs.python.org Fri Jul 24 21:46:53 2009
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 24 Jul 2009 19:46:53 +0000
Subject: [New-bugs-announce] [issue6565] improper use of __setitem__ in
ElementTree for Python 3.1
In-Reply-To: <1248464813.63.0.470228683416.issue6565@psf.upfronthosting.co.za>
Message-ID: <1248464813.63.0.470228683416.issue6565@psf.upfronthosting.co.za>
New submission from Andre Roberge <andre.roberge at gmail.com>:
I have a function to replace the content of an ElementTree Element by
that of another one which works using Python 2 but not with Python 3.
I get an assertion error.
It was suggested on the Python list that the problem is that in Python 3
slice assignments are done with __setitem__ rather than __setslice__ but
ElementTree has not been adapted to that -- hence the title given to
this bug.
The function that I use to demonstrate this (with a workaround solution)
is as follows:
def replace_element(elem, replacement):
'''replace the content of an ElementTree Element by that of
another
one.
'''
elem.clear()
elem.text = replacement.text
elem.tail = replacement.tail
elem.tag = replacement.tag
elem.attrib = replacement.attrib
try:
elem[:] = replacement[:] # works with Python 2.5 but not 3.1
except AssertionError:
del elem[:]
for child in replacement:
elem.append(child)
I have included a small test file which demonstrate the behaviour.
----------
components: Library (Lib)
files: test.py
messages: 90891
nosy: aroberge
severity: normal
status: open
title: improper use of __setitem__ in ElementTree for Python 3.1
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14560/test.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6565>
_______________________________________
From report at bugs.python.org Fri Jul 24 23:07:58 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 24 Jul 2009 21:07:58 +0000
Subject: [New-bugs-announce] [issue6566] json.dumps converts None to "null"
(not null)
In-Reply-To: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
Message-ID: <1248469678.72.0.793111928959.issue6566@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
In [2]: json.dumps({'a': 1, 'b': {'c': 3, None: 5}})
Out[2]: '{"a": 1, "b": {"c": 3, "null": 5}}'
In [3]: j = json.dumps({'a': 1, 'b': {'c': 3, None: 5}})
In [4]: json.loads(j)
Out[4]: {u'a': 1, u'b': {u'c': 3, u'null': 5}}
I was surprised to note that None was converted to "null" instead of
null. This happens only in dicts and not, for example, lists:
In [5]: json.dumps([None, 1, "a"])
Out[5]: '[null, 1, "a"]'
----------
components: Library (Lib)
messages: 90896
nosy: srid
severity: normal
status: open
title: json.dumps converts None to "null" (not null)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6566>
_______________________________________
From report at bugs.python.org Sat Jul 25 00:05:36 2009
From: report at bugs.python.org (Lucas Prado Melo)
Date: Fri, 24 Jul 2009 22:05:36 +0000
Subject: [New-bugs-announce] [issue6567] Isn't inf almost equal to inf?
In-Reply-To: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
Message-ID: <1248473136.17.0.947327850034.issue6567@psf.upfronthosting.co.za>
New submission from Lucas Prado Melo <lucaspradomelo at gmail.com>:
When we use TestCase.assertAlmostEqual to compare two float('inf')
objects, the result is that float('inf') is not almost equal to
float('inf').
I believe this is a bug. I tested against r74195 of Python 3.2 and
against Python 2.6.2.
----------
messages: 90902
nosy: lucaspmelo
severity: normal
status: open
title: Isn't inf almost equal to inf?
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6567>
_______________________________________
From report at bugs.python.org Sat Jul 25 01:16:07 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 24 Jul 2009 23:16:07 +0000
Subject: [New-bugs-announce] [issue6568] unittest test discovery improvements
In-Reply-To: <1248477367.35.0.856395228547.issue6568@psf.upfronthosting.co.za>
Message-ID: <1248477367.35.0.856395228547.issue6568@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Issue to track improvements in the standalone discover.py that I need to
port to the test discovery in unittest.
* Failure to import a module does not halt discovery
* Will not attempt to import test files whose names are not valid Python
identifiers, even if they match the pattern
----------
assignee: michael.foord
messages: 90904
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: unittest test discovery improvements
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6568>
_______________________________________
From report at bugs.python.org Sat Jul 25 02:47:56 2009
From: report at bugs.python.org (Kouki Hashimoto)
Date: Sat, 25 Jul 2009 00:47:56 +0000
Subject: [New-bugs-announce] [issue6569] unittest document bug
(random.shuffle sequence)
In-Reply-To: <1248482876.59.0.638608810535.issue6569@psf.upfronthosting.co.za>
Message-ID: <1248482876.59.0.638608810535.issue6569@psf.upfronthosting.co.za>
New submission from Kouki Hashimoto <hsmtkk at gmail.com>:
Hello.
I found a bug in unittest sample code.
http://docs.python.org/dev/py3k/library/unittest.html#unittest-minimal-example
(naming this code as test_sample.py)
I got this error.
$ python3.2 test_sample.py
..E
======================================================================
ERROR: test_shuffle (__main__.TestSequenceFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_sample.py", line 11, in test_shuffle
random.shuffle(self.seq)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/random.py",
line 270, in shuffle
x[i], x[j] = x[j], x[i]
TypeError: 'range' object does not support item assignment
----------------------------------------------------------------------
Ran 3 tests in 0.004s
I think this code should be fixed with attached patch.
Regards.
----------
assignee: georg.brandl
components: Documentation
files: unittest.rst.patch
keywords: patch
messages: 90907
nosy: georg.brandl, hsmtkk
severity: normal
status: open
title: unittest document bug (random.shuffle sequence)
versions: Python 3.2
Added file: http://bugs.python.org/file14563/unittest.rst.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6569>
_______________________________________
From report at bugs.python.org Sat Jul 25 10:35:40 2009
From: report at bugs.python.org (Mark du Preez)
Date: Sat, 25 Jul 2009 08:35:40 +0000
Subject: [New-bugs-announce] [issue6570] Documentation Clarity
In-Reply-To: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
Message-ID: <1248510940.46.0.953855607394.issue6570@psf.upfronthosting.co.za>
New submission from Mark du Preez <drunkard at thepub.co.za>:
Hi
In section 4.7.2 of the tutorial documentation, we suddenly find the
following paragraph:
"In general, an argument list must have any positional arguments
followed by any keyword arguments, where the keywords must be chosen
from the formal parameter names. It?s not important whether a formal
parameter has a default value or not. No argument may receive a value
more than once ? formal parameter names corresponding to positional
arguments cannot be used as keywords in the same calls. Here?s an
example that fails due to this restriction:"
To a beginner who is reading a tutorial to learn how to use this
language for the first time, it is completely overwhelming. What is a
"positional argument" vs a "keyword argument" and what is a "formal
parameter name"?
None of these things have been explained up until this point and an
understanding of their meaning is required to make sense of this paragraph.
Please consider revising this section.
Thank you.
Mark
----------
assignee: georg.brandl
components: Documentation
messages: 90910
nosy: StMark, georg.brandl
severity: normal
status: open
title: Documentation Clarity
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6570>
_______________________________________
From report at bugs.python.org Sat Jul 25 14:15:24 2009
From: report at bugs.python.org (Colin J. Williams)
Date: Sat, 25 Jul 2009 12:15:24 +0000
Subject: [New-bugs-announce] [issue6571] Help index
In-Reply-To: <1248524124.94.0.366651342464.issue6571@psf.upfronthosting.co.za>
Message-ID: <1248524124.94.0.366651342464.issue6571@psf.upfronthosting.co.za>
New submission from Colin J. Williams <cjw at ncf.ca>:
Shift operators. It would be good if "<<" and ">>" could be included
in the index.
Incidentally, the usage seems counter-intuitive.
One would expect ">>" to be a shift to the right and
"<<" to be a shift to the left.
----------
assignee: georg.brandl
components: Documentation
messages: 90917
nosy: cjw, georg.brandl
severity: normal
status: open
title: Help index
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6571>
_______________________________________
From report at bugs.python.org Sat Jul 25 17:16:29 2009
From: report at bugs.python.org (Manas)
Date: Sat, 25 Jul 2009 15:16:29 +0000
Subject: [New-bugs-announce] [issue6572] Manas Thapliyal wants to chat
In-Reply-To: <f7e1212e0907250816h38602468p@mail.gmail.com>
Message-ID: <f7e1212e0907250816h38602468p@mail.gmail.com>
New submission from Manas <gravitywarrior1 at gmail.com>:
-----------------------------------------------------------------------
Manas Thapliyal wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-6dec705464-1ad2ad81d2-c136c6a2ca2ffe8f
You'll need to click this link to be able to chat with Manas Thapliyal.
To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Manas Thapliyal, visit:
http://mail.google.com/mail/a-6dec705464-1ad2ad81d2-c136c6a2ca2ffe8f
Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
that are relevant to the content of your messages
All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:
http://www.google.com/talk/
Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
client
Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!
Thanks,
The Google Team
To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html
(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
----------
messages: 90924
nosy: gravitywarrior1
severity: normal
status: open
title: Manas Thapliyal wants to chat
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6572>
_______________________________________
From report at bugs.python.org Sat Jul 25 17:24:21 2009
From: report at bugs.python.org (Shawn Smout)
Date: Sat, 25 Jul 2009 15:24:21 +0000
Subject: [New-bugs-announce] [issue6573] set union method ignores arguments
appearing after the original set
In-Reply-To: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>
Message-ID: <1248535461.31.0.573143089601.issue6573@psf.upfronthosting.co.za>
New submission from Shawn Smout <silroquen at yahoo.com>:
When calling the union method of a set with several arguments, if one of
those sets is the original set, all arguments appearing after it are
ignored. For example:
x = set()
x.union(set([1]), x, set([2]))
evaluates to set([1]), not set([1, 2]) as expected. As another example,
since all empty frozensets are the same,
frozenset().union(frozenset([1]), frozenset(), frozenset([2]))
also evaluates to just frozenset([1]).
The fix is trivial, so I'm attaching a patch.
----------
files: set_union.patch
keywords: patch
messages: 90925
nosy: ssmout
severity: normal
status: open
title: set union method ignores arguments appearing after the original set
Added file: http://bugs.python.org/file14565/set_union.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6573>
_______________________________________
From report at bugs.python.org Sun Jul 26 11:34:13 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 26 Jul 2009 09:34:13 +0000
Subject: [New-bugs-announce] [issue6574] List the __future__ features in a
table
In-Reply-To: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
Message-ID: <1248600853.49.0.371600667943.issue6574@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
The documentation about the __future__ features [1] only lists the
features available for that particular version, without specifying when
they were added and their effects.
It would be nice to have a table with |feature|version added|effect|.
A better place for this table could also be the page of the __future__
module [2].
[1]: http://docs.python.org/reference/simple_stmts.html#future
[2]: http://docs.python.org/library/__future__.html
----------
assignee: ezio.melotti
components: Documentation
keywords: easy
messages: 90935
nosy: ezio.melotti
priority: low
severity: normal
stage: needs patch
status: open
title: List the __future__ features in a table
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6574>
_______________________________________
From report at bugs.python.org Sun Jul 26 14:21:53 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 12:21:53 +0000
Subject: [New-bugs-announce] [issue6575] Can't download docs
In-Reply-To: <1248610913.94.0.0307799249969.issue6575@psf.upfronthosting.co.za>
Message-ID: <1248610913.94.0.0307799249969.issue6575@psf.upfronthosting.co.za>
New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:
http://docs.python.org/3.1/download.html (available both with 'Download
these documents' link @docs and 'Download Current Python 3.1
Documentation' link @http://www.python.org/doc/) doesn't contain links
to packed docs, but text for dev-releases:
"We don't package the documentation for development releases for
download. Downloads will be available for the final release."
----------
assignee: georg.brandl
components: Documentation
messages: 90937
nosy: georg.brandl, zuo
severity: normal
status: open
title: Can't download docs
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6575>
_______________________________________
From report at bugs.python.org Sun Jul 26 15:13:11 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:13:11 +0000
Subject: [New-bugs-announce] [issue6576] re docs: wrong link targets
In-Reply-To: <1248613991.98.0.0140220759492.issue6576@psf.upfronthosting.co.za>
Message-ID: <1248613991.98.0.0140220759492.issue6576@psf.upfronthosting.co.za>
New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:
Some of links in re docs should lead to RegexObject.match()|
RegexObject.search() method but lead to re.match()|re.search() module
function.
These are the places in 2.6 docs (in 2.7-3.2 versions' you'll find the
bug in analogous places):
http://docs.python.org/library/re.html#re.compile
http://docs.python.org/library/re.html#re.RegexObject.match
http://docs.python.org/library/re.html#re.RegexObject.search
http://docs.python.org/library/re.html#re.MatchObject.pos
http://docs.python.org/library/re.html#re.MatchObject.endpos
http://docs.python.org/library/re.html#re.MatchObject.re
http://docs.python.org/library/re.html#re.MatchObject.string (<- here
maybe both possibilities should be noted, which would mean changing not
only link targets but also the content)
----------
assignee: georg.brandl
components: Documentation
messages: 90941
nosy: georg.brandl, zuo
severity: normal
status: open
title: re docs: wrong link targets
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6576>
_______________________________________
From report at bugs.python.org Sun Jul 26 15:38:30 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:38:30 +0000
Subject: [New-bugs-announce] [issue6577] Links wrongly targeting to builtin
functions' instead of module functions/methods
In-Reply-To: <1248615510.07.0.327416656356.issue6577@psf.upfronthosting.co.za>
Message-ID: <1248615510.07.0.327416656356.issue6577@psf.upfronthosting.co.za>
New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:
The problem can be found in many places in docs -- tipically, where
there is a function/method with name identical to builtin name (or
sometimes to another function/method within the same module -- see:
#6575): links leads to te latter but should lead to the former.
One example -- open():
http://docs.python.org/library/shelve.html?
highlight=open#shelve.DbfilenameShelf
http://docs.python.org/library/shelve.html?highlight=open#example
http://docs.python.org/library/sunau.html?highlight=open#sunau.openfp
http://docs.python.org/library/sunau.html?highlight=open#au-read-objects
http://docs.python.org/library/sunau.html?highlight=open#au-write-
objects
http://docs.python.org/library/wave.html?highlight=open#wave.openfp
http://docs.python.org/library/wave.html?highlight=open#wave-read-
objects
http://docs.python.org/library/wave.html?highlight=open#wave-write-
objects
http://docs.python.org/library/io.html?highlight=open#module-interface
http://docs.python.org/library/io.html?highlight=open#io.open
http://docs.python.org/library/io.html?highlight=open#io.IOBase.readline
It's hard to find all such place by hand; probably it's a job for a
script...
----------
assignee: georg.brandl
components: Documentation
messages: 90943
nosy: georg.brandl, zuo
severity: normal
status: open
title: Links wrongly targeting to builtin functions' instead of module functions/methods
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6577>
_______________________________________
From report at bugs.python.org Sun Jul 26 15:57:09 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 13:57:09 +0000
Subject: [New-bugs-announce] [issue6578] 2 problems with 'Docs for other
versions' section on left HTML docs sidebar
In-Reply-To: <1248616629.63.0.429238805122.issue6578@psf.upfronthosting.co.za>
Message-ID: <1248616629.63.0.429238805122.issue6578@psf.upfronthosting.co.za>
New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:
* In 2.6 the content of that section isn't up to date (3.1 is
descripted as 'in development')
* In 3.0 there is no that section.
----------
messages: 90945
nosy: zuo
severity: normal
status: open
title: 2 problems with 'Docs for other versions' section on left HTML docs sidebar
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6578>
_______________________________________
From report at bugs.python.org Sun Jul 26 16:11:09 2009
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 26 Jul 2009 14:11:09 +0000
Subject: [New-bugs-announce] [issue6579] No update about automatic numbering
of fields in format strings (e.g. 'A {} with {} buttocks')
In-Reply-To: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
Message-ID: <1248617469.33.0.437131453768.issue6579@psf.upfronthosting.co.za>
New submission from Jan Kaliszewski <zuo at chopin.edu.pl>:
As we can read in http://docs.python.org/3.1/whatsnew/3.1.html#other-
language-changes:
----
The fields in format() strings can now be automatically numbered:
>>> 'Sir {} of {}'.format('Gallahad', 'Camelot')
'Sir Gallahad of Camelot'
Formerly, the string would have required numbered fields such as: 'Sir
{0} of {1}'.
(Contributed by Eric Smith; issue 5237.)
----
But it is not mentioned in 3.2's, 3.1's and 2.7's docs about format
string syntax, e.g. in 3.1 docs we have:
http://docs.python.org/3.1/library/string.html#format-string-syntax
[Please note that also grammar for a replacement field should be
updated there ('field_name' should be in '[' ']', but I'm not sure if
it'd be enough)].
----------
assignee: georg.brandl
components: Documentation
messages: 90946
nosy: georg.brandl, zuo
severity: normal
status: open
title: No update about automatic numbering of fields in format strings (e.g. 'A {} with {} buttocks')
versions: Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6579>
_______________________________________
From report at bugs.python.org Sun Jul 26 19:25:03 2009
From: report at bugs.python.org (Michael R Bax)
Date: Sun, 26 Jul 2009 17:25:03 +0000
Subject: [New-bugs-announce] [issue6580] No deprecation warning for list
comprehension leak conflict
In-Reply-To: <1248629103.59.0.528554407036.issue6580@psf.upfronthosting.co.za>
Message-ID: <1248629103.59.0.528554407036.issue6580@psf.upfronthosting.co.za>
New submission from Michael R Bax <mrbax at users.sourceforge.net>:
PEP 289 states that "Python 2.4 and beyond should issue a deprecation
warning if a list comprehension's loop variable has the same name as a
variable used in the immediately surrounding scope". But no warning is
shown when running
for x in [ 0 ]: print [ x for x in [ 1 ] ]
in Python 2.5.2 (at least).
----------
components: Interpreter Core
messages: 90952
nosy: mrbax
severity: normal
status: open
title: No deprecation warning for list comprehension leak conflict
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6580>
_______________________________________
From report at bugs.python.org Sun Jul 26 22:21:36 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 26 Jul 2009 20:21:36 +0000
Subject: [New-bugs-announce] [issue6581] inspect.py sys._getframe patch for
Python 2.6
In-Reply-To: <1248639696.3.0.831428549243.issue6581@psf.upfronthosting.co.za>
Message-ID: <1248639696.3.0.831428549243.issue6581@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Patch for inspect.py so that it will import correctly even if
sys._getframe is unavailable.
Without this patch inspect can't be imported under IronPython 2.6
(breaking basic features like help) when started without Python stack
frame support.
The same fix is required on trunk.
----------
assignee: michael.foord
components: Library (Lib)
files: inspect.patch
keywords: needs review, patch, patch
messages: 90955
nosy: michael.foord
severity: normal
status: open
title: inspect.py sys._getframe patch for Python 2.6
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14571/inspect.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6581>
_______________________________________
From report at bugs.python.org Mon Jul 27 00:30:32 2009
From: report at bugs.python.org (Jack Diederich)
Date: Sun, 26 Jul 2009 22:30:32 +0000
Subject: [New-bugs-announce] [issue6582] test_telnetlib doesn't test
Telnet.write
In-Reply-To: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
Message-ID: <1248647432.95.0.0572688649106.issue6582@psf.upfronthosting.co.za>
New submission from Jack Diederich <jackdied at gmail.com>:
test/test_telnetlib.py has zero tests for the telnetlib.Telnet.write method.
----------
assignee: jackdied
messages: 90963
nosy: jackdied
severity: normal
status: open
title: test_telnetlib doesn't test Telnet.write
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6582>
_______________________________________
From report at bugs.python.org Mon Jul 27 07:21:22 2009
From: report at bugs.python.org (Joe Amenta)
Date: Mon, 27 Jul 2009 05:21:22 +0000
Subject: [New-bugs-announce] [issue6583] 2to3 fails to fix test.test_support
In-Reply-To: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
Message-ID: <1248672082.21.0.412952291584.issue6583@psf.upfronthosting.co.za>
New submission from Joe Amenta <amentajo at msu.edu>:
PEP 3108 states that test.test_support was renamed to test.support as a
part of the Standard Library Reorganization process. However...
2to3 does not refactor (or even warn about) test.test_support. Simply
adding
"test.test_support": "test.support",
into the MAPPING of fix_imports.py would not work, because
fix_imports.py does not accept anything with a dot in it, i.e. "foo.bar".
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3_out.txt
messages: 90975
nosy: joe.amenta
severity: normal
status: open
title: 2to3 fails to fix test.test_support
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14575/2to3_out.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6583>
_______________________________________
From report at bugs.python.org Mon Jul 27 08:10:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 27 Jul 2009 06:10:50 +0000
Subject: [New-bugs-announce] [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Much like zipfile.BadZipfile, we need a base custom exception for the
gzip module. At least, catch gzip-related exceptions and throw a
tarfile.TarError when used *via* tarfile.*.
See the following example (the exception escaped the "try... except
tarfile.TarError: .. " block!):
***
[...]
File "/home/sridharr/as/pypm/src/pypm/common/compression.py", line
199, in _ensure_read_write_access
for tarinfo in tarfileobj.getmembers():
File "/opt/ActivePython-2.6/lib/python2.6/tarfile.py", line 1791, in
getmembers
self._load() # all members, we first have to
File "/opt/ActivePython-2.6/lib/python2.6/tarfile.py", line 2352, in
_load
tarinfo = self.next()
File "/opt/ActivePython-2.6/lib/python2.6/tarfile.py", line 2307, in
next
self.fileobj.seek(self.offset)
File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 382, in seek
self.read(1024)
File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 219, in read
self._read(readsize)
File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 284, in _read
self._read_eof()
File "/opt/ActivePython-2.6/lib/python2.6/gzip.py", line 304, in
_read_eof
hex(self.crc)))
IOError: CRC check failed 0x115929f0 != 0x9f074a38L
----------
components: Library (Lib)
messages: 90976
nosy: srid
severity: normal
status: open
title: gzip module has no custom exception
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________
From report at bugs.python.org Mon Jul 27 11:39:19 2009
From: report at bugs.python.org (Antonio Cavallo)
Date: Mon, 27 Jul 2009 09:39:19 +0000
Subject: [New-bugs-announce] [issue6585] configure.in forces specific
autoconf version
In-Reply-To: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>
Message-ID: <1248687559.88.0.690836235505.issue6585@psf.upfronthosting.co.za>
New submission from Antonio Cavallo <a.cavallo at cavallinux.eu>:
Hi,
I've seen the code change in /python/trunk/configure.in (rev. 74072):
it enforces a specific autoconfig version (2.61) in order to build
python.
Unfortunately OpenSuSE 11.1 (mainstream at time of writing) has an
updated version of autoconf 2.63 (and I think is true for Mandriva as
well).
Wouldn't be better to force the 2.61 being the minimal version for
autoconf allowing more up-to-date versions to be used?
You can have a look into http://pyvm.sourceforge.net/ where continuous
build of the python interpreter are stored for further references.
----------
components: Build
messages: 90980
nosy: alexandre.vassalotti, cavallo71
severity: normal
status: open
title: configure.in forces specific autoconf version
type: compile error
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6585>
_______________________________________
From report at bugs.python.org Mon Jul 27 17:25:02 2009
From: report at bugs.python.org (Chris Liechti)
Date: Mon, 27 Jul 2009 15:25:02 +0000
Subject: [New-bugs-announce] [issue6586] Documentation of os.write and
os.read are inaccurate.
In-Reply-To: <1248708302.5.0.774291437722.issue6586@psf.upfronthosting.co.za>
Message-ID: <1248708302.5.0.774291437722.issue6586@psf.upfronthosting.co.za>
New submission from Chris Liechti <cliechti at users.sourceforge.net>:
Documentation of os.write and os.read are inaccurate, it states that the
methods work with 'str' (or strings), which is wrong.
- os.write expects an instance of bytes or buffer
- os.read returns an instance of bytes
The implementation is OK, it fits well with the new io library but the
docs don't describe the implementation.
----------
assignee: georg.brandl
components: Documentation
messages: 90983
nosy: cliechti, georg.brandl
severity: normal
status: open
title: Documentation of os.write and os.read are inaccurate.
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6586>
_______________________________________
From report at bugs.python.org Tue Jul 28 02:32:12 2009
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 28 Jul 2009 00:32:12 +0000
Subject: [New-bugs-announce] [issue6587] interrupts during long writes cause
connection corruption with SSL module
In-Reply-To: <1248741132.11.0.651534522713.issue6587@psf.upfronthosting.co.za>
Message-ID: <1248741132.11.0.651534522713.issue6587@psf.upfronthosting.co.za>
New submission from Bill Janssen <bill.janssen at gmail.com>:
The behavior when a write or send is interrupted is suboptimal. If the
write buffer moves before a retry is attempted in response to
SSL_ERROR_WANT_OUTPUT, OpenSSL rejects the retry attempt. See
http://www.mail-archive.com/openssl-users at openssl.org/msg07806.html.
Looks like a simple fix.
----------
assignee: janssen
messages: 90999
nosy: janssen
priority: high
severity: normal
stage: needs patch
status: open
title: interrupts during long writes cause connection corruption with SSL module
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6587>
_______________________________________
From report at bugs.python.org Tue Jul 28 04:07:14 2009
From: report at bugs.python.org (Jon Debonis)
Date: Tue, 28 Jul 2009 02:07:14 +0000
Subject: [New-bugs-announce] [issue6588] insert cookies into cookie jar -
cookielib.py
In-Reply-To: <1248746834.41.0.511434731236.issue6588@psf.upfronthosting.co.za>
Message-ID: <1248746834.41.0.511434731236.issue6588@psf.upfronthosting.co.za>
New submission from Jon Debonis <jon at tooln.com>:
Added ability to insert cookies into cookie jar.
Fixed problem where some domain names are prepended with '.' and others
were not.
Fixed problem with _LWPCookieJar.py to handle case where version = None
----
import urllib2, urllib, time
import cookielib
req_url = 'http://google.com'
## OPEN COOKIE JAR - Optional
cj = cookielib.CookieJar()
cookie_handler = urllib2.HTTPCookieProcessor(cj)
opener = urllib2.build_opener(cookie_handler)
urllib2.install_opener(opener)
req = urllib2.Request(url=req_url)
cj.add_cookie(req, 'cname2', 'cval2',
{'expires': int(time.time()) + 3600,})
cj.add_cookie(req, 'cname3', 'cval3')
print "-" * 45
print "Cookies before first request is sent:"
for index, cookie in enumerate(cj):
print index, ' : ', cookie
res = urllib2.urlopen(req)
# Google will redirect, and clear the additional cookies
print "-" * 45
print "Cookies after first request is sent:"
print "(google cleared extra cookies)"
for index, cookie in enumerate(cj):
print index, ' : ', cookie
---
----------
components: Library (Lib)
files: cookie_update.diff
keywords: patch
messages: 91000
nosy: jondebonis
severity: normal
status: open
title: insert cookies into cookie jar - cookielib.py
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file14582/cookie_update.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6588>
_______________________________________
From report at bugs.python.org Tue Jul 28 05:59:58 2009
From: report at bugs.python.org (Casey McGinty)
Date: Tue, 28 Jul 2009 03:59:58 +0000
Subject: [New-bugs-announce] [issue6589] smtpd.SMTPServer can cause
asyncore.loop to enter infinite event loop
In-Reply-To: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
Message-ID: <1248753598.39.0.190804723361.issue6589@psf.upfronthosting.co.za>
New submission from Casey McGinty <casey.mcginty at gmail.com>:
When subclass of smtpd.SMTPServer, it is possible the get asyncore.loop
to enter an infinite loop where the following output is shown:
.....
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
warning: unhandled write event
warning: unhandled read event
....
To reproduce:
1) Init SMTPServer class instance inside of Thread class and call
asyncore.loop()
2) Init second SMTPServer class instance from a second Thread class,
binding to the same address and port. The SMTPServer instance will raise
an exception that socket cannot bind to the port in use. The socket
exception must be caught at some level, and the program execution
allowed to continue.
3) First SMTPServer thread will enter infinite event loop.
Analysis:
When the exception is raised in the second SMTPServer instance, the new
instance has already registered itself with the asyncore library (ex:
'asyncore.dispatcher.__init__(self)'). There is no code in the
SMTPServere.__init__ method that catches the exception raised, caused by
the failed bind attempt. After the exception is caught, the first thread
continues to run, but asyncore is in an invalid state because it still
has the registration of the second SMTPServer instance that never completed.
Workaround and Proposed Fix:
A viable workaround seems to be catching the raised exception in
__init__ method of the SMTPServer subclass, and call self.close() before
re-raising the exception:
class MySmtpServer( smtpd.SMTPServer, object ):
def __init__( self, **kwargs ):
try:
super( _SmtpSink, self).__init__(**kwargs)
except Exception as e:
self.close() # cleanup asyncore after failure
raise
For a long term fix, I would recommend performing the
asyncore.dispatcher.close() method call in the SMTPServer.__init__() method.
----------
components: Library (Lib)
messages: 91002
nosy: cmcginty
severity: normal
status: open
title: smtpd.SMTPServer can cause asyncore.loop to enter infinite event loop
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6589>
_______________________________________
From report at bugs.python.org Tue Jul 28 11:43:01 2009
From: report at bugs.python.org (Hakan)
Date: Tue, 28 Jul 2009 09:43:01 +0000
Subject: [New-bugs-announce] [issue6590] Py3K can't set the browser's
character encoding! (CGI)
In-Reply-To: <1248774181.34.0.157512876081.issue6590@psf.upfronthosting.co.za>
Message-ID: <1248774181.34.0.157512876081.issue6590@psf.upfronthosting.co.za>
New submission from Hakan <physic.tr at gmail.com>:
Hi,
I'm new to web programming with Python.
In Python2k, the special "# -*- coding: cp1254 -*-" code sets the
character encoding. It works in the internet browsers too and sets the
browser's character encoding. That was really good. But in Py3k, that
special comment doesn't work. Usually, the encoding is UTF-8 in my
browser. That time, non-ascii Turkish characters seems strange symbols.
The locale.setlocale method doesn't work too. The users must manualy set
the encoding from UTF-8 to Turkish(Windows-1254) or Turkish(ISO-8859-9).
Is there anyway to set browser's encoding with Python 3.1?
I use IIS7 and Windows 7 x64.
BTW, the ASP don't identify Python. But I can use .py files. So, I did
these thing in CGI/.py
----------
components: Unicode
messages: 91003
nosy: [PhysiC]
severity: normal
status: open
title: Py3K can't set the browser's character encoding! (CGI)
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6590>
_______________________________________
From report at bugs.python.org Tue Jul 28 13:04:47 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Tue, 28 Jul 2009 11:04:47 +0000
Subject: [New-bugs-announce] [issue6591] add reference to fcntl.ioctl in the
socket module
In-Reply-To: <1248779087.11.0.343607433403.issue6591@psf.upfronthosting.co.za>
Message-ID: <1248779087.11.0.343607433403.issue6591@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
socket.ioctl says it is Windows specific, and people may think there
is no way to use ioctl with sockets in non-Windows platforms (see
http://groups.google.com/group/comp.lang.python/browse_thread/
thread/246f4522ad215d74 )
This doc patch adds a reference to the fcntl.fcntl and fcntl.ioctl
functions so people is aware of them.
----------
assignee: georg.brandl
components: Documentation
files: socket.diff
keywords: patch
messages: 91004
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: add reference to fcntl.ioctl in the socket module
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file14583/socket.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6591>
_______________________________________
From report at bugs.python.org Tue Jul 28 14:12:57 2009
From: report at bugs.python.org (tanvalley)
Date: Tue, 28 Jul 2009 12:12:57 +0000
Subject: [New-bugs-announce] [issue6592] otparse: processing variable number
of short option arguments
Message-ID: <1248783177.09.0.433019746368.issue6592@psf.upfronthosting.co.za>
Changes by tanvalley <tanvalley at hotmail.com>:
----------
components: Library (Lib)
files: optparse-feature
nosy: tanvalley
severity: normal
status: open
title: otparse: processing variable number of short option arguments
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file14584/optparse-feature
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6592>
_______________________________________
From report at bugs.python.org Tue Jul 28 19:13:44 2009
From: report at bugs.python.org (Egon Frerich)
Date: Tue, 28 Jul 2009 17:13:44 +0000
Subject: [New-bugs-announce] [issue6593] Documentation: gettext install link
In-Reply-To: <1248801224.0.0.797200646429.issue6593@psf.upfronthosting.co.za>
Message-ID: <1248801224.0.0.797200646429.issue6593@psf.upfronthosting.co.za>
New submission from Egon Frerich <e.frerich at nord-com.net>:
The description of gettext.install in 23.1.2 (Class-based API) contains
two links to install() which should go to this function in "The
NullTranslations class" 23.1.2.1 but they don't.
----------
assignee: georg.brandl
components: Documentation
messages: 91010
nosy: efrerich, georg.brandl
severity: normal
status: open
title: Documentation: gettext install link
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6593>
_______________________________________
From report at bugs.python.org Tue Jul 28 22:19:21 2009
From: report at bugs.python.org (Shawn)
Date: Tue, 28 Jul 2009 20:19:21 +0000
Subject: [New-bugs-announce] [issue6594] json C serializer performance tied
to structure depth on some systems
In-Reply-To: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
Message-ID: <1248812361.89.0.626576705519.issue6594@psf.upfronthosting.co.za>
New submission from Shawn <swalker at opensolaris.org>:
The json serializer's performance (when using the C speedups) appears to
be tied to the depth of the structure being serialized on some systems.
In particular, dict structure that are more than a few levels deep,
especially when they content mixed values (lists, strings, and other
dicts) causes severe serialization penalties (in the neighborhood of an
extra 20-30 seconds) on some systems.
On SPARC systems, this is very likely because of the recursive call
structure that the C speedups serializer uses which doesn't work well
with SPARC due to register windows.
On x86 systems, recursive call structures are cheap, so this doesn't
appear to be an issue there.
SPARC systems with higher amounts of memory bandwidth don't suffer as
badly from this (such as Niagra T1000, T2000, etc. systems), but older
UltraSparc systems are especially prone to performance issues.
----------
components: Library (Lib)
messages: 91015
nosy: swalker
severity: normal
status: open
title: json C serializer performance tied to structure depth on some systems
type: performance
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6594>
_______________________________________
From report at bugs.python.org Wed Jul 29 10:39:55 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Jul 2009 08:39:55 +0000
Subject: [New-bugs-announce] [issue6595] Make Decimal constructor accept all
unicode decimal digits in input.
In-Reply-To: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
Message-ID: <1248856795.44.0.0182588213317.issue6595@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Ezio Melotti asked (on #python-dev) why the Decimal constructor doesn't
accept decimal digits other than 0-9. As far as I can tell there's no
good reason for it not to. Moreover, the standard on which the decimal
module is based says[1]:
"""It is recommended that implementations also provide additional number
formatting routines (including some which are locale-dependent), and if
available should accept non-European decimal digits in strings."""
All other builtin or standard library numeric types already accept such
digits:
Python 3.2a0 (py3k:74247, Jul 29 2009, 09:28:12)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> from decimal import Decimal
>>> x = '\uff11\uff10\uff15\uff18\uff15'
>>> x
'?????'
>>> int(x)
10585
>>> float(x)
10585.0
>>> complex(x)
(10585+0j)
>>> Fraction(x)
Fraction(10585, 1)
>>> Decimal(x)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 548, in
__new__
"Invalid literal for Decimal: %r" % value)
File "/Users/dickinsm/python/svn/py3k/Lib/decimal.py", line 3816, in
_raise_error
raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: '?????'
I propose adding support for this in Python 3.2 and (possibly) 2.7. The
change would be for input only: no record of the original form of the
digits would be kept by the Decimal object itself, so that e.g.,
str(Decimal('?????')) would still be '10585'.
[1] See http://speleotrove.com/decimal/daconvs.html
----------
assignee: marketdickinson
components: Library (Lib)
messages: 91030
nosy: ezio.melotti, marketdickinson
severity: normal
status: open
title: Make Decimal constructor accept all unicode decimal digits in input.
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6595>
_______________________________________
From report at bugs.python.org Wed Jul 29 12:35:58 2009
From: report at bugs.python.org (Anton)
Date: Wed, 29 Jul 2009 10:35:58 +0000
Subject: [New-bugs-announce] [issue6596] urllib2 bug on CentOS
In-Reply-To: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
Message-ID: <1248863758.9.0.379989191773.issue6596@psf.upfronthosting.co.za>
New submission from Anton <rk3dov at gmail.com>:
This code gives HTTP Error 500 on CentOS:
---------------------------------------------
import urllib2
url = 'http://wm.exchanger.ru/asp/XMLWMList.asp?exchtype=1'
t = urllib2.urlopen(url).read()
---------------------------------------------
tcpdump:
---------------------------------------------
...
GET /asp/XMLWMList.asp?exchtype=1?3d2ebf80 HTTP/1.1
Accept-Encoding: identity
Host: wm.exchanger.ru
Connection: close
User-Agent: Python-urllib/2.6
...
---------------------------------------------
"?3d2ebf80" appended to request
% uname -a
Linux xxx.xxx 2.6.18-028stab062.3-ent #1 SMP Thu Mar 26 15:12:05 MSK
2009 i686 i686 i386 GNU/Linux
The same problem with python 2.4.3. On other systems this code works
nice.
----------
components: Extension Modules
messages: 91034
nosy: rk3dov
severity: normal
status: open
title: urllib2 bug on CentOS
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6596>
_______________________________________
From report at bugs.python.org Thu Jul 30 01:21:39 2009
From: report at bugs.python.org (Matthew Russell)
Date: Wed, 29 Jul 2009 23:21:39 +0000
Subject: [New-bugs-announce] [issue6597] Depricate iterable.next in Python >
2.6.x when called with -3 option
In-Reply-To: <1248909699.69.0.0901747009049.issue6597@psf.upfronthosting.co.za>
Message-ID: <1248909699.69.0.0901747009049.issue6597@psf.upfronthosting.co.za>
New submission from Matthew Russell <matt.horizon5 at gmail.com>:
Not sure if this should be (tentative) feature request or behavior...
It might help new comers and those preparing to port to Python 3.
----------
assignee: georg.brandl
components: 2to3 (2.x to 3.0 conversion tool), Documentation, Interpreter Core
messages: 91072
nosy: georg.brandl, mattrussell
severity: normal
status: open
title: Depricate iterable.next in Python > 2.6.x when called with -3 option
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6597>
_______________________________________
From report at bugs.python.org Thu Jul 30 02:32:16 2009
From: report at bugs.python.org (Michael Hudson)
Date: Thu, 30 Jul 2009 00:32:16 +0000
Subject: [New-bugs-announce] [issue6598] calling email.utils.make_msgid
frequently has a non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
New submission from Michael Hudson <mwh at users.sourceforge.net>:
If you call email.utils.make_msgid a number of times within the same
second, the uniqueness of the results depends on random.randint(100000)
returning different values each time.
A little mathematics proves that you don't have to call make_msgid
*that* often to get the same message id twice: if you call it 'n' times,
the probability of a collision is approximately "1 -
math.exp(-n*(n-1)/200000.0)", and for n == 100, that's about 5%. For n
== 1000, it's over 99%.
These numbers are born out by experiment:
>>> def collisions(n):
... msgids = [make_msgid() for i in range(n)]
... return len(msgids) - len(set(msgids))
...
>>> sum((collisions(100)>0) for i in range(1000))
49
>>> sum((collisions(1000)>0) for i in range(1000))
991
I think probably having a counter in addition to the randomness would be
a good fix for the problem, though I guess then you have to worry about
thread safety.
----------
components: Library (Lib)
messages: 91073
nosy: mwh
severity: normal
status: open
title: calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids
type: behavior
versions: 3rd party, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________
From report at bugs.python.org Thu Jul 30 03:14:15 2009
From: report at bugs.python.org (James Abbatiello)
Date: Thu, 30 Jul 2009 01:14:15 +0000
Subject: [New-bugs-announce] [issue6599] 2to3 test_print_function_option
fails on Windows
In-Reply-To: <1248916455.36.0.400701947417.issue6599@psf.upfronthosting.co.za>
Message-ID: <1248916455.36.0.400701947417.issue6599@psf.upfronthosting.co.za>
New submission from James Abbatiello <abbeyj at gmail.com>:
test_print_function_option is failing on Windows. Patch attached.
Output of failure:
C:>python test.py
test_all_project_files (lib2to3.tests.test_all_fixers.Test_all) ...
<snip>\2to3\lib2to3\refactor.py:194: DeprecationWarning: the
'print_function' option is deprecated
DeprecationWarning)
<snip>
======================================================================
FAIL: test_print_function_option
(lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
File "<snip>\2to3\lib2to3\tests\test_refactor.py", line 51, in
test_print_function_option
self.assertEqual(len(w), 1)
AssertionError: 0 != 1
----------------------------------------------------------------------
On my system test_all_fixers.py comes before test_refactor.py in the
output of os.listdir(). The warning gets fired by test_all_fixers and
then won't be retriggered in test_refactor. Since the option doesn't do
anything anymore I've just removed its use.
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: print_function_option.patch
keywords: patch
messages: 91075
nosy: abbeyj, benjamin.peterson
severity: normal
status: open
title: 2to3 test_print_function_option fails on Windows
Added file: http://bugs.python.org/file14603/print_function_option.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6599>
_______________________________________
From report at bugs.python.org Thu Jul 30 03:23:22 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 30 Jul 2009 01:23:22 +0000
Subject: [New-bugs-announce] [issue6600] MemoryError in AiX 64-bit build
In-Reply-To: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
Message-ID: <1248917002.34.0.391671010793.issue6600@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
(currently investigating the root cause of this issue...)
bash-2.04$ build/py2_6_2-aix5-powerpc-apy26-rrun/python/python -c "open
('/tmp/test', 'w')"
Traceback (most recent call last):
File "<string>", line 1, in <module>
MemoryError
bash-2.04$ build/py2_6_2-aix5-powerpc-apy26-rrun/python/python -c
"import platform; print platform.uname()"
('AIX', 'asaixv5152', '1', '5', '000C763E4C00', 'powerpc')
bash-2.04$ file build/py2_6_2-aix5-powerpc-apy26-rrun/python/python
build/py2_6_2-aix5-powerpc-apy26-rrun/python/python: 64-bit XCOFF
executable or object module not stripped
----------
components: Build, IO
messages: 91076
nosy: srid
severity: normal
status: open
title: MemoryError in AiX 64-bit build
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6600>
_______________________________________
From report at bugs.python.org Thu Jul 30 11:33:15 2009
From: report at bugs.python.org (Alexander Myodov)
Date: Thu, 30 Jul 2009 09:33:15 +0000
Subject: [New-bugs-announce] [issue6601] Fractions do not support other
Fractions as numerators or denominators
In-Reply-To: <1248946395.45.0.703572208084.issue6601@psf.upfronthosting.co.za>
Message-ID: <1248946395.45.0.703572208084.issue6601@psf.upfronthosting.co.za>
New submission from Alexander Myodov <amyodov at gmail.com>:
Occurs in 2.6, doesn't occur in 3.1.
Example:
Python 2.6.2+ (release26-maint, Jun 23 2009, 07:08:39)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> Fraction(Fraction(3,5), Fraction(1,2))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/fractions.py", line 99, in __new__
numerator = operator.index(numerator)
TypeError: 'Fraction' object cannot be interpreted as an index
Compare:
Python 3.1 (r31:73572, Jul 23 2009, 23:41:26)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> Fraction(Fraction(3,5), Fraction(1,2))
Fraction(6, 5)
----------
messages: 91088
nosy: honeyman
severity: normal
status: open
title: Fractions do not support other Fractions as numerators or denominators
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6601>
_______________________________________
From report at bugs.python.org Thu Jul 30 13:13:26 2009
From: report at bugs.python.org (tomkm)
Date: Thu, 30 Jul 2009 11:13:26 +0000
Subject: [New-bugs-announce] [issue6602] BaseHTTPServer log_message should
log to sys.stdout
In-Reply-To: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za>
Message-ID: <1248952406.18.0.680079792557.issue6602@psf.upfronthosting.co.za>
New submission from tomkm <tom at dialogue.net>:
I believe that the log_message method of BaseHTTPServer should log to
sys.stdout not sys.stderr, whereas log_error should log to sys.stderr
instead of just delegating to log_message.
I found this inconsistency when using SimpleXMLRPCServer which logs both
successful (200) and non-successful (non-200) requests to stderr when
logRequests is set to True.
----------
components: None
messages: 91093
nosy: tomkm
severity: normal
status: open
title: BaseHTTPServer log_message should log to sys.stdout
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6602>
_______________________________________
From report at bugs.python.org Thu Jul 30 16:30:36 2009
From: report at bugs.python.org (Artur Frysiak)
Date: Thu, 30 Jul 2009 14:30:36 +0000
Subject: [New-bugs-announce] [issue6603] Compilation error if configuref
--with-computed-gotos
In-Reply-To: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
Message-ID: <1248964236.44.0.906577171773.issue6603@psf.upfronthosting.co.za>
New submission from Artur Frysiak <wiget at pld-linux.org>:
Building Python 3.1 (or Python from mercural py3k branch) fail if
configured --with-computed-gotos.
Traceback (most recent call last):
File "./setup.py", line 13, in <module>
from distutils.core import Extension, setup
File "/home/users/wiget/mirror/python/cpython/Lib/distutils/core.py",
line 18, in <module>
from distutils.dist import Distribution
File "/home/users/wiget/mirror/python/cpython/Lib/distutils/dist.py",
line 12, in <module>
import warnings
File "/home/users/wiget/mirror/python/cpython/Lib/warnings.py", line
6, in <module>
import linecache
File "/home/users/wiget/mirror/python/cpython/Lib/linecache.py", line
10, in <module>
import tokenize
File "/home/users/wiget/mirror/python/cpython/Lib/tokenize.py", line
94, in <module>
Ignore = Whitespace + any(r'\\\r?\n' + Whitespace) + maybe(Comment)
File "/home/users/wiget/mirror/python/cpython/Lib/tokenize.py", line
87, in any
def any(*choices): return group(*choices) + '*'
TypeError: group() argument after ** must be a mapping, not tuple
make: *** [sharedmods] Error 1
Compiled on PLD Linux using GCC 4.4.1
----------
components: Build
messages: 91097
nosy: wiget
severity: normal
status: open
title: Compilation error if configuref --with-computed-gotos
type: compile error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6603>
_______________________________________
From report at bugs.python.org Thu Jul 30 18:54:36 2009
From: report at bugs.python.org (jan matejek)
Date: Thu, 30 Jul 2009 16:54:36 +0000
Subject: [New-bugs-announce] [issue6604] test_distutils subtest
test_get_exe_bytes fails depending on execution order
In-Reply-To: <1248972876.14.0.894982225722.issue6604@psf.upfronthosting.co.za>
Message-ID: <1248972876.14.0.894982225722.issue6604@psf.upfronthosting.co.za>
New submission from jan matejek <jmatejek at suse.cz>:
test_bdist_wininst.py fails in non-windows environment, depending on the
order of execution of tests in the test_distutils suite
When this test is not run on windows, msvccompiler.py fails to load
win32 registry modules and emits a warning-level message to the log.
Depending on which tests run before this test, the log threshold might
be set lower than WARN. in such case, The warning is actually printed,
test runner detects it and fails the test (which otherwise passes).
the attached patch sets log threshold to ERROR, silencing the warning
and producing a happier test ;e)
----------
assignee: tarek
components: Distutils
files: python-2.6.2-test_distutils.patch
keywords: patch
messages: 91100
nosy: matejcik, tarek
severity: normal
status: open
title: test_distutils subtest test_get_exe_bytes fails depending on execution order
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14607/python-2.6.2-test_distutils.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6604>
_______________________________________
From report at bugs.python.org Thu Jul 30 22:18:02 2009
From: report at bugs.python.org (Casey McGinty)
Date: Thu, 30 Jul 2009 20:18:02 +0000
Subject: [New-bugs-announce] [issue6605] smtplib.SMTP.sendmail() rejected
after quit(), connect() sequence, no HELO
In-Reply-To: <1248985082.82.0.727591290783.issue6605@psf.upfronthosting.co.za>
Message-ID: <1248985082.82.0.727591290783.issue6605@psf.upfronthosting.co.za>
New submission from Casey McGinty <casey.mcginty at gmail.com>:
The smtplib.SMTP.quit() method does not reset the 'helo_resp' and
'ehlo_resp' instance attributes. During the next
smtplib.SMTP.sendmail(), the HELO/EHLO commands are not sent, and may
cause the remote SMTP service to reject the message, due to improper
protocol handshaking.
To fix, self.helo_resp and self.ehlo_resp should be set to 'None' in the
smtplib.SMTP.quit() method.
----------
components: Library (Lib)
messages: 91107
nosy: cmcginty
severity: normal
status: open
title: smtplib.SMTP.sendmail() rejected after quit(),connect() sequence, no HELO
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6605>
_______________________________________
From report at bugs.python.org Thu Jul 30 22:24:52 2009
From: report at bugs.python.org (Joseph Tate)
Date: Thu, 30 Jul 2009 20:24:52 +0000
Subject: [New-bugs-announce] [issue6606] csv.Sniffer.sniff on data with
doublequotes doesn't set up the dialect properly
In-Reply-To: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
Message-ID: <1248985492.71.0.602333062674.issue6606@psf.upfronthosting.co.za>
New submission from Joseph Tate <jtate+python at dragonstrider.com>:
Given the attached code, the Sniffer.sniff routine does not set the
doublequote property. This results in errors during reader operations.
If the doublequote property is set in the dialect, the data is read
properly.
The data was created using oocalc, forcing it to use ascii quotes rather
than u'\u201c\u201d'.
----------
components: Library (Lib)
files: foo.py
messages: 91109
nosy: jtate
severity: normal
status: open
title: csv.Sniffer.sniff on data with doublequotes doesn't set up the dialect properly
type: behavior
versions: Python 2.4, Python 2.6
Added file: http://bugs.python.org/file14609/foo.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6606>
_______________________________________
From report at bugs.python.org Fri Jul 31 01:56:34 2009
From: report at bugs.python.org (Amir Habibi)
Date: Thu, 30 Jul 2009 23:56:34 +0000
Subject: [New-bugs-announce] [issue6607] asctime causing python to crash
In-Reply-To: <1248998194.31.0.18315754711.issue6607@psf.upfronthosting.co.za>
Message-ID: <1248998194.31.0.18315754711.issue6607@psf.upfronthosting.co.za>
New submission from Amir Habibi <amir at aryosys.com>:
I use:
Python 2.6.2
(r262:71605, Apr 14 2009, 22:40:02)
[MSC v.1500 32 bit (Intel)] on win32
import time
asctime((2009, 1, 1, 24, 0, 0, 0, 0, 0))
the 24 is a wrong parameter but it should'n't crash the engine. This may
be the side effect of a more serious problem though. An assertion may
fix it.
----------
components: None
messages: 91114
nosy: AmirHabibi
severity: normal
status: open
title: asctime causing python to crash
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6607>
_______________________________________
From report at bugs.python.org Fri Jul 31 01:56:48 2009
From: report at bugs.python.org (Amir Habibi)
Date: Thu, 30 Jul 2009 23:56:48 +0000
Subject: [New-bugs-announce] [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
New submission from Amir Habibi <amir at aryosys.com>:
I use:
Python 2.6.2
(r262:71605, Apr 14 2009, 22:40:02)
[MSC v.1500 32 bit (Intel)] on win32
import time
time.asctime((2009, 1, 1, 24, 0, 0, 0, 0, 0))
the 24 is a wrong parameter but it should'n't crash the engine. This may
be the side effect of a more serious problem though. An assertion may
fix it.
----------
components: None
messages: 91115
nosy: AmirHabibi
severity: normal
status: open
title: asctime causing python to crash
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6608>
_______________________________________
From report at bugs.python.org Fri Jul 31 02:12:50 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 31 Jul 2009 00:12:50 +0000
Subject: [New-bugs-announce] [issue6609] zipfile: WindowsError [267] The
directory name is invalid
In-Reply-To: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
Message-ID: <1248999170.31.0.424602339152.issue6609@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
The following exception occured when I tried to extract http://
sourceforge.net/projects/slut/files/slut/slut-0.9.0/slut-0.9.0.zip/
download using the zipfile module on Windows XP.
C:\\HOME\\as\\pypm-infinitude\\scratch\\b\\slut-0.9.0.zip.work is 1)
current working directory 2) directory where the zip file was stored,
3) directory where the extraction is to happen.
[...]
f.extractall()
File "C:\Python26\lib\zipfile.py", line 935, in extractall
self.extract(zipinfo, path, pwd)
File "C:\Python26\lib\zipfile.py", line 923, in extract
return self._extract_member(member, path, pwd)
File "C:\Python26\lib\zipfile.py", line 957, in _extract_member
os.makedirs(upperdirs)
File "C:\Python26\lib\os.py", line 157, in makedirs
mkdir(name, mode)
WindowsError: [Error 267] The directory name is invalid: 'C:\\HOME\\as\
\pypm-infinitude\\scratch\\b\\slut-0.9.0.zip.work\\slut-0.9\\aux'
----------
components: Library (Lib), Windows
messages: 91116
nosy: srid
severity: normal
status: open
title: zipfile: WindowsError [267] The directory name is invalid
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6609>
_______________________________________
From report at bugs.python.org Fri Jul 31 02:27:04 2009
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 31 Jul 2009 00:27:04 +0000
Subject: [New-bugs-announce] [issue6610] Subprocess descriptor debacle
In-Reply-To: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
Message-ID: <1249000024.51.0.280381658662.issue6610@psf.upfronthosting.co.za>
New submission from Christian Heimes <lists at cheimes.de>:
The subprocess module may suffer from a minor design flaw that is
described at http://unixwiz.net/techtips/remap-pipe-fds.html under the
heading "Descriptor Debacle". The problem can occur under rare
conditions when a subprocess is created from a Python daemon process.
Proposed solution:
Create a function os.duprange(*args) that takes one or more tuple pairs
of file descriptors. The function takes care of the necessary order and
dubbing of fds.
----------
components: Library (Lib)
keywords: easy, needs review
messages: 91118
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Subprocess descriptor debacle
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6610>
_______________________________________
From report at bugs.python.org Fri Jul 31 09:45:54 2009
From: report at bugs.python.org (Liu DongMiao)
Date: Fri, 31 Jul 2009 07:45:54 +0000
Subject: [New-bugs-announce] [issue6611] HTMLParser cannot deal with mixture
of arbitrary data and character reference
In-Reply-To: <1249026354.39.0.530341625498.issue6611@psf.upfronthosting.co.za>
Message-ID: <1249026354.39.0.530341625498.issue6611@psf.upfronthosting.co.za>
New submission from Liu DongMiao <liudongmiao at gmail.com>:
HTMLParser (Python 2.6.2) Cannot deal with mixture of arbitrary data and
character reference.
In line 365-373, replaceEntities(s) returns unichr(charref) in unicode,
which cannot be a mixture with arbitrary data in str.
A fix way: replace unichr(c) with unichr(c).encode('utf-8').
----------
components: Library (Lib)
files: chinese.py
messages: 91128
nosy: liudongmiao at gmail.com
severity: normal
status: open
title: HTMLParser cannot deal with mixture of arbitrary data and character reference
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14613/chinese.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6611>
_______________________________________
From report at bugs.python.org Fri Jul 31 11:53:27 2009
From: report at bugs.python.org (W. Trevor King)
Date: Fri, 31 Jul 2009 09:53:27 +0000
Subject: [New-bugs-announce] [issue6612] 'import site' fails when called
from an unlinked directory
In-Reply-To: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
Message-ID: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
New submission from W. Trevor King <wking at drexel.edu>:
I don't imagine this comes up very often, but:
$ mkdir /tmp/a; cd /tmp/a; rmdir /tmp/a; python -c 'import site';
rmdir: removing directory, /tmp/a
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/wking/lib/python/site.py", line 73, in <module>
__boot()
File "/home/wking/lib/python/site.py", line 33, in __boot
imp.load_module('site',stream,path,descr)
File "/usr/lib/python2.5/site.py", line 408, in <module>
main()
File "/usr/lib/python2.5/site.py", line 392, in main
paths_in_sys = removeduppaths()
File "/usr/lib/python2.5/site.py", line 96, in removeduppaths
dir, dircase = makepath(dir)
File "/usr/lib/python2.5/site.py", line 72, in makepath
dir = os.path.abspath(os.path.join(*paths))
File "/usr/lib/python2.5/posixpath.py", line 403, in abspath
path = join(os.getcwd(), path)
OSError: [Errno 2] No such file or directory
----------
messages: 91129
nosy: labrat
severity: normal
status: open
title: 'import site' fails when called from an unlinked directory
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6612>
_______________________________________
From report at bugs.python.org Fri Jul 31 17:13:43 2009
From: report at bugs.python.org (Tiago Coutinho)
Date: Fri, 31 Jul 2009 15:13:43 +0000
Subject: [New-bugs-announce] [issue6613] ctypes.PyThreadState_SetAsyncExc
does not work on linux 64bit machines
In-Reply-To: <1249053223.75.0.703019238493.issue6613@psf.upfronthosting.co.za>
Message-ID: <1249053223.75.0.703019238493.issue6613@psf.upfronthosting.co.za>
New submission from Tiago Coutinho <coutinhotiago at gmail.com>:
Hello,
It seems that the ctypes.PyThreadState_SetAsyncExc is not working in
Linux 64bits machines
I have tried the code in attachment in python 2.5 and 2.6 in both 32bits
and 64bits machines with the following return:
| linux 32bits | linux 64bits |
------|--------------|--------------|
py2.5 | 1 (OK) | 0 (ERR) |
py2.6 | 1 (OK) | 0 (ERR) |
I have also tried to make a python extension in C++ exporting a function
to python that simply calls the C++ PyThreadState_SetAsyncExc and this
works fine.
----------
assignee: theller
components: ctypes
files: t16.py
messages: 91131
nosy: coutinhotiago, theller
severity: normal
status: open
title: ctypes.PyThreadState_SetAsyncExc does not work on linux 64bit machines
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14614/t16.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6613>
_______________________________________
From report at bugs.python.org Fri Jul 31 18:56:02 2009
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 31 Jul 2009 16:56:02 +0000
Subject: [New-bugs-announce] [issue6614] heapq.nsmallest and nlargest should
be smarter/more usable/more consistent
In-Reply-To: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
Message-ID: <1249059362.21.0.599959669928.issue6614@psf.upfronthosting.co.za>
New submission from Joshua Bronson <jabronson at gmail.com>:
>From http://docs.python.org/library/heapq.html:
> The latter two functions (nlargest and nsmallest) perform best for
> smaller values of n. For larger values, it is more efficient to use
> the sorted() function. Also, when n==1, it is more efficient to use
> the builtin min() and max() functions.
A quick usability win for the heapq module: Be more specific than "smaller" and
"larger", e.g. "when n is O(...(len(iterable)))".
>From http://groups.google.com/group/comp.lang.python/msg/9556f56ae25ecf3b:
> I find it interesting that the heapq functions tell you in the
> documentation that they aren't suitable for use where n==1 or where
> n is near the total size of the sequence whereas random.sample()
> chooses what it thinks is the best algorithm based on the input. At
> the very least I would have thought the heapq functions could check
> for n==1 and call min/max when it is.
+1. It looks like the pure Python implementation of nsmallest is actually already
choosing either an insort algorithm or a minheap algorithm based on whether n * 10 <=
len(iterable), but the C implementation of nsmallest unconditionally uses a minheap
algorithm. Neither the pure Python nor the C implementation of nlargest chooses its
algorithm conditionally. For the sake of consistency and usability, all
implementations of nsmallest and nlargest should choose the most efficient algorithm
from among min/max, insort, and minheap, and the docs should be updated to describe
this behavior.
Also, in looking through the heapq.py that came with my Python 2.6.2 distribution, I
noticed that line 196 seems to have no reason to be there:
_heappushpop = heappushpop
This is the only occurrence of "_heappushpop" in the file.
I made a patch for heapq.py, but since I'm not a CPython hacker, I thought it might
be better to leave the changes up to someone who could do both the pure Python and
the C implementations in tandem. I'd be happy to contribute documentation when the
time comes if that would help.
----------
messages: 91134
nosy: jab
severity: normal
status: open
title: heapq.nsmallest and nlargest should be smarter/more usable/more consistent
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6614>
_______________________________________