From report at bugs.python.org Tue Sep 1 00:20:14 2009
From: report at bugs.python.org (Seamus O'Shea)
Date: Mon, 31 Aug 2009 22:20:14 +0000
Subject: [New-bugs-announce] [issue6812] Snow Leopard python program fails
because _PyType_Modified is missing from python framework
In-Reply-To: <1251757214.1.0.925595604794.issue6812@psf.upfronthosting.co.za>
Message-ID: <1251757214.1.0.925595604794.issue6812@psf.upfronthosting.co.za>
New submission from Seamus O'Shea <oshea at uleth.ca>:
Attempts to compile a simple example using XCode 3.2 (Xcode IDE: 1610.0,
Xcode Core: 1608.0, ToolSupport: 1591.0)under Snow Leopard fail with
error message
Traceback (most recent call last):
File "/Users/seamus/Science/xcode exploration/Objc-
programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/ma
in.py", line 10, in <module>
import objc
File
"/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib
/python/PyObjC/objc/__init__.py", line 22, in <module>
_update()
File
"/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib
/python/PyObjC/objc/__init__.py", line 19, in _update
import _objc
ImportError:
dlopen(/System/Library/Frameworks/Python.framework/Versions/Current/Extr
as/lib/python/PyObjC/objc/_objc.so, 2): Symbol not found:
_PyType_Modified
Referenced from:
/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/
python/PyObjC/objc/_objc.so
Expected in: flat namespace
in
/System/Library/Frameworks/Python.framework/Versions/Current/Extras/lib/
python/PyObjC/objc/_objc.so
2009-08-31 08:31:23.534 First_PyObjC[4072:a0f] *** Terminating app due
to uncaught exception 'NSInternalInconsistencyException', reason:
'/Users/seamus/Science/xcode exploration/Objc-
programs/First_PyObjC/main.m:46 main() PyRun_SimpleFile failed with file
'/Users/seamus/Science/xcode exploration/Objc-
programs/First_PyObjC/build/Debug/First_PyObjC.app/Contents/Resources/ma
in.py'. See console for errors.'
*** Call stack at first throw:
(
0 CoreFoundation 0x90a1858a __raiseError
+ 410
1 libobjc.A.dylib 0x9309cf49
objc_exception_throw + 56
2 CoreFoundation 0x90a182b8 +[NSException
raise:format:arguments:] + 136
3 CoreFoundation 0x90a1822a +[NSException
raise:format:] + 58
4 First_PyObjC 0x00002bc2 main + 1084
5 First_PyObjC 0x0000275a start + 54
)
sharedlibrary apply-load-rules all
The Current Version in the system library is 2.6.
Any suggestions?
----------
assignee: ronaldoussoren
components: Macintosh
messages: 92117
nosy: ronaldoussoren, soshea
severity: normal
status: open
title: Snow Leopard python program fails because _PyType_Modified is missing from python framework
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6812>
_______________________________________
From report at bugs.python.org Tue Sep 1 06:05:06 2009
From: report at bugs.python.org (Daniel Black)
Date: Tue, 01 Sep 2009 04:05:06 +0000
Subject: [New-bugs-announce] [issue6813] update format() documentation and
tutorial
In-Reply-To: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>
Message-ID: <1251777906.33.0.931142737183.issue6813@psf.upfronthosting.co.za>
New submission from Daniel Black <daniel at cacert.org>:
Release notes show the use of '{}'.format('this') and the attached patch
updates this to be the default example in the tutorial. Library
references are updated to show field_name as optional and a few examples
are added.
Relates to the improvements from issue 5237.
----------
assignee: georg.brandl
components: Documentation
files: documentation-str-format.patch
keywords: patch
messages: 92119
nosy: georg.brandl, grooverdan
severity: normal
status: open
title: update format() documentation and tutorial
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14812/documentation-str-format.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6813>
_______________________________________
From report at bugs.python.org Tue Sep 1 08:11:33 2009
From: report at bugs.python.org (Daniel Black)
Date: Tue, 01 Sep 2009 06:11:33 +0000
Subject: [New-bugs-announce] [issue6814] xrange removal from documentation
In-Reply-To: <1251785493.22.0.615787122176.issue6814@psf.upfronthosting.co.za>
Message-ID: <1251785493.22.0.615787122176.issue6814@psf.upfronthosting.co.za>
New submission from Daniel Black <daniel at cacert.org>:
xrange still exists in bits of documentation here and there.
patch fixes it.
----------
assignee: georg.brandl
components: Documentation
files: xrange-doco.patch
keywords: patch
messages: 92120
nosy: georg.brandl, grooverdan
severity: normal
status: open
title: xrange removal from documentation
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14813/xrange-doco.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6814>
_______________________________________
From report at bugs.python.org Tue Sep 1 09:51:17 2009
From: report at bugs.python.org (Alexandr Zamaraev)
Date: Tue, 01 Sep 2009 07:51:17 +0000
Subject: [New-bugs-announce] [issue6815] UnicodeDecodeError in
os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
New submission from Alexandr Zamaraev <shura_zam at users.sourceforge.net>:
OS Windows Vista Home Basic Ru + sp2
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Simple code to crach (file expandvars_bug.py):
[code]
# -*- coding: cp1251 -*-
import os.path
var = r'C:\????\Microsoft'
print os.path.expandvars(var)
print os.path.expandvars(unicode(var))
[/code]
Console session:
[code]
C:\????\Microsoft
Traceback (most recent call last):
File "C:\Lang\test\python\expandvars_bug.py", line 6, in <module>
print os.path.expandvars(unicode(var))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 3:
ordinal
not in range(128)
[/code]
----------
components: Unicode
messages: 92124
nosy: shura_zam
severity: normal
status: open
title: UnicodeDecodeError in os.path.expandvars
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6815>
_______________________________________
From report at bugs.python.org Tue Sep 1 12:56:39 2009
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Sep 2009 10:56:39 +0000
Subject: [New-bugs-announce] [issue6816] Provide CPython command line
functionality via runpy module
In-Reply-To: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
Message-ID: <1251802599.29.0.539498266032.issue6816@psf.upfronthosting.co.za>
New submission from Nick Coghlan <ncoghlan at gmail.com>:
Currently, the runpy._run_module_as_main() function allows a launch
script to mimic Python's -m switch fairly well.
This RFE suggests making it possible to mimic other command line
behaviour of the CPython interpreter in a documented fashion:
run_module_as_main - document and make public the existing
_run_module_as_main function (exposes -m style functionality)
run_path_as_main - accept a filesystem path and execute it as per the
command line rules for executing named scripts, zipfiles and directories
(exposes normal script execution functionality)
run_file_as_main - accept a file-like object and execute it as per the
command line rules for executing stdin (exposes '-' style functionality)
run_code_as_main - accept a string or code object and execute it
(exposes -c style functionality)
The runpy module would also be updated to expose these via its command
line to ensure they achieve their stated goal of allowing a launch
script to mimic the native interpreter behaviour. Due to the legacy of
implementing -m style execution by default, the module command line will
expose filesystem path execution through a '-f' switch.
----------
messages: 92140
nosy: ncoghlan
severity: normal
status: open
title: Provide CPython command line functionality via runpy module
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6816>
_______________________________________
From report at bugs.python.org Wed Sep 2 04:57:46 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 02 Sep 2009 02:57:46 +0000
Subject: [New-bugs-announce] [issue6817] char buffer in function
posix_getcwdu should not be fix length
In-Reply-To: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>
Message-ID: <1251860266.99.0.218849353808.issue6817@psf.upfronthosting.co.za>
New submission from Boya Sun <boya.sun at case.edu>:
This issue is similar to issue 2722 (http://bugs.python.org/issue2722#),
where the char buffer support that the path string has
not fixed length in the function posix_getcwd().
In the function posix_getcwdu(), the char buffer is still fix length. But
I think the same change should also apply to this function. A patch is
attached to allow the char buffer in posix_getcwdu() to be not fixed
length.
----------
files: patch_get_cwdu.diff
keywords: patch
messages: 92151
nosy: boya
severity: normal
status: open
title: char buffer in function posix_getcwdu should not be fix length
Added file: http://bugs.python.org/file14818/patch_get_cwdu.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6817>
_______________________________________
From report at bugs.python.org Wed Sep 2 06:42:12 2009
From: report at bugs.python.org (Ross)
Date: Wed, 02 Sep 2009 04:42:12 +0000
Subject: [New-bugs-announce] [issue6818] remove/delete method for
zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
New submission from Ross <rossmclendon at tamu.edu>:
It would be most helpful if a method could be included in the TarFile
class of the tarfile module and the ZipFile class of the zipfile module
that would remove a particular file (either given by a name or a
TarInfo/ZipInfo object) from the archive.
Usage to remove a single file from an archive would be as follows:
import zipfile
zipFileObject = zipfile.ZipFile(archiveName,'a')
zipFileObject.remove(fileToRemove)
zipFileObject.close()
Such a method should probably only apply to archives that are in append
mode as write mode would erase the original archive and read mode should
render the archive immutable.
One possible extra to be included is to allow a list of file names or
ZipInfo/TarInfo objects to be passed into the remove method, such that
all items in the list would be removed from the archive.
----------
components: Library (Lib)
messages: 92154
nosy: rossmclendon
severity: normal
status: open
title: remove/delete method for zipfile/tarfile objects
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6818>
_______________________________________
From report at bugs.python.org Wed Sep 2 08:01:58 2009
From: report at bugs.python.org (Jon Parise)
Date: Wed, 02 Sep 2009 06:01:58 +0000
Subject: [New-bugs-announce] [issue6819] Typo in datamodel.rst ("Custon" ->
"Custom")
In-Reply-To: <1251871318.67.0.564956754608.issue6819@psf.upfronthosting.co.za>
Message-ID: <1251871318.67.0.564956754608.issue6819@psf.upfronthosting.co.za>
New submission from Jon Parise <jon at indelible.org>:
reference/datamodel.rst misspells "Custom" as "Custon". The attached
patch fixes that.
----------
assignee: georg.brandl
components: Documentation
files: datamodel.custon.diff
keywords: patch
messages: 92157
nosy: georg.brandl, jon
severity: normal
status: open
title: Typo in datamodel.rst ("Custon" -> "Custom")
versions: Python 3.2
Added file: http://bugs.python.org/file14819/datamodel.custon.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6819>
_______________________________________
From report at bugs.python.org Wed Sep 2 11:39:46 2009
From: report at bugs.python.org (rgpitts)
Date: Wed, 02 Sep 2009 09:39:46 +0000
Subject: [New-bugs-announce] [issue6820] Redefinition of HAVE_STRFTIME can
cause compiler errors.
In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
Message-ID: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
New submission from rgpitts <richard.pitts at cdl.co.uk>:
I'm working with the Python C API and omniOrb with Visual Studio 2008
on Windows XP.
A OmniOrb header corba_sys_dep.h is defining HAVE_STRFTIME as 1
...
#define HAVE_STRFTIME 1
...
pyconfig.h is then defining this again.
...
#define HAVE_STRFTIME
...
This is raising a compiler warning and then multiple syntax errors in
math.h depending on the order of inclusion of these headers. If the
pyconfig.h is included after corba_sys_dep.h multiple syntax errors.
However if it is included before only a warning is raised.
I think pyconfig.h needs changing to
#ifndef HAVE_STRFTIME
#define HAVE_STRFTIME
#endif
----------
components: Windows
messages: 92159
nosy: rgpitts
severity: normal
status: open
title: Redefinition of HAVE_STRFTIME can cause compiler errors.
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6820>
_______________________________________
From report at bugs.python.org Wed Sep 2 14:40:25 2009
From: report at bugs.python.org (egreen)
Date: Wed, 02 Sep 2009 12:40:25 +0000
Subject: [New-bugs-announce] [issue6821] incorrect doc for PyBuffer_Release
In-Reply-To: <1251895225.69.0.615338727818.issue6821@psf.upfronthosting.co.za>
Message-ID: <1251895225.69.0.615338727818.issue6821@psf.upfronthosting.co.za>
New submission from egreen <egreen at operamail.com>:
In documentation (c-api/buffer.html):
void PyBuffer_Release(PyObject *obj, Py_buffer *view)
should be:
void PyBuffer_Release(Py_buffer *view)
(as per Include/abstract.h)
----------
assignee: georg.brandl
components: Documentation
messages: 92165
nosy: egreen, georg.brandl
severity: normal
status: open
title: incorrect doc for PyBuffer_Release
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6821>
_______________________________________
From report at bugs.python.org Wed Sep 2 15:01:29 2009
From: report at bugs.python.org (Robert DeVaughn)
Date: Wed, 02 Sep 2009 13:01:29 +0000
Subject: [New-bugs-announce] [issue6822] Error calling .storlines from ftplib
In-Reply-To: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
Message-ID: <1251896489.26.0.54536142072.issue6822@psf.upfronthosting.co.za>
New submission from Robert DeVaughn <rdevaughn at gmail.com>:
When attempting to store a file via FTP, the following error occurs. See
attached code.
Traceback (most recent call last):
File "C:\Documents and
Settings\rdevaughn\Desktop\HTTP\src\FTP_directory.py", line 14, in
<module>
ftp.storlines("STOR source.txt",f)
File "C:\Python30\lib\ftplib.py", line 477, in storlines
if buf[-1] in B_CRLF: buf = buf[:-1]
TypeError: Type str doesn't support the buffer AP
----------
components: Library (Lib)
files: module.txt
messages: 92166
nosy: rdevaughn
severity: normal
status: open
title: Error calling .storlines from ftplib
type: compile error
versions: Python 3.0
Added file: http://bugs.python.org/file14820/module.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6822>
_______________________________________
From report at bugs.python.org Wed Sep 2 17:40:51 2009
From: report at bugs.python.org (Richard Shapiro)
Date: Wed, 02 Sep 2009 15:40:51 +0000
Subject: [New-bugs-announce] [issue6823] time.strftime does unnecessary
range check
In-Reply-To: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
Message-ID: <1251906051.81.0.942074704483.issue6823@psf.upfronthosting.co.za>
New submission from Richard Shapiro <rashapiro83 at gmail.com>:
in Modules/timemodule.c, in the routine time_strftime, there is a range
check on the tm_isdst field:
if (buf.tm_isdst < -1 || buf.tm_isdst > 1) {
PyErr_SetString(PyExc_ValueError,
"daylight savings flag out of range");
return NULL;
}
This check is incorrect, as the tm_isdst field is interpreted as less
than 0, 0, or greater than zero (see the comment at the top of the
routine, and the documentation for the strftime function).
Unfortunately, there exists at least one platform for which tm_isdst is
set to something other than -1, 0, or 1 (on IBM zOS it's apparently set
to 2 for daylight savings). This means that you can't do the obvious
strftime(...,localtime(...)) to format a time.
The fix is to either remove the range check entirely, or else to
normalize the +1, -1, or 0. The former is preferred unless there is some
platform on which strftime doesn't do the right thing with values
outside the range of [-1,1].
This bug exists in 2.5.1 and 2.6.2. I haven't checked other versions.
----------
components: Library (Lib)
messages: 92170
nosy: rshapiro
severity: normal
status: open
title: time.strftime does unnecessary range check
type: behavior
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6823>
_______________________________________
From report at bugs.python.org Wed Sep 2 18:43:01 2009
From: report at bugs.python.org (Ritesh Raj Sarraf)
Date: Wed, 02 Sep 2009 16:43:01 +0000
Subject: [New-bugs-announce] [issue6824] help for a module should list
supported platforms
In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
Message-ID: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za>
New submission from Ritesh Raj Sarraf <rrs at researchut.com>:
Whey I do a help (python-module), I get the help text as follows:
Help on module tempfile:
NAME
tempfile - Temporary files.
FILE
/usr/lib/python2.5/tempfile.py
MODULE DOCS
http://www.python.org/doc/2.5.4/lib/module-tempfile.html
DESCRIPTION
This module provides generic, low- and high-level interfaces for
creating temporary files and directories. The interfaces listed
as "safe" just below can be used without fear of race conditions.
Those listed as "unsafe" cannot, and are provided for backward
compatibility only.
The link to the webpage lists the supported platforms for the module.
It would be good to have an entry stating the list of platforms supported
by the module, in the module doc itself.
----------
assignee: georg.brandl
components: Documentation
messages: 92173
nosy: georg.brandl, rickysarraf
severity: normal
status: open
title: help for a module should list supported platforms
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6824>
_______________________________________
From report at bugs.python.org Wed Sep 2 22:35:24 2009
From: report at bugs.python.org (Evan Driscoll)
Date: Wed, 02 Sep 2009 20:35:24 +0000
Subject: [New-bugs-announce] [issue6825] Minor documentation bug with
os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
New submission from Evan Driscoll <evaned at gmail.com>:
The documentation for os.path.split says, in part:
"In nearly all cases, join(head, tail) equals path (the only
exception being when there were multiple slashes separating head
from tail)."
But this is not quite true: that's not the *only* exception, at least
without a somewhat liberal definition of "equals".
This can also happen if os.altsep is used in the path being split, in
which case it will be replaced by os.sep:
>>> import ntpath
>>> path = "a/b"
>>> (head, tail) = ntpath.split(path)
>>> joined = ntpath.join(head, tail)
>>> joined == path
False
>>> joined
'a\\b'
[I only selected the versions that I actually verified, but I would
guess it's present in more.]
----------
assignee: georg.brandl
components: Documentation
messages: 92180
nosy: evaned, georg.brandl
severity: normal
status: open
title: Minor documentation bug with os.path.split
versions: Python 2.6, Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6825>
_______________________________________
From report at bugs.python.org Wed Sep 2 22:49:20 2009
From: report at bugs.python.org (Joseph Thomson)
Date: Wed, 02 Sep 2009 20:49:20 +0000
Subject: [New-bugs-announce] [issue6826] Add __contains__ to range type
In-Reply-To: <1251924560.8.0.143337742055.issue6826@psf.upfronthosting.co.za>
Message-ID: <1251924560.8.0.143337742055.issue6826@psf.upfronthosting.co.za>
New submission from Joseph Thomson <joseph.thomson at gmail.com>:
The range type should implement the __contains__ method. Currently an
expression like 'x in range(10000000)' will iterate through every item
in the range (exiting when an item tests true for equality); this is
highly unnecessary as the following expression will perform the same
function in a fraction of the time:
value >= start and value < stop and (value - start) % step == 0
The biggest advantage of this modification would be to allow users to say:
if foo in range(lower, upper):
bar()
instead of:
if foo >= lower and foo < upper:
bar()
safe in the knowledge that they are losing no performance. The former
is also far more Pythonic in my opinion :).
If there is still any doubt (which I doubt), I have attached an example
script showing what is to be gained.
----------
components: Interpreter Core
files: range.py
messages: 92183
nosy: hpesoj
severity: normal
status: open
title: Add __contains__ to range type
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file14821/range.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6826>
_______________________________________
From report at bugs.python.org Wed Sep 2 23:29:52 2009
From: report at bugs.python.org (Shaun Cutts)
Date: Wed, 02 Sep 2009 21:29:52 +0000
Subject: [New-bugs-announce] [issue6827] deepcopy erroneously doesn't call
__setstate__ if __getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
New submission from Shaun Cutts <shauncutts at users.sourceforge.net>:
Line 335 of copy.py guards call to __setstate__ with
if state:
...
However, __getstate__ may legitimately return an empty dictionary even
if __setstate__ still needs to be called. For example,
__setstate__/__getstate__ pair may not want to "persist" default values
(as is the case for me).
The fix would be to change this line to (e.g.):
if state is not None:
...
----------
components: Library (Lib)
files: deepcopy_bug.py
messages: 92186
nosy: shauncutts
severity: normal
status: open
title: deepcopy erroneously doesn't call __setstate__ if __getstate__ returns empty dict
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file14822/deepcopy_bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6827>
_______________________________________
From report at bugs.python.org Thu Sep 3 04:44:41 2009
From: report at bugs.python.org (Gabriel Genellina)
Date: Thu, 03 Sep 2009 02:44:41 +0000
Subject: [New-bugs-announce] [issue6828] wrongly highlighted blocks in the
Tutorial
In-Reply-To: <1251945881.72.0.464228919269.issue6828@psf.upfronthosting.co.za>
Message-ID: <1251945881.72.0.464228919269.issue6828@psf.upfronthosting.co.za>
New submission from Gabriel Genellina <gagsl-py2 at yahoo.com.ar>:
In the tutorial, some blocks were wrongly highlighted as being Python
code when they were actually just program output.
This patch adds the missing ``highlightlang:: none`` declarations.
See http://permalink.gmane.org/gmane.comp.python.general/636597
----------
assignee: georg.brandl
components: Documentation
files: introduction.diff
keywords: patch
messages: 92190
nosy: gagenellina, georg.brandl
severity: normal
status: open
title: wrongly highlighted blocks in the Tutorial
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14823/introduction.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6828>
_______________________________________
From report at bugs.python.org Thu Sep 3 09:20:19 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Sep 2009 07:20:19 +0000
Subject: [New-bugs-announce] [issue6829] Frendly error message when
inheriting from function
In-Reply-To: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
Message-ID: <1251962419.95.0.109154121907.issue6829@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
It is an error to try to inherit from function and the error message in
this case is:
{{{
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "m:\p\pb.py", line 4, in <module>
class PostgreSQLConnection(DatabaseConnection):
TypeError: Error when calling the metaclass bases
function() argument 1 must be code, not str
}}}
Something like 'Impossible to inherit from function' will clear
confusion state from users unfamiliar with metaclasses.
{{{
def DatabaseConnection(object):
pass
class PostgreSQLConnection(DatabaseConnection):
pass
}}}
----------
components: Interpreter Core
messages: 92191
nosy: techtonik
severity: normal
status: open
title: Frendly error message when inheriting from function
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6829>
_______________________________________
From report at bugs.python.org Thu Sep 3 10:23:50 2009
From: report at bugs.python.org (Toshihiro Kamiya)
Date: Thu, 03 Sep 2009 08:23:50 +0000
Subject: [New-bugs-announce] [issue6830] Some uniformness in defaultdict
In-Reply-To: <1251966230.42.0.696554317136.issue6830@psf.upfronthosting.co.za>
Message-ID: <1251966230.42.0.696554317136.issue6830@psf.upfronthosting.co.za>
New submission from Toshihiro Kamiya <t-kamiya at aist.go.jp>:
I found the syntax of collections.defaultdict is confusing, at least to
me.
When I need a defaultdict of int, that is, a defaultdict which contains
int objects, I can write simply:
a = defaultdict(int)
However, when I want a defaultdict of defaultdict of something, I can't
write:
d = defaultdict(defaultdict(int))
This raises TypeError.
I understand the argument of defaultdict is not a type (or class), but
a factory by definition. So I should to write:
d = defaultdict(lambda: defaultdict(int))
But this syntax is somehow confusing to me.
Am I missing some important feature of defaultdict?
The workaround that I've found is:
import collections
class __Helper(object):
def __getitem__(self, ctor):
return lambda: collections.defaultdict(lambda: ctor())
genericdefaultdict = __Helper()
This helper introduce some generics flavor in defaultdict.
The above cases can be spelt out:
a = genericdefaultdict[int]()
d = genericdefaultdict[genericdefaultdict[int]]()
----------
components: Library (Lib)
files: ddh.py
messages: 92193
nosy: t-kamiya
severity: normal
status: open
title: Some uniformness in defaultdict
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file14824/ddh.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6830>
_______________________________________
From report at bugs.python.org Thu Sep 3 10:24:13 2009
From: report at bugs.python.org (=?utf-8?q?Jonas_Bystr=C3=B6m?=)
Date: Thu, 03 Sep 2009 08:24:13 +0000
Subject: [New-bugs-announce] [issue6831] 2to3 assignment division conversion
In-Reply-To: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>
Message-ID: <1251966253.23.0.241992051928.issue6831@psf.upfronthosting.co.za>
New submission from Jonas Bystr?m <highfestiva at gmail.com>:
Code from 2.x containing __idiv__ does not translate into
def __floordiv__(self, x): self.__truediv__(x)
def __truediv__(self, x): ...
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 92194
nosy: highfestiva
severity: normal
status: open
title: 2to3 assignment division conversion
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6831>
_______________________________________
From report at bugs.python.org Thu Sep 3 11:29:55 2009
From: report at bugs.python.org (Jerzy)
Date: Thu, 03 Sep 2009 09:29:55 +0000
Subject: [New-bugs-announce] [issue6832] Outputting unicode crushes when
printing to file on Linux
In-Reply-To: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
Message-ID: <1251970195.88.0.252657466377.issue6832@psf.upfronthosting.co.za>
New submission from Jerzy <jerzyo at genesilico.pl>:
Hi
When I am outputting unicode strings to terminal my script works OK, but
when I redirect it to file I get a crash:
$ python mailing/message_sender.py -l Bia
Bia?ystok
$ python mailing/message_sender.py -l Bia > ~/tmp/aaa.txt
Traceback (most recent call last):
File "mailing/message_sender.py", line 71, in <module>
list_groups(unicode(args[0],'utf-8'))
File "mailing/message_sender.py", line 53, in list_groups
print group[1].name
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0142' in
position 3: ordinal not in range(128)
----------
components: Unicode
messages: 92196
nosy: Orlowski
severity: normal
status: open
title: Outputting unicode crushes when printing to file on Linux
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6832>
_______________________________________
From report at bugs.python.org Thu Sep 3 13:25:32 2009
From: report at bugs.python.org (Paul van der Linden)
Date: Thu, 03 Sep 2009 11:25:32 +0000
Subject: [New-bugs-announce] [issue6833] incorrect: failed local variable
referenced before assignment
In-Reply-To: <1251977132.94.0.194945951914.issue6833@psf.upfronthosting.co.za>
Message-ID: <1251977132.94.0.194945951914.issue6833@psf.upfronthosting.co.za>
New submission from Paul van der Linden <paul at soulbase.nl>:
The attached python file will give the following output, which is
incorrect behavior as far as I know:
"
this will fail
failed local variable 'in_std' referenced before assignment
this won't fail
Not failed
this won't fail either
Not failed
"
This is tested on windows with python2.6(standard msi) and on centos
5.3 with python2.6 (custom rpm), python2.4 (system rpm), freebsd with
python2.5 (system package), python2.6 ("hand" compiled) and python3.0
("hand" compiled).
The attached code is stripped down to the bare minimum and therefore
won't do anything usefull.
----------
components: None
files: bug.py
messages: 92199
nosy: paultjuhatwork
severity: normal
status: open
title: incorrect: failed local variable referenced before assignment
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14825/bug.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6833>
_______________________________________
From report at bugs.python.org Thu Sep 3 16:24:45 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Sep 2009 14:24:45 +0000
Subject: [New-bugs-announce] [issue6834] use different mechanism for pythonw
on osx
In-Reply-To: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
Message-ID: <1251987885.23.0.814311669715.issue6834@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
Note: this is mostly a reminder for myself to clean up the pythonw stub
executable
The current implementation of pythonw on OSX uses exec to start an
executable inside the framework, this is needed to be able to use GUI
functionality from the command-line without resorting to undocumented
and unsupported system APIs. To deal with selection between 32-bit and
64-bit the framework contains a number of python executables.
Using "posix_spawnattr_setbinpref_np", "posix_spawnattr_setflags" and
"posix_spawn" it is possible to do away with the additional executables,
leaving a simpler situation.
Nice to have features:
* python(1) on SnowLeopard has a system preference to select between 32-
bit and 64-bit:
$ defaults read com.apple.versioner.python
{
"Prefer-32-Bit" = 1;
}
(The "versioner" appears to be a private Apple library/tool,
reimplementing the functionality would be fairly trivial)
* It would be nice to have a command-line switch as well
* It would be nice if the stub executable could be reused by tools like
virtualenv without recompilation
----------
assignee: ronaldoussoren
components: Macintosh
keywords: easy
messages: 92210
nosy: ronaldoussoren
severity: normal
stage: needs patch
status: open
title: use different mechanism for pythonw on osx
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6834>
_______________________________________
From report at bugs.python.org Thu Sep 3 16:53:57 2009
From: report at bugs.python.org (Goetz Pfeiffer)
Date: Thu, 03 Sep 2009 14:53:57 +0000
Subject: [New-bugs-announce] [issue6835] doctest problem with decorated
function when decorator is defined in separate file
In-Reply-To: <1251989637.01.0.106852845631.issue6835@psf.upfronthosting.co.za>
Message-ID: <1251989637.01.0.106852845631.issue6835@psf.upfronthosting.co.za>
New submission from Goetz Pfeiffer <goetzpf at googlemail.com>:
As described in bug 1108, doctest skips tests on
functions that have been decorated with a decorator that
is defined in a separate file.
As described in bug 1108, the problem lies in
file "doctest.py", there in class "DocTestFinder",
there in method "_from_module"
There at about line 857 the following code makes problems:
elif inspect.isfunction(object):
return module.__dict__ is object.func_globals
The "func_globals" property of the function is used to find out if
the function was defined in the current module. This is not true
for a decorated function where the decorator is defined in another
module. Maybe _from_module() should use inspect.getmodulename() or
the "__module__" property of the function instead. "__module__"
is set correctly when the decorator uses functools.wraps().
The func_globals property is read-only, so there is no chance fix this
at the decorator definition.
----------
components: Library (Lib)
files: mytest.sh
messages: 92212
nosy: goetzpf
severity: normal
status: open
title: doctest problem with decorated function when decorator is defined in separate file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14826/mytest.sh
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6835>
_______________________________________
From report at bugs.python.org Fri Sep 4 13:54:28 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 04 Sep 2009 11:54:28 +0000
Subject: [New-bugs-announce] [issue6836] Mismatching use of memory APIs
In-Reply-To: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
Message-ID: <1252065268.74.0.319653064039.issue6836@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
There are instances in python where memory allocated using one api
(PyMem_*) is freed using the other (PyObject_*).
The provided patch (suggested for submission once we fix all instances)
illustrates this.
It is sufficient to fire up python_d and "import traceback" to trigger the
error.
----------
components: Interpreter Core
files: debugmalloc.patch
keywords: patch
messages: 92251
nosy: krisvale, lemburg, ncoghlan
severity: normal
status: open
title: Mismatching use of memory APIs
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14828/debugmalloc.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6836>
_______________________________________
From report at bugs.python.org Fri Sep 4 16:05:29 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 04 Sep 2009 14:05:29 +0000
Subject: [New-bugs-announce] [issue6837] Mark the compiler package as
deprecated
In-Reply-To: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
Message-ID: <1252073129.08.0.365906218945.issue6837@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
According to http://docs.python.org/library/compiler.html, the compiler
package is deprecated. However, importing the compiler package does not
emit a deprecation warning. It should, to convey this information to
people who are actually trying to use the package.
----------
components: Library (Lib)
messages: 92254
nosy: exarkun
severity: normal
status: open
title: Mark the compiler package as deprecated
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6837>
_______________________________________
From report at bugs.python.org Fri Sep 4 18:08:41 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 04 Sep 2009 16:08:41 +0000
Subject: [New-bugs-announce] [issue6838] httplib's _read_chunked extremely
slow for lots of chunks
In-Reply-To: <1252080521.37.0.722122314932.issue6838@psf.upfronthosting.co.za>
Message-ID: <1252080521.37.0.722122314932.issue6838@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
As the comment in this method suggests, accumulating the value by repeated string concatenation is slow. Appending to a list speeds this
up dramatically.
To quantify this, downloading a 110Mb file from Apache take:
~3s using Internet Explorer
2.2s using wget
30mins using the script in http://mail.python.org/pipermail/python-
dev/2009-September/091581.html
With the attached patch applied, this time drops to 2.3s.
----------
assignee: cjw296
files: httplib.patch.txt
keywords: easy
messages: 92257
nosy: cjw296
priority: high
severity: normal
status: open
title: httplib's _read_chunked extremely slow for lots of chunks
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14830/httplib.patch.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6838>
_______________________________________
From report at bugs.python.org Fri Sep 4 21:56:50 2009
From: report at bugs.python.org (Kim Kyung Don)
Date: Fri, 04 Sep 2009 19:56:50 +0000
Subject: [New-bugs-announce] [issue6839] zipfile can't extract file
Message-ID: <1252094210.03.0.111917894019.issue6839@psf.upfronthosting.co.za>
Changes by Kim Kyung Don <newercookie at gmail.com>:
----------
components: Library (Lib), Windows
files: test.zip
nosy: NewerCookie
severity: normal
status: open
title: zipfile can't extract file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14832/test.zip
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6839>
_______________________________________
From report at bugs.python.org Fri Sep 4 23:31:44 2009
From: report at bugs.python.org (Alexandru Munteanu)
Date: Fri, 04 Sep 2009 21:31:44 +0000
Subject: [New-bugs-announce] [issue6840] genericpath: _splitext returns
'.ext', '' instead of '', '.ext'
In-Reply-To: <1252099904.92.0.556344423163.issue6840@psf.upfronthosting.co.za>
Message-ID: <1252099904.92.0.556344423163.issue6840@psf.upfronthosting.co.za>
New submission from Alexandru Munteanu <io_fx at yahoo.fr>:
Having a '.ogg' filename, _splitext returns '.ogg' as base and empty
extension. Probably it should return empty base and '.ogg' extension.
Lib/genericpath.py:99 - Why "skip all leading dots" ?
I attach a possible patch (with tests).
----------
components: Library (Lib)
files: genericpath_splitext.patch
keywords: patch
messages: 92267
nosy: optimix
severity: normal
status: open
title: genericpath: _splitext returns '.ext', '' instead of '', '.ext'
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14834/genericpath_splitext.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6840>
_______________________________________
From report at bugs.python.org Sat Sep 5 10:54:07 2009
From: report at bugs.python.org (Cheese Lee)
Date: Sat, 05 Sep 2009 08:54:07 +0000
Subject: [New-bugs-announce] [issue6841] A typo in Doc/library/stdtypes.rst
In-Reply-To: <1252140847.01.0.360605550612.issue6841@psf.upfronthosting.co.za>
Message-ID: <1252140847.01.0.360605550612.issue6841@psf.upfronthosting.co.za>
New submission from Cheese Lee <cheeselee at 126.com>:
See the patch.
This typo is found in all branches.
----------
assignee: georg.brandl
components: Documentation
files: stdtypes-rst-cheese.patch
keywords: patch
messages: 92273
nosy: cheeselee, georg.brandl
severity: normal
status: open
title: A typo in Doc/library/stdtypes.rst
versions: Python 2.6
Added file: http://bugs.python.org/file14835/stdtypes-rst-cheese.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6841>
_______________________________________
From report at bugs.python.org Sat Sep 5 16:44:10 2009
From: report at bugs.python.org (John Van Praag)
Date: Sat, 05 Sep 2009 14:44:10 +0000
Subject: [New-bugs-announce] [issue6842] program run in interpreter,
fails at command line
In-Reply-To: <1252161850.13.0.448876854396.issue6842@psf.upfronthosting.co.za>
Message-ID: <1252161850.13.0.448876854396.issue6842@psf.upfronthosting.co.za>
New submission from John Van Praag <john at jvp247.com>:
My platform: Win XP.
Program fibo.py from the tutorial runs correctly in the interpreter.
When I run it from the command line I get the following error:
file "fibo.py" line 6
print(b, end=' ')
^
----------
components: Windows
files: fibo.py
messages: 92275
nosy: jvanpraag
severity: normal
status: open
title: program run in interpreter, fails at command line
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14836/fibo.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6842>
_______________________________________
From report at bugs.python.org Sat Sep 5 17:44:30 2009
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 05 Sep 2009 15:44:30 +0000
Subject: [New-bugs-announce] [issue6843] No documentation for the module
argument to warnings.filterwarnings
In-Reply-To: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>
Message-ID: <1252165470.79.0.703128610414.issue6843@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone <exarkun at divmod.com>:
None of the documentation seems to cover this parameter. The test suite
doesn't even seem to exercise it, either. What does it do? What kind
of values are expected to be passed for it?
----------
assignee: georg.brandl
components: Documentation
messages: 92280
nosy: exarkun, georg.brandl
severity: normal
status: open
title: No documentation for the module argument to warnings.filterwarnings
versions: Python 2.5, Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6843>
_______________________________________
From report at bugs.python.org Sat Sep 5 18:24:54 2009
From: report at bugs.python.org (Alan Isaac)
Date: Sat, 05 Sep 2009 16:24:54 +0000
Subject: [New-bugs-announce] [issue6844] BaseException DeprecationError
raises inappropriately
In-Reply-To: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
Message-ID: <1252167894.27.0.660137723145.issue6844@psf.upfronthosting.co.za>
New submission from Alan Isaac <alan.isaac at gmail.com>:
In Python 2.6 if I subclass Exception and intialize my instances with a
`message` attribute, I get a DeprecationError via BaseException.
Of course there is no problem in Py3, because adding a `message`
attribute to instances of a subclass is in fact **not** a problem and
will **not** be disallowed. I.e., the DeprecationError is raised
incorrectly in Python 2.6.
I am not sure how to raise a DeprecationError *only* in the correct
cases, but certainly the current behavior can be much improved. As a
crude example, if the `args` passed to BaseException has length 0, then
a flag could be set not to raise this DeprecationError. Even if not
perfect, this would be **much** better than the current behavior, since
it is common practice not to pass the subclass's initialization
arguments on to Exception.__init__.
This behavior can be expected to affect entire libraries and therefore
should be fixed. (Eg., it affects docutils.) I.e., "change the name of
your variable" is the wrong answer to this bug report.
----------
components: Interpreter Core
messages: 92281
nosy: aisaac
severity: normal
status: open
title: BaseException DeprecationError raises inappropriately
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6844>
_______________________________________
From report at bugs.python.org Sat Sep 5 20:00:45 2009
From: report at bugs.python.org (Pablo Mouzo)
Date: Sat, 05 Sep 2009 18:00:45 +0000
Subject: [New-bugs-announce] [issue6845] ftplib rest support for storbinary
In-Reply-To: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
Message-ID: <1252173645.44.0.329218283627.issue6845@psf.upfronthosting.co.za>
New submission from Pablo Mouzo <pablomouzo at gmail.com>:
FPT class doesn't support the rest parameter in storbinary method.
----------
components: None
messages: 92287
nosy: pablomouzo
severity: normal
status: open
title: ftplib rest support for storbinary
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6845>
_______________________________________
From report at bugs.python.org Sat Sep 5 20:51:56 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 05 Sep 2009 18:51:56 +0000
Subject: [New-bugs-announce] [issue6846] bytearray.pop() returns negative
ints
In-Reply-To: <1252176716.07.0.102651567862.issue6846@psf.upfronthosting.co.za>
Message-ID: <1252176716.07.0.102651567862.issue6846@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
This looks pretty bad:
>>> b = bytearray(b"\xff")
>>> b[0]
255
>>> b.pop()
-1
Fortunately it's easy too fix (attached).
----------
components: Interpreter Core
messages: 92292
nosy: hagen
severity: normal
status: open
title: bytearray.pop() returns negative ints
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6846>
_______________________________________
From report at bugs.python.org Sat Sep 5 20:59:54 2009
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 05 Sep 2009 18:59:54 +0000
Subject: [New-bugs-announce] [issue6847] Exception strings for bytearray say
"bytes"
In-Reply-To: <1252177194.86.0.89360876667.issue6847@psf.upfronthosting.co.za>
Message-ID: <1252177194.86.0.89360876667.issue6847@psf.upfronthosting.co.za>
New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:
Various exceptions thrown by bytearray objects talk of "bytes" instead
of "bytearray". Correction attached.
----------
components: Interpreter Core
files: bytearray_strings.patch
keywords: patch
messages: 92293
nosy: hagen
severity: normal
status: open
title: Exception strings for bytearray say "bytes"
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14843/bytearray_strings.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6847>
_______________________________________
From report at bugs.python.org Sun Sep 6 14:53:31 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Sep 2009 12:53:31 +0000
Subject: [New-bugs-announce] [issue6848] curses module build failure
(ncurses 5.7)
In-Reply-To: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>
Message-ID: <1252241611.96.0.24137998755.issue6848@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
There seems to be a problem building the curses module on systems with
ncurses 5.7. The following output was produced on OS X 10.6, on a trunk
build; I'm not sure whether this problem is Mac-specific (or 64-bit
specific).
building '_curses' extension
gcc -fno-strict-aliasing -g -Wall -Wstrict-prototypes -
I/Users/dickinsm/python/svn/trunk/Mac/Include -I. -I./Include -IInclude
-I/Users/dickinsm/python/svn/trunk -c
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c -o
build/temp.macosx-10.4-i386-2.7-
pydebug/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.o
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function
?PyCursesWindow_EchoChar?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:805: error:
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:812: warning:
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function
?PyCursesWindow_NoOutRefresh?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1230: error:
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1261: warning:
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function
?PyCursesWindow_Refresh?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1372: error:
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1402: warning:
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function
?PyCursesWindow_SubWin?:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1438: error:
dereferencing pointer to incomplete type
Here's a relevant excerpt from _cursesmodule.c (lines 804--811)
#ifdef WINDOW_HAS_FLAGS
if (self->win->_flags & _ISPAD)
return PyCursesCheckERR(pechochar(self->win, ch | attr),
"echochar");
else
#endif
return PyCursesCheckERR(wechochar(self->win, ch | attr),
"echochar");
Here self->win has type WINDOW; the problem is that as of ncurses 5.7, the internals of the WINDOW type (and much else besides) are deliberately hidden (by default) from users of the library; there's a
preprocessor constant NCURSES_OPAQUE that controls this.
So an obvious workaround is to set NCURSES_OPAQUE=0 somewhere in the
Python build process; however, that may be the wrong thing to do if the ncurses developers are planning to mess with the ncurses internals in
the near future (which would explain the NCURSES_OPAQUE business). I
don't know whether there's some alternative 'official' way to
distinguish between ncurses windows and pads.
----------
components: Build
messages: 92312
nosy: marketdickinson
severity: normal
status: open
title: curses module build failure (ncurses 5.7)
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6848>
_______________________________________
From report at bugs.python.org Sun Sep 6 19:21:47 2009
From: report at bugs.python.org (Michael Foord)
Date: Sun, 06 Sep 2009 17:21:47 +0000
Subject: [New-bugs-announce] [issue6849] Tutorial changes
In-Reply-To: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
Message-ID: <1252257707.68.0.937367410449.issue6849@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
There are a couple of minor changes I'd like to make to the tutorial.
Section 6.1 introduces the import * syntax without noting that it is bad
practise. I'd like to add the following text:
The import * form is generally considered to be bad practise as it makes
it hard to tell where the names you use in your code come from, *and*
you can accidentally overwrite names if you import something that is
already defined elsewhere. It can still be useful when working in the
console.
Section 6.4.1 uses Windows 95 and DOS 8+3 as the reason that importing
from packages doesn't automatically import all sub-packages. This is out
of date and not the most compelling reasoning anyway. I'd like to
replace that text with:
Perhaps this should go out to the filesystem, find which submodules are
present in the package, and import them all. This could take a long time
and importing sub-modules might have unwanted side-effects that should
only happen when the sub-module is explicitly imported.
----------
assignee: michael.foord
components: Documentation
keywords: easy
messages: 92324
nosy: michael.foord
severity: normal
status: open
title: Tutorial changes
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6849>
_______________________________________
From report at bugs.python.org Sun Sep 6 23:34:28 2009
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 06 Sep 2009 21:34:28 +0000
Subject: [New-bugs-announce] [issue6850] decimal.py: format_dict['type'] not
initialized
In-Reply-To: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
Message-ID: <1252272868.18.0.127348789237.issue6850@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi,
it looks like format_dict['type'] is not always initialized:
>>> from decimal import *
>>> format(Decimal("0.12345"), "a=-7.0")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.1/decimal.py", line 3611, in __format__
spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
File "/usr/lib/python3.1/decimal.py", line 5595, in
_parse_format_specifier
if format_dict['type'] in 'gG' or format_dict['type'] is None:
TypeError: 'in <string>' requires string as left operand, not NoneType
Inserting these two lines somewhere in _parse_format_specifier fixes the
problem. (float() uses 'g' as the default, but I got the impression that
decimal.py uses uppercase as the default.)
if format_dict['type'] is None:
format_dict['type'] = 'G'
----------
messages: 92337
nosy: skrah
severity: normal
status: open
title: decimal.py: format_dict['type'] not initialized
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6850>
_______________________________________
From report at bugs.python.org Mon Sep 7 02:00:59 2009
From: report at bugs.python.org (jweber)
Date: Mon, 07 Sep 2009 00:00:59 +0000
Subject: [New-bugs-announce] [issue6851] urllib.urlopen crashes in a thread
on Snow Leopard
In-Reply-To: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
Message-ID: <1252281659.27.0.994311757963.issue6851@psf.upfronthosting.co.za>
New submission from jweber <jacob at jacobweber.com>:
The following program works fine under Mac OS 10.5.x. But in 10.6, it
crashes Python, and displays Apple's crash reporter dialog. I've tried
it on Python 2.6 and 2.5, both the 64-bit and 32-bit versions.
The crash seems to happen any time urllib.urlopen is done in a thread.
The same thing happens if I do it in a BaseHTTPServer.HTTPServer, using
SocketServer.ThreadingMixIn.
#!/usr/bin/python
import threading, urllib
class MyThread (threading.Thread):
def run(self):
c = urllib.urlopen("http://www.google.com")
MyThread().start()
----------
assignee: ronaldoussoren
components: Macintosh
files: crash_log.txt
messages: 92340
nosy: jweber, ronaldoussoren
severity: normal
status: open
title: urllib.urlopen crashes in a thread on Snow Leopard
type: crash
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14849/crash_log.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6851>
_______________________________________
From report at bugs.python.org Mon Sep 7 06:32:19 2009
From: report at bugs.python.org (loveminix)
Date: Mon, 07 Sep 2009 04:32:19 +0000
Subject: [New-bugs-announce] [issue6852] Unicode IO not working in cgi applet
In-Reply-To: <1252297939.29.0.310972528107.issue6852@psf.upfronthosting.co.za>
Message-ID: <1252297939.29.0.310972528107.issue6852@psf.upfronthosting.co.za>
New submission from loveminix <loveminix at yahoo.com.cn>:
The following cgi applet does output Unicode string correctly in an
Ubuntu terminal, but when invoked from a web browser (IE or Firefox) by
a client, it doesn't output the Unicode string. Output stops at
"...<div><p>", right before the Unicode string "??".
#! /usr/bin/python3
# -*- coding: utf-8 -*-
print(
"""\
Content-type: text/html
"""
);
print(
"""\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head>
<body>\
"""
);
print("<div><p>");
print("??");
print("</p></div>");
print(
"""\
</body>
</html>\
"""
);
----------
components: Unicode
messages: 92341
nosy: loveminix
severity: normal
status: open
title: Unicode IO not working in cgi applet
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6852>
_______________________________________
From report at bugs.python.org Mon Sep 7 06:46:34 2009
From: report at bugs.python.org (lplatypus)
Date: Mon, 07 Sep 2009 04:46:34 +0000
Subject: [New-bugs-announce] [issue6853] system proxy not used for https (on
windows)
In-Reply-To: <1252298794.29.0.673935576663.issue6853@psf.upfronthosting.co.za>
Message-ID: <1252298794.29.0.673935576663.issue6853@psf.upfronthosting.co.za>
New submission from lplatypus <luke at deller.id.au>:
On Windows, the urllib2 module (renamed to urllib.request in python 3)
does not use the system web proxy for https URLs in the case where "Use
the same proxy for all protocols" is selected in the Internet Explorer
proxy settings.
Attached is a patch against urllib/request.py in python 3.1.1
----------
components: Library (Lib)
files: urllib-httpsproxy.patch
keywords: patch
messages: 92342
nosy: ldeller
severity: normal
status: open
title: system proxy not used for https (on windows)
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14850/urllib-httpsproxy.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6853>
_______________________________________
From report at bugs.python.org Mon Sep 7 07:13:34 2009
From: report at bugs.python.org (loveminix)
Date: Mon, 07 Sep 2009 05:13:34 +0000
Subject: [New-bugs-announce] [issue6854] UnicodeDecodeError when retrieving
binary data from cgi.FieldStorage()
In-Reply-To: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
Message-ID: <1252300414.57.0.638541093466.issue6854@psf.upfronthosting.co.za>
New submission from loveminix <loveminix at yahoo.com.cn>:
The following cgi applet uploads a binary file to the server. It gets a
"UnicodeDecodeError" inside cgi.FieldStorage(). The same code works in
python 2.6.
#! /usr/bin/python3
import os, cgi;
import cgitb; cgitb.enable();
pathInfo = os.environ.get("PATH_INFO", "");
serverName = os.environ.get("SERVER_NAME", "");
scriptName = os.environ.get("SCRIPT_NAME", "");
if pathInfo == "":
print(
"""\
Content-type: text/html
"""
);
print(
"""\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head>
<body>
<div>
<form action="http://{0}{1}/upload"
enctype="multipart/form-data" method="post">
<p>
<input type="file" name="file"><br>
<input type="submit" value="Upload">
</p>
</form>
</div>
</body>
</html>\
""".format(serverName, scriptName)
);
elif pathInfo == "/upload":
fieldStorage = cgi.FieldStorage();
fileItem = fieldStorage["file"];
if fileItem.filename != "":
file = open("/tmp/test.txt", mode="wb");
file.write(fileItem.file.read());
file.close();
print(
"""\
Content-type: text/html
"""
);
print(
"""\
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
</head>
<body>
<div>
<p>Success</p>
</div>
</body>
</html>\
"""
);
----------
components: Library (Lib)
messages: 92343
nosy: loveminix
severity: normal
status: open
title: UnicodeDecodeError when retrieving binary data from cgi.FieldStorage()
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6854>
_______________________________________
From report at bugs.python.org Mon Sep 7 08:29:47 2009
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 07 Sep 2009 06:29:47 +0000
Subject: [New-bugs-announce] [issue6855] ihooks support for relative imports
In-Reply-To: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za>
Message-ID: <1252304987.26.0.681394594908.issue6855@psf.upfronthosting.co.za>
New submission from Neil Schemenauer <nas-python at arctrix.com>:
ihooks in 2.6 does not support relative imports. The attached patch was
impired by Brett's "import in Python" code.
----------
assignee: brett.cannon
components: Library (Lib)
files: ihooks_relimport.txt
messages: 92345
nosy: brett.cannon, nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: ihooks support for relative imports
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14852/ihooks_relimport.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6855>
_______________________________________
From report at bugs.python.org Mon Sep 7 09:47:30 2009
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Sep 2009 07:47:30 +0000
Subject: [New-bugs-announce] [issue6856] allow settong uid and gid when
creating tar files
In-Reply-To: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
Message-ID: <1252309650.71.0.647505417979.issue6856@psf.upfronthosting.co.za>
New submission from Tarek Ziad? <ziade.tarek at gmail.com>:
I am proposing this feature for an issue we have in Distutils: being
able to set the uid/gid of files added in a tar archive using tarfile.
Here's what I am proposing:
- adding two methods to TarInfo: set_uid and set_gid, that are able to
take a user and group name *or* a uid and gid number
- adding in TarFile a new filter option to add() called include. If
given, it's a callable that receives the tarinfo object right before
it's added, so its uid/gid can be tweaked. This callable must return the
object. If it returns None, the object is not added to the tar file.
----------
components: Library (Lib)
messages: 92348
nosy: lars.gustaebel, tarek
severity: normal
status: open
title: allow settong uid and gid when creating tar files
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6856>
_______________________________________
From report at bugs.python.org Mon Sep 7 17:46:48 2009
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Sep 2009 15:46:48 +0000
Subject: [New-bugs-announce] [issue6857] float().__format__() default
alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
format(float("0.12345"), "7.0") -> ' 0.1'
The default alignment should be 'left-aligned'.
----------
messages: 92370
nosy: skrah
severity: normal
status: open
title: float().__format__() default alignment
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6857>
_______________________________________
From report at bugs.python.org Tue Sep 8 01:07:53 2009
From: report at bugs.python.org (gert cuykens)
Date: Mon, 07 Sep 2009 23:07:53 +0000
Subject: [New-bugs-announce] [issue6858] This is a python file,
apply syntax highlighting
In-Reply-To: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>
Message-ID: <1252364873.43.0.809885579905.issue6858@psf.upfronthosting.co.za>
New submission from gert cuykens <gert.cuykens at gmail.com>:
http://groups.google.be/group/comp.lang.python/browse_thread/thread/252fa1ccd0251977#
Menu option please, so I can highlight .wsgi .txt .xml files with python
code in it, does not matter if non python code gets wrongly highlighted too.
----------
components: IDLE
messages: 92395
nosy: gert
severity: normal
status: open
title: This is a python file, apply syntax highlighting
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6858>
_______________________________________
From report at bugs.python.org Tue Sep 8 01:58:08 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Sep 2009 23:58:08 +0000
Subject: [New-bugs-announce] [issue6859] stdint (eg. uint64_t) for ctypes
In-Reply-To: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za>
Message-ID: <1252367888.87.0.134332885078.issue6859@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
It would be nice to have (at least) some stdint.h types in ctypes:
- uint8_t, int8_t
- int16_t, uint16_t
- int32_t, uint32_t
- uint64_t, int64_t
Attached fle is a Python implementation of that.
stdint.h contains much more types, but I don't think that
(u)int_leastXX_t/(u)int_fastXX_t are used in public structures/functions.
Other interesting types/constants from stdint.h:
- intptr_t / uintptr_t
- (U)INT(8|16|32|64)_(MIN|MAX)
- PTRDIFF_MAX
----------
components: Extension Modules
files: stdint.py
messages: 92403
nosy: haypo
severity: normal
status: open
title: stdint (eg. uint64_t) for ctypes
type: feature request
Added file: http://bugs.python.org/file14858/stdint.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6859>
_______________________________________
From report at bugs.python.org Tue Sep 8 03:08:34 2009
From: report at bugs.python.org (=?utf-8?q?Patrick_N=C3=A4f?=)
Date: Tue, 08 Sep 2009 01:08:34 +0000
Subject: [New-bugs-announce] [issue6860] Inconsistent naming of custom
command in setup.py help output
In-Reply-To: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
Message-ID: <1252372114.27.0.565813299947.issue6860@psf.upfronthosting.co.za>
New submission from Patrick N?f <herzbube at herzbube.ch>:
The attached setup.py file defines a custom command named "test", which
is implemented in a class named "TestClass". Try to run both of the
following:
1) ./setup.py test -h
2) ./setup.py --help-commands
In case 1, Distutils will use the class name to print the help output.
In case 2, it will use the command name. This behaviour is inconsistent.
As a developer, if I want to get the output right in both cases, I am
forced to use the same name both for the command class and the command
name (a string in a dictionary).
I propose that Distutils always use the command name. Besides fixing the
inconsistency, this solution gives the freedom to choose class names
back to the developer.
I have tested this behaviour on Mac OS X 10.5, both with the
system-provided Python 2.5 and custom-installed versions of Python 2.6
and 3.1.
----------
assignee: tarek
components: Distutils
files: setup.py
messages: 92405
nosy: herzbube, tarek
severity: normal
status: open
title: Inconsistent naming of custom command in setup.py help output
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14859/setup.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6860>
_______________________________________
From report at bugs.python.org Tue Sep 8 03:56:16 2009
From: report at bugs.python.org (kai zhu)
Date: Tue, 08 Sep 2009 01:56:16 +0000
Subject: [New-bugs-announce] [issue6861] bytearray.__new__ doesn't subclass
In-Reply-To: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za>
Message-ID: <1252374976.15.0.672645211717.issue6861@psf.upfronthosting.co.za>
New submission from kai zhu <kaizhu256 at gmail.com>:
# a00.py
parent = bytearray # fails
# parent = bytes # works
# parent = str # works
class Foo(parent):
def __new__(klass, x): return parent.__new__(klass, x)
Foo(x = None)
$ python3.1 -c "import a00"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "a00.py", line 11, in <module>
Foo(x = None)
TypeError: 'x' is an invalid keyword argument for this function
lethe 3 /tmp/kaizhu/Python-3.1.1:
----------
components: Interpreter Core, Library (Lib)
messages: 92406
nosy: kaizhu
severity: normal
status: open
title: bytearray.__new__ doesn't subclass
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6861>
_______________________________________
From report at bugs.python.org Tue Sep 8 09:22:07 2009
From: report at bugs.python.org (john zeng)
Date: Tue, 08 Sep 2009 07:22:07 +0000
Subject: [New-bugs-announce] [issue6862] exec(),
locals() and local variable access
In-Reply-To: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za>
Message-ID: <1252394527.99.0.612337784106.issue6862@psf.upfronthosting.co.za>
New submission from john zeng <ooev at 163.com>:
Can you help me understand why variable `u' is not accessible after
exec()? Is this sort of a late binding issue?
def test(v1):
print(v1)
print("Before exec(): " + str(locals()))
exec(v1)
print("After exec(): " + str(locals()))
# This fails:
# print(u)
# This is workaround:
en = locals()['u']
print(en)
v1="u=4"
test(v1)
----------
components: Interpreter Core
messages: 92409
nosy: ooev
severity: normal
status: open
title: exec(), locals() and local variable access
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6862>
_______________________________________
From report at bugs.python.org Tue Sep 8 15:05:39 2009
From: report at bugs.python.org (=?utf-8?q?Pertti_Kellom=C3=A4ki?=)
Date: Tue, 08 Sep 2009 13:05:39 +0000
Subject: [New-bugs-announce] [issue6863] Wrong linker command if CXX set to
"ccache g++"
In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
Message-ID: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
New submission from Pertti Kellom?ki <pertti.kellomaki at tut.fi>:
If the compiler command in CXX contains more than one word, e.g. "ccache
g++", line 256 in distutils/unixccompiler.py only picks the first word
as the linker and discards the rest:
linker[i] = self.compiler_cxx[i]
On Ubuntu 9.04 the values of the variables are:
(Pdb) print linker
['gcc', '-pthread', '-shared', '-Wl,-O1', '-Wl,-Bsymbolic-functions']
(Pdb) print self.compiler_cxx
['ccache', 'g++']
(Pdb)
----------
assignee: tarek
components: Distutils
messages: 92414
nosy: perttikellomaki, tarek
severity: normal
status: open
title: Wrong linker command if CXX set to "ccache g++"
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6863>
_______________________________________
From report at bugs.python.org Tue Sep 8 15:37:25 2009
From: report at bugs.python.org (dpogg1)
Date: Tue, 08 Sep 2009 13:37:25 +0000
Subject: [New-bugs-announce] [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
New submission from dpogg1 <dan.poggi at gmail.com>:
IDLE 2.6.1 locks up on Mac OS 10.6 when running using Apple's built-in
version of Python (also 2.6.1) when creating a new buffer window or
attempting to run/debug an existing file.
----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 92415
nosy: dpogg1, ronaldoussoren
severity: normal
status: open
title: IDLE 2.6.1 locks up on Mac OS 10.6
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________
From report at bugs.python.org Tue Sep 8 21:10:42 2009
From: report at bugs.python.org (caglar10ur)
Date: Tue, 08 Sep 2009 19:10:42 +0000
Subject: [New-bugs-announce] [issue6865] Refcount error in pwd module
In-Reply-To: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za>
Message-ID: <1252437042.03.0.0223574441717.issue6865@psf.upfronthosting.co.za>
New submission from caglar10ur <caglar at pardus.org.tr>:
Fix refcounting problem which causes a segfault for following test code;
--------------------------------------------------------
#include <python2.5/Python.h>
int main(void)
{
int i;
for (i = 0; i < 1000; ++i)
{
Py_Initialize();
PyRun_SimpleString("import pwd\n");
Py_Finalize();
}
return 0;
}
--------------------------------------------------------
Reported-by: Onur K???k <onur at pardus.org.tr>
Signed-off-by: S.?a?lar Onur <caglar at pardus.org.tr>
----------
files: pwdmodule_refcount_fix.patch
keywords: patch
messages: 92425
nosy: caglar10ur
severity: normal
status: open
title: Refcount error in pwd module
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file14863/pwdmodule_refcount_fix.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6865>
_______________________________________
From report at bugs.python.org Tue Sep 8 22:03:50 2009
From: report at bugs.python.org (Mark Roddy)
Date: Tue, 08 Sep 2009 20:03:50 +0000
Subject: [New-bugs-announce] [issue6866] TestLoader.loadTestsFromName does
not use suiteClass attribute to create TestSuite instances
In-Reply-To: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>
Message-ID: <1252440230.46.0.994444389252.issue6866@psf.upfronthosting.co.za>
New submission from Mark Roddy <markroddy at gmail.com>:
The TestLoader class in unittest.py has an attribute 'suiteClass' that
is used to create instances of TestSuite object(s) in the process of
loading tests. If it is desired to subclass the TestSuite class then
consumers may set this attribute on a TestLoader object in order to
override what TestSuite class gets instantiated (a pythonic version of
the factory method pattern).
However, the loadTestsFromName() on the TestLoader class does not use
this attribute to create TestSuite instances, and instead has a hard
coded reference to the unittest.TestSuite class. This results in the
base class being created instead of a possibly desired subclass that
has been specified via this attribute.
Solution for this issue is to change the loadTestsFromName() method to
use the suiteClass attribute when creating TestSuite objects instead
using a reference to the TestSuite class. Included is a patch that
implements this behavior as well as two additional test for the
test_unittest.py file which expose this issue if run against an
unpatched version of unittest.
----------
components: Library (Lib)
files: unittest.patch
keywords: patch
messages: 92427
nosy: MarkRoddy
severity: normal
status: open
title: TestLoader.loadTestsFromName does not use suiteClass attribute to create TestSuite instances
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file14864/unittest.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6866>
_______________________________________
From report at bugs.python.org Wed Sep 9 03:58:00 2009
From: report at bugs.python.org (shaowei.cui)
Date: Wed, 09 Sep 2009 01:58:00 +0000
Subject: [New-bugs-announce] [issue6867] return value of epoll.register
In-Reply-To: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za>
Message-ID: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za>
New submission from shaowei.cui <shaovie at gmail.com>:
help(select.epoll) show 'register(fd[, eventmask]) -> bool', but it
return 'None' actually.
I view the source code of selectmodule.c that return None actually.
The function "pyepoll_internal_ctl(int epfd, int op, PyObject *pfd,
unsigned int events)"
----------
assignee: georg.brandl
components: Documentation
messages: 92440
nosy: georg.brandl, shaovie
severity: normal
status: open
title: return value of epoll.register
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6867>
_______________________________________
From report at bugs.python.org Wed Sep 9 04:13:11 2009
From: report at bugs.python.org (shaowei.cui)
Date: Wed, 09 Sep 2009 02:13:11 +0000
Subject: [New-bugs-announce] [issue6868] Check errno of epoll_ctrl
In-Reply-To: <1252462391.45.0.469283463386.issue6868@psf.upfronthosting.co.za>
Message-ID: <1252462391.45.0.469283463386.issue6868@psf.upfronthosting.co.za>
New submission from shaowei.cui <shaovie at gmail.com>:
in selectmodule.c, I found the code of epoll module
' result = epoll_ctl(epfd, op, fd, &ev);
if (errno == EBADF) {
/* fd already closed */
result = 0;
errno = 0;
}
'
'man epoll_ctl' show 'EBADF epfd or fd is not a valid file
descriptor.', assume I register an fd of 'open('xxx', O_RDONLY)', return
value will be -1, errno will be EBADF,
epoll not support 'file descriptors.' as i know, or i register an fd
was not be opened.
----------
components: Library (Lib)
messages: 92441
nosy: shaovie
severity: normal
status: open
title: Check errno of epoll_ctrl
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6868>
_______________________________________
From report at bugs.python.org Wed Sep 9 10:31:15 2009
From: report at bugs.python.org (Ilya)
Date: Wed, 09 Sep 2009 08:31:15 +0000
Subject: [New-bugs-announce] [issue6869] Embedded python crashed on 4th run,
if "ctypes" is used
In-Reply-To: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
Message-ID: <1252485075.59.0.965228056128.issue6869@psf.upfronthosting.co.za>
New submission from Ilya <kaplan.ilya at gmail.com>:
When embedding python from C, and importing "ctypes" module in embedded
script, it always crashes on Py_Finalize() on 4th cycle.
Tested with both PyRun_SimpleString(...) and PyRun_String(...).
Platform: Windows XP
IDE's: LabWindows/CVI 8.5 and Code::Blocks/gcc
Code:
--------------------------
#include <stdio.h>
#include <python.h>
int main()
{
int i;
for (i=0; i<10; i++)
{
printf("--- %d ---\n", i);
Py_Initialize();
PyRun_SimpleString("import ctypes");
Py_Finalize();
}
return 0;
}
--------------------------------
Output:
--------------------------------
--- 0 ---
--- 1 ---
--- 2 ---
--- 3 ---
Process returned -1073741819 (0xC0000005) execution time : 3.109 s
Press any key to continue.
--------------------------------
----------
assignee: theller
components: ctypes
messages: 92444
nosy: Warlock, theller
severity: normal
status: open
title: Embedded python crashed on 4th run, if "ctypes" is used
type: crash
versions: Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6869>
_______________________________________
From report at bugs.python.org Wed Sep 9 11:06:23 2009
From: report at bugs.python.org (Pravin Chavan)
Date: Wed, 09 Sep 2009 09:06:23 +0000
Subject: [New-bugs-announce] [issue6870] sybase module for python3.1
In-Reply-To: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za>
Message-ID: <1252487183.35.0.803150529972.issue6870@psf.upfronthosting.co.za>
New submission from Pravin Chavan <pravinpchavan at rediffmail.com>:
How can I use sybase module in python 3.1?
----------
components: Extension Modules
messages: 92445
nosy: pravinpchavan
severity: normal
status: open
title: sybase module for python3.1
type: feature request
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6870>
_______________________________________
From report at bugs.python.org Wed Sep 9 18:07:22 2009
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Sep 2009 16:07:22 +0000
Subject: [New-bugs-announce] [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
New submission from Stefan Krah <stefan-usenet at bytereef.org>:
Hi,
I've two more issues where format behavior should probably be identical:
1: (version 2.6 vs. 3.1):
Version 2.6:
>>> format(Decimal("NaN"), "+08.4")
'+0000NaN'
>>> format(float("NaN"), "+08.4")
'+00.0nan'
Version 3.1:
>>> format(Decimal("NaN"), "+08.4")
'+NaN '
>>> format(float("NaN"), "+08.4")
'+0000nan'
2: (float vs. decimal):
>>> format(float(123), "00")
'123.0'
>>> format(Decimal(123), "00")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.1/decimal.py", line 3611, in __format__
spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
File "/usr/lib/python3.1/decimal.py", line 5563, in
_parse_format_specifier
raise ValueError("Invalid format specifier: " + format_spec)
ValueError: Invalid format specifier: 00
----------
messages: 92453
nosy: marketdickinson, skrah
severity: normal
status: open
title: decimal.py: more format issues
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________
From report at bugs.python.org Wed Sep 9 21:03:28 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Sep 2009 19:03:28 +0000
Subject: [New-bugs-announce] [issue6872] Support system readline on OS X 10.6
In-Reply-To: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
Message-ID: <1252523008.71.0.00362112297351.issue6872@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
The readline library supplied in OS X 10.6 looks good enough to use in
Python. It would be nice to enable building with this library, to avoid
having to install GNU readline.
There's a curious off-by-one difference between Apple's readline (which,
as I understand it, is just libedit wrapped to look like libreadline)
and GNU readline: with 'n' history items, the valid indices for Apple's
readline are 0 through n-1; for GNU they're 1 through n.
I was able to get Python trunk + system readline working on OS X 10.6
using the attached patch (which obviously isn't suitable for applying,
since it breaks the build with a non-system readline). A side effect of
the patch is that readline.get_history_item and friends store the first
history entry with index 0 rather than 1:
Python 2.7a0 (trunk:74735M, Sep 9 2009, 19:40:25)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
[39474 refs]
>>> readline.get_history_item(0)
'import readline'
[39476 refs]
>>> readline.get_history_item(2)
'readline.get_history_item(2)'
[39476 refs]
Interestingly, the Apple-supplied Python also behaves this way:
Mark-Dickinsons-MacBook-Pro:trunk dickinsm$ python
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_history_item(0)
'import readline'
>>> readline.get_history_item(2)
'readline.get_history_item(2)'
If people think this is worth pursuing, I'll put together a proper
patch.
----------
assignee: ronaldoussoren
components: Build, Extension Modules, Macintosh
messages: 92457
nosy: marketdickinson, ronaldoussoren
severity: normal
status: open
title: Support system readline on OS X 10.6
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6872>
_______________________________________
From report at bugs.python.org Wed Sep 9 23:01:23 2009
From: report at bugs.python.org (Boya Sun)
Date: Wed, 09 Sep 2009 21:01:23 +0000
Subject: [New-bugs-announce] [issue6873] posix_lchown: possible overflow of
uid, gid
In-Reply-To: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
Message-ID: <1252530083.88.0.0590368551001.issue6873@psf.upfronthosting.co.za>
New submission from Boya Sun <boya.sun at case.edu>:
posix_lchown(PyObject *self, PyObject *args)
{
...
int uid, gid;
...
if (!PyArg_ParseTuple(args, "etii:lchown",
Py_FileSystemDefaultEncoding, &path,
&uid, &gid))
...
}
uid and gid could cause over flow. A similar bug is issue 5705.
Patch attached. Any comment is appreciated!
Boya
----------
files: patch.diff
keywords: patch
messages: 92465
nosy: boya
severity: normal
status: open
title: posix_lchown: possible overflow of uid, gid
Added file: http://bugs.python.org/file14869/patch.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6873>
_______________________________________
From report at bugs.python.org Thu Sep 10 08:46:24 2009
From: report at bugs.python.org (s7v7nislands)
Date: Thu, 10 Sep 2009 06:46:24 +0000
Subject: [New-bugs-announce] [issue6874] sequence method .count() and
.index() shoud be in immutable sequence method list.
In-Reply-To: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za>
Message-ID: <1252565184.5.0.887138864217.issue6874@psf.upfronthosting.co.za>
New submission from s7v7nislands <s7v7nislands at gmail.com>:
In document 6.6.4. Mutable Sequence Types says:
The following operations are defined on mutable sequence types:
s.count(x) return number of i?s for which s[i] == x
s.index(x[, i[, j]]) return smallest k such that s[k] == x and i <= k
< j (4)
here, s.count() and s.index() maybe should in immutable sequence types
operations list.
----------
assignee: georg.brandl
components: Documentation
messages: 92471
nosy: georg.brandl, s7v7nislands
severity: normal
status: open
title: sequence method .count() and .index() shoud be in immutable sequence method list.
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6874>
_______________________________________
From report at bugs.python.org Thu Sep 10 13:47:05 2009
From: report at bugs.python.org (Vincent Legoll)
Date: Thu, 10 Sep 2009 11:47:05 +0000
Subject: [New-bugs-announce] [issue6875] add os.close() suggestion to
mkstemp documentation
In-Reply-To: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
Message-ID: <1252583225.62.0.0154739326414.issue6875@psf.upfronthosting.co.za>
New submission from Vincent Legoll <vincent.legoll at gmail.com>:
As per the blog entry
http://www.logilab.org/blogentry/17873
I think the tempfile.mkstemp() documentation could be more helpful by
suggesting the use of os.close() appropriately.
If some native english speaker could give a review of the language I
used in the additional text, I'd be grateful.
----------
assignee: georg.brandl
components: Documentation
files: python-doc-mkstemp.patch
keywords: patch
messages: 92477
nosy: georg.brandl, vincele
severity: normal
status: open
title: add os.close() suggestion to mkstemp documentation
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file14870/python-doc-mkstemp.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6875>
_______________________________________
From report at bugs.python.org Thu Sep 10 13:49:04 2009
From: report at bugs.python.org (Stefan Schwarzburg)
Date: Thu, 10 Sep 2009 11:49:04 +0000
Subject: [New-bugs-announce] [issue6876] readline documentation example error
In-Reply-To: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za>
Message-ID: <1252583344.25.0.0380300575414.issue6876@psf.upfronthosting.co.za>
New submission from Stefan Schwarzburg <stefan.schwarzburg at googlemail.com>:
In the last example in the readline documentation
(http://docs.python.org/library/readline.html), the line
code.InteractiveConsole.__init__(self)
should be changed to
code.InteractiveConsole.__init__(self, locals, filename)
to work properly.
----------
assignee: georg.brandl
components: Documentation
messages: 92478
nosy: georg.brandl, schwarz
severity: normal
status: open
title: readline documentation example error
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/issue6876>
_______________________________________
From report at bugs.python.org Thu Sep 10 14:38:29 2009
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 10 Sep 2009 12:38:29 +0000
Subject: [New-bugs-announce] [issue6877] enable compilation of readline
module on Mac OS X 10.5 and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
New submission from Zvezdan Petkovic <zvezdan at zope.com>:
The attached patch enables compilation and use of the readline module on
Mac OS X 10.5 (Leopard) and 10.6 (Snow Leopard).
It utilizes the native editline library (used for emulation of the
readline library on Mac).
I used the patch for almost two years already with Python 2.4 and since
December 2008 with Python 2.6. The only difference is that Python 2.4
did not need the setup.py changes.
The patch is written in such a way that it does *not* affect the
compilation on systems that use GNU readline library (e.g., Linux).
However, I don't have access to any other system that uses editline
emulation of readline library besides Mac. I believe it should work the
same but some testing would be welcome if anyone is aware of such a
system (NetBSD?).
With the readline module compiled in, it is enough to put in .editrc
python:bind -v
and one gets a vi emulation in the python interactive interpreter.
You can also try it directly from the shell:
>>> import readline
>>> readline.parse_and_bind("bind -v")
>>> # use editing features to change the lines above to
>>> import rlcompleter
>>> readline.parse_and_bind("bind ^I rl_complete")
>>> # now TAB offers the completions
It would be nice if we could get this included into Python-2.6.3
release.
----------
components: Build
files: readline-trunk.patch
keywords: patch
messages: 92480
nosy: zvezdan
severity: normal
status: open
title: enable compilation of readline module on Mac OS X 10.5 and 10.6
type: compile error
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14871/readline-trunk.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________
From report at bugs.python.org Thu Sep 10 19:25:08 2009
From: report at bugs.python.org (SilentGhost)
Date: Thu, 10 Sep 2009 17:25:08 +0000
Subject: [New-bugs-announce] [issue6878] outdated docstring in
tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:
Doc string for tkinter/__init__.py Canvas.coords (line 2115 in
python3.1.1) reads: """Return a list of coordinates for the item given
in ARGS."""
actual code: return map(...etc...)
I actually don't know whether it's an outdated docstring, may be coords
should return a tuple.
----------
components: Tkinter
messages: 92495
nosy: SilentGhost
severity: normal
status: open
title: outdated docstring in tkinter.Canvas.coords
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________
From report at bugs.python.org Fri Sep 11 03:35:46 2009
From: report at bugs.python.org (Gene Ratzlaff)
Date: Fri, 11 Sep 2009 01:35:46 +0000
Subject: [New-bugs-announce] [issue6879] misstatement in example explanation
using raise
In-Reply-To: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>
Message-ID: <1252632946.18.0.482571861035.issue6879@psf.upfronthosting.co.za>
New submission from Gene Ratzlaff <generatz at gmail.com>:
v2.6.2 Python Tutorial
http://docs.python.org/tutorial/errors.html#raising-exceptions
Section 8. Errors and Exceptions
8.4. Raising Exceptions
It appears that in the example, the original may have been:
raise(NameError('HiThere')) and was then changed to
raise NameError('HiThere') but the explanation was not changed
accordingly. The current state and my suggested change are found below,
respectively:
Currently:
"""
>>> raise NameError('HiThere')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: HiThere
The first argument to raise names the exception to be raised. The
optional second argument specifies the exception?s argument.
Alternatively, the above could be written as
raise NameError('HiThere'). Either form works fine, but there seems to
be a growing stylistic preference for the latter.
"""
Suggest change to:
"""
>>> raise NameError('HiThere')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: HiThere
The first argument to raise names the exception to be raised. The
optional second argument specifies the exception?s argument.
Alternatively, the above could be written as
raise(NameError('HiThere')). Either form works fine, but there seems to
be a growing stylistic preference for the former.
"""
----------
assignee: georg.brandl
components: Documentation
messages: 92501
nosy: bluebloodpole, georg.brandl
severity: normal
status: open
title: misstatement in example explanation using raise
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6879>
_______________________________________
From report at bugs.python.org Fri Sep 11 03:46:15 2009
From: report at bugs.python.org (Gene Ratzlaff)
Date: Fri, 11 Sep 2009 01:46:15 +0000
Subject: [New-bugs-announce] [issue6880] class needs forward reference
In-Reply-To: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za>
Message-ID: <1252633575.43.0.606508097483.issue6880@psf.upfronthosting.co.za>
New submission from Gene Ratzlaff <generatz at gmail.com>:
http://docs.python.org/tutorial/errors.html#user-defined-exceptions
class mechanism used in 8.5 before classes are explained in chapter 9.
Suggest first use of word "class" be a forward link to "9. Classes":
http://docs.python.org/tutorial/classes.html#classes
----------
assignee: georg.brandl
components: Documentation
messages: 92502
nosy: bluebloodpole, georg.brandl
severity: normal
status: open
title: class needs forward reference
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6880>
_______________________________________
From report at bugs.python.org Fri Sep 11 11:24:44 2009
From: report at bugs.python.org (egreen)
Date: Fri, 11 Sep 2009 09:24:44 +0000
Subject: [New-bugs-announce] [issue6881] incorrect signature in doc for
PyByteArray_Resize
In-Reply-To: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>
Message-ID: <1252661084.46.0.992588228962.issue6881@psf.upfronthosting.co.za>
New submission from egreen <egreen at operamail.com>:
in Doc/c-api/bytearray.rst:
PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
should be:
int PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
as per Include/bytearrayobject.h
----------
assignee: georg.brandl
components: Documentation
messages: 92506
nosy: egreen, georg.brandl
severity: normal
status: open
title: incorrect signature in doc for PyByteArray_Resize
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6881>
_______________________________________
From report at bugs.python.org Fri Sep 11 11:59:13 2009
From: report at bugs.python.org (Dirk Haage)
Date: Fri, 11 Sep 2009 09:59:13 +0000
Subject: [New-bugs-announce] [issue6882] uuid creates zombies
In-Reply-To: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
Message-ID: <1252663153.38.0.979298945834.issue6882@psf.upfronthosting.co.za>
New submission from Dirk Haage <haage at net.in.tum.de>:
a simple import uuid will always result in a zombie sh process:
$ python3
Python 3.1.1 (r311:74480, Aug 19 2009, 16:23:08)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import uuid
>>>
13528 pts/5 Ss 0:01 \_ bash
18349 pts/5 S+ 0:00 | \_ python3
18352 pts/5 Z+ 0:00 | \_ [sh] <defunct>
confirmed on ubuntu and gentoo with various python3.0 - 3.1.1 builds
----------
messages: 92507
nosy: dhg
severity: normal
status: open
title: uuid creates zombies
versions: Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6882>
_______________________________________
From report at bugs.python.org Fri Sep 11 16:26:28 2009
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 11 Sep 2009 14:26:28 +0000
Subject: [New-bugs-announce] [issue6883]
OptionParser.allow_interspersed_args is undocumented
In-Reply-To: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
Message-ID: <60bb7ceb0909110726i738a484ck1b1ca3a31f6ea91b@mail.gmail.com>
New submission from Skip Montanaro <skip at pobox.com>:
The OptionParser.allow_interspersed_args attribute is undocumented in
the Sphinx documentation. (It is mentioned in the OptionParser
docstring.) By its name it appears to actually part of the official
API, so should at least be mentioned in the rst file.
----------
messages: 92510
nosy: skip.montanaro
severity: normal
status: open
title: OptionParser.allow_interspersed_args is undocumented
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6883>
_______________________________________
From report at bugs.python.org Fri Sep 11 16:28:28 2009
From: report at bugs.python.org (Chris Withers)
Date: Fri, 11 Sep 2009 14:28:28 +0000
Subject: [New-bugs-announce] [issue6884] Impossible to include file in sdist
that starts with 'build' on Win32
In-Reply-To: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
Message-ID: <1252679308.98.0.343140927716.issue6884@psf.upfronthosting.co.za>
New submission from Chris Withers <chris at simplistix.co.uk>:
With a simple setup.py:
from distutils.core import setup
setup(name='packagename')
And a MANIFEST.in containing:
include buildout.cfg
The result of a debug run of python setup.py sdist on Windows is:
Distribution.parse_config_files():
options (after parsing config files):
no commands known yet
options (after parsing command line):
option dict for 'sdist' command:
{}
running sdist
Distribution.get_command_obj(): creating 'sdist' command object
warning: sdist: missing required meta-data: version, url
warning: sdist: missing meta-data: either (author and author_email) or
(maintainer and maintainer_email) mus
t be supplied
checking if setup.py newer than MANIFEST
warning: sdist: standard file not found: should have one of README,
README.txt
reading manifest template 'MANIFEST.in'
include buildout.cfg
include_pattern: applying regex r'^buildout\.cfg$'
adding buildout.cfg
Distribution.get_command_obj(): creating 'build' command object
exclude_pattern: applying regex r'^build\.*'
removing buildout.cfg
...
The regex built is incorrect, although it is apparently correctly built
on other platforms...
----------
assignee: tarek
messages: 92511
nosy: cjw296, tarek
priority: normal
severity: normal
stage: test needed
status: open
title: Impossible to include file in sdist that starts with 'build' on Win32
type: behavior
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6884>
_______________________________________
From report at bugs.python.org Fri Sep 11 20:45:55 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 18:45:55 +0000
Subject: [New-bugs-announce] [issue6885] pdb documentation shows running as
script using "python" not "python3"
In-Reply-To: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>
Message-ID: <1252694755.95.0.997731708213.issue6885@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The library documentation page for pdb shows running pdb as a script
using the command
python -m pdb
Shouldn't that be
python3 -m pdb
?
----------
assignee: georg.brandl
components: Documentation
messages: 92515
nosy: MLModel, georg.brandl
severity: normal
status: open
title: pdb documentation shows running as script using "python" not "python3"
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6885>
_______________________________________
From report at bugs.python.org Fri Sep 11 21:01:57 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 19:01:57 +0000
Subject: [New-bugs-announce] [issue6886] cgi.py runs python, not python3
In-Reply-To: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za>
Message-ID: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The file cgi.py in the lib directory is an executable beginning with the
line:
#! /usr/local/bin/python
Shouldn't that be python3?
----------
components: Library (Lib)
messages: 92517
nosy: MLModel
severity: normal
status: open
title: cgi.py runs python, not python3
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6886>
_______________________________________
From report at bugs.python.org Fri Sep 11 21:04:36 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 19:04:36 +0000
Subject: [New-bugs-announce] [issue6887] executables in lib use /usr/bin/env
python, not python3
In-Reply-To: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>
Message-ID: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Some of the executables in lib begin with the line:
#! /usr/bin/env python
Shouldn't that be python3?
----------
components: Library (Lib)
messages: 92518
nosy: MLModel
severity: normal
status: open
title: executables in lib use /usr/bin/env python, not python3
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6887>
_______________________________________
From report at bugs.python.org Fri Sep 11 22:21:15 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 11 Sep 2009 20:21:15 +0000
Subject: [New-bugs-announce] [issue6888] pdb alias command with no arguments
is broken
In-Reply-To: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za>
Message-ID: <1252700475.39.0.749180351016.issue6888@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Typing just
alias
in pdb doesn't work. Because dict.keys() now returns a dict_keys object
instead of a list the line
keys.sort()
in Pdb.do_alias breaks because dict_keys doesn't have a sort method.
----------
components: Library (Lib)
messages: 92522
nosy: MLModel
severity: normal
status: open
title: pdb alias command with no arguments is broken
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6888>
_______________________________________
From report at bugs.python.org Fri Sep 11 22:34:10 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Sep 2009 20:34:10 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNjg4OV0gwqtQeXRob27igJlz?=
=?utf-8?q?_default_encoding_is_the_=E2=80=98ascii=E2=80=99_encoding=2E?=
=?utf-8?b?wrs=?=
In-Reply-To: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za>
Message-ID: <1252701250.82.0.768270765436.issue6889@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
In the Python ?Unicode HOWTO?, we still read the statement:
?For example, Python's default encoding is the 'ascii'
encoding.?
Here:
http://svn.python.org/view/python/branches/py3k/Doc/howto/unicode.rst?revision=72294&view=markup
----------
assignee: georg.brandl
components: Documentation
messages: 92523
nosy: flox, georg.brandl
severity: normal
status: open
title: ?Python?s default encoding is the ?ascii? encoding.?
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6889>
_______________________________________
From report at bugs.python.org Fri Sep 11 22:50:44 2009
From: report at bugs.python.org (Michael Foord)
Date: Fri, 11 Sep 2009 20:50:44 +0000
Subject: [New-bugs-announce] [issue6890] IOError has no __unicode__ method -
and loses information
In-Reply-To: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za>
Message-ID: <1252702244.44.0.0923996310102.issue6890@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
>>> try:
... open('flooble')
... except Exception as e:
... pass
...
[39343 refs]
>>> str(e)
"[Errno 2] No such file or directory: 'flooble'"
[39345 refs]
>>> unicode(e)
u"(2, 'No such file or directory')"
The Unicode representation of an IOError has no information about the
file or directory name. This is a regression from 2.5. Would be nice to
backport a fix to 2.6 if we can.
This bit docutils - and can happen as a side-effect of interpolating
into a Unicode string with %s. The filename information is lost from the
error report.
----------
components: IO
keywords: 26backport
messages: 92525
nosy: michael.foord
severity: normal
status: open
title: IOError has no __unicode__ method - and loses information
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6890>
_______________________________________
From report at bugs.python.org Fri Sep 11 23:15:50 2009
From: report at bugs.python.org (flox)
Date: Fri, 11 Sep 2009 21:15:50 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue6891=5D_small_typo_in_?=
=?utf-8?q?=C2=ABunicode=2Erst=C2=BB=3A_=C2=ABthe_Uniode_APIs_should_be_us?=
=?utf-8?q?ed=C2=BB_and_broken_URL?=
In-Reply-To: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>
Message-ID: <1252703750.59.0.33036975142.issue6891@psf.upfronthosting.co.za>
New submission from flox <laxyf at yahoo.fr>:
Found 2 typos:
- Uniode instead of Unicode
- Acknowledgements instead of Acknowledgments
And the following reference is broken (Jason Orendorff website):
http://www.jorendorff.com/articles/unicode/
The last version is dated 2007 on the wayback machine:
http://web.archive.org/web/*/www.jorendorff.com/articles/unicode/index.html
Relevant file is:
Doc/howto/unicode.rst
----------
assignee: georg.brandl
components: Documentation
messages: 92526
nosy: flox, georg.brandl
severity: normal
status: open
title: small typo in ?unicode.rst?: ?the Uniode APIs should be used? and broken URL
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6891>
_______________________________________
From report at bugs.python.org Sat Sep 12 04:13:00 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 12 Sep 2009 02:13:00 +0000
Subject: [New-bugs-announce] [issue6892] optparser example in optparse
documentation is broken
In-Reply-To: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za>
Message-ID: <1252721580.94.0.672952462459.issue6892@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The help example in the middle of the optparse library documentation is
broken. The code reads:
parser = OptionParser()
parser.add_option("-h", "--help", action="help"),
parser.add_option("-v", action="store_true", dest="verbose",
help="Be moderately verbose")
parser.add_option("--file", dest="filename",
help="Input file to read data from"),
The result of executing this code is:
optparse.OptionConflictError: option -h/--help: conflicting option
string(s): -h, --help
I see that the documentation says that normally help is added
automatically so you don't need to do it, but doing so shouldn't break
especially since the example shows doing it.
Also, the trailing commas on two of the lines are weird and should be
removed.
----------
assignee: georg.brandl
components: Documentation
messages: 92530
nosy: MLModel, georg.brandl
severity: normal
status: open
title: optparser example in optparse documentation is broken
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6892>
_______________________________________
From report at bugs.python.org Sat Sep 12 05:03:43 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 03:03:43 +0000
Subject: [New-bugs-announce] [issue6893] defaultdict example in py3 doc
should mention the new Counter class
In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
Message-ID: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
The 3rd example of defaultdict [1] shows how to use it to count the
letters of a string, but the new Counter class is a better tool for
doing that.
Possible solutions:
1) "Setting the default_factory to int makes the defaultdict useful for
counting (like a bag or multiset in other languages):" -> "Setting the
default_factory to int makes the defaultdict useful for basic counting
(see also the Counter class for more features):";
2) remove the example.
[1]:
http://docs.python.org/dev/py3k/library/collections.html#defaultdict-examples
----------
assignee: georg.brandl
components: Documentation
messages: 92534
nosy: ezio.melotti, georg.brandl, rhettinger
priority: low
severity: normal
status: open
title: defaultdict example in py3 doc should mention the new Counter class
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6893>
_______________________________________
From report at bugs.python.org Sat Sep 12 12:12:29 2009
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Barrois?=)
Date: Sat, 12 Sep 2009 10:12:29 +0000
Subject: [New-bugs-announce] [issue6894] urllib2 doesn't respect "no_proxy"
environment (python2.6.2)
In-Reply-To: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
Message-ID: <1252750349.64.0.743075601539.issue6894@psf.upfronthosting.co.za>
New submission from Rapha?l Barrois <xelnor_python at melix.net>:
I discovered recently that urllib2 doesn't respect the "no_proxy"
environment variable on linux (and on other platforms too, I think).
Here is an example of the problem :
- Set http_proxy and no_proxy environment variables (for instance
no_proxy="localhost")
proxy_handler = urllib2.ProxyHandler()
opener = urllib2.build_opener(proxy_handler)
urllib2.install_opener(opener)
and then open an "outside" url : everything is OK (urllib2 reads
correctly http_proxy), but for "localhost", it tries to open it
through the proxy.
You would expect urllib2 to understand no_proxy, all the more since
all the needed code is already available in urllib.
I have prepared a patch for urllib2 which does correct that bug.
I don't have other versions of python installed, so I couldn't check
that se bug is still present there.
----------
components: Library (Lib)
files: python2.6.2-urllib2-no_proxy.patch
keywords: patch
messages: 92538
nosy: xelnor
severity: normal
status: open
title: urllib2 doesn't respect "no_proxy" environment (python2.6.2)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14880/python2.6.2-urllib2-no_proxy.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6894>
_______________________________________
From report at bugs.python.org Sat Sep 12 16:26:58 2009
From: report at bugs.python.org (Santhosh Thottingal)
Date: Sat, 12 Sep 2009 14:26:58 +0000
Subject: [New-bugs-announce] [issue6895] locale._parse_localename fails when
localename does not contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
New submission from Santhosh Thottingal <santhosh.thottingal at gmail.com>:
locale._parse_localename fails when the locale name is in xx_YY format.
For example when the system locale is Malayalam(India), ml_IN we get
the following result
>>> locale._parse_localename("ml_IN")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/python311/lib/python3.1/locale.py", line 424, in
_parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: ml_IN
The expected result is ('ml_IN', None)
For Latin languages, locale.py assumes iso-8859-15 as the encoding type
if encoding type is not given in localename. In case
of other locales, None can be returned for encoding type.
Attached patch fixes this.
The result after applying patch to locale.py
>>> import locale
>>> locale._parse_localename("ml_IN")
('ml_IN', None)
----------
components: Library (Lib)
files: locale.py-parselocale-patch.diff
keywords: patch
messages: 92546
nosy: santhosh.thottingal
severity: normal
status: open
title: locale._parse_localename fails when localename does not contain encoding information
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14881/locale.py-parselocale-patch.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6895>
_______________________________________
From report at bugs.python.org Sat Sep 12 20:15:14 2009
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Sep 2009 18:15:14 +0000
Subject: [New-bugs-announce] [issue6896] Intermittent failures in
test_mailbox
In-Reply-To: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
Message-ID: <1252779314.23.0.231704147278.issue6896@psf.upfronthosting.co.za>
New submission from Ezio Melotti <ezio.melotti at gmail.com>:
While running test.regrtest, test_mailbox failed with the error:
test test_mailbox failed -- Traceback (most recent call last):
File "/home/wolf/py3k/Lib/test/test_mailbox.py", line 116, in
test_discard
self.assertEqual(len(self._box), 1)
AssertionError: 2 != 1
I ran the test again several times and got intermittent failures in
several different methods. Attached there's a file with the errors I
got.
During the first tests I was running test_mailbox after
test_zipimport, but then I was able to reproduce the failures running
test_mailbox alone.
I'm using Python 3.2a0 on Ubuntu 8.04.
----------
components: Tests
files: mailboxfailures.txt
messages: 92550
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: Intermittent failures in test_mailbox
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14882/mailboxfailures.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6896>
_______________________________________
From report at bugs.python.org Sat Sep 12 22:05:58 2009
From: report at bugs.python.org (geremy condra)
Date: Sat, 12 Sep 2009 20:05:58 +0000
Subject: [New-bugs-announce] [issue6897] imaplib fails during login
In-Reply-To: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za>
Message-ID: <1252785958.65.0.870328470051.issue6897@psf.upfronthosting.co.za>
New submission from geremy condra <debatem1 at gmail.com>:
Getting the following issue- this code:
#! /usr/bin/env python3
import getpass, imaplib
M = imaplib.IMAP4_SSL("imap.gmail.com")
M.login(<username>, <password>)
M.select()
typ, data = M.search(None, 'ALL')
for num in data[0].split():
typ, data = M.fetch(num, '(RFC822)')
print('Message %s\n%s\n' % (num, data[0][1]))
M.close()
M.logout()
taken almost verbatim from the documentation, produces this error:
Traceback (most recent call last):
File "./imaptest.py", line 6, in <module>
M.login(<username>, <password>)
File "/usr/lib/python3.0/imaplib.py", line 514, in login
typ, dat = self._simple_command('LOGIN', user, self._quote(password))
File "/usr/lib/python3.0/imaplib.py", line 1072, in _quote
arg = arg.replace(b'\\', b'\\\\')
TypeError: Can't convert 'bytes' object to str implicitly
username and password obviously redeacted.
Changing imaplib.py's _quote function to this:
def _quote(self, arg):
arg = arg.replace('\\', '\\\\')
arg = arg.replace('"', '\\"')
return '"' + arg + '"'
seems to resolve the issue.
----------
components: Library (Lib)
messages: 92552
nosy: debatem1
severity: normal
status: open
title: imaplib fails during login
versions: Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6897>
_______________________________________
From report at bugs.python.org Sun Sep 13 02:57:33 2009
From: report at bugs.python.org (vitvn)
Date: Sun, 13 Sep 2009 00:57:33 +0000
Subject: [New-bugs-announce] [issue6898] Unicode Error
In-Reply-To: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za>
Message-ID: <1252803453.94.0.767926898591.issue6898@psf.upfronthosting.co.za>
New submission from vitvn <caothucodon123 at gmail.com>:
>>>viet= "? ? ? ? ? ? ? ? ? ? ? "
>>>print(viet)
Traceback (most recent call last):
File "tiengviet.py", line 4, in <module>
print(viet)
File "I:\python\python.v3.1_portable\App\lib\encodings\cp1252.py",
line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0103' in
position 2: character maps to <undefined>
>Exit code: 1
how to fix it ?
----------
components: Unicode
messages: 92557
nosy: vitvn
severity: normal
status: open
title: Unicode Error
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6898>
_______________________________________
From report at bugs.python.org Sun Sep 13 10:50:41 2009
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 13 Sep 2009 08:50:41 +0000
Subject: [New-bugs-announce] [issue6899] Base.replace breaks tree
In-Reply-To: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
Message-ID: <1252831841.16.0.893335369907.issue6899@psf.upfronthosting.co.za>
New submission from Martin v. L?wis <martin at v.loewis.de>:
In Base.replace, the method checks that self.parent is not None -
however, it (unfortunately), breaks this very property itself if self is
new, or self in new.
In particular, some fixers return node from transform if they don't want
to do anything. In that case, self.parent gets set to None, even though
new (which is self) is still connected to the tree.
This patch
a) short-cuts the case that self is new
b) arranges to set parent of the new nodes only after clearing parent of
self
----------
components: 2to3 (2.x to 3.0 conversion tool)
files: python.patch
keywords: patch
messages: 92563
nosy: loewis
severity: normal
status: open
title: Base.replace breaks tree
Added file: http://bugs.python.org/file14883/python.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6899>
_______________________________________
From report at bugs.python.org Sun Sep 13 14:06:51 2009
From: report at bugs.python.org (Tom Seddon)
Date: Sun, 13 Sep 2009 12:06:51 +0000
Subject: [New-bugs-announce] [issue6900] Sub-optimal "Locate" button
behaviour in Windows CHM file
In-Reply-To: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
Message-ID: <1252843611.04.0.462538798156.issue6900@psf.upfronthosting.co.za>
New submission from Tom Seddon <bugs.python.org at tomseddon.plus.com>:
Behaviour of "Locate" in latest Windows CHM file for Python 2.6.2 is
sub-optimal.
I first spotted this with the optparse module, so this bug refers to
the optparse module. It looks as if this is a global problem, though.
First, ensure one has latest patched Python 2.6.2 CHM file.
Sample repro steps:
- Load Windows CHM file (observe fully collapsed contents tree);
- Select "Global Module Index" in contents tree (note availability of
"Locate" button);
- Click "O" link;
- Click "optparse" link.
Note that contents remains collapsed and "Locate" button is
unavailable. This makes navigating through the page a bit tiring. The
Find functionality in the CHM viewer isn't great.
Also try:
- Load Windows CHM file;
- Select Index;
- Enter "optparse" in keyword field;
- Select "optparse (module)" entry in index.
Note lack of Locate button. This looks to be the same thing as
selecting optparse from the module index (as it maybe is).
Also try:
- Load Windows CHM file;
- Expand "The Python Standard Library" folder in contents;
- ...expand "Generic Operating System Services" folder in contents;
- Click "optparse --- More powerful command line option parser" folder
in contents (note optparse page appears again, but this time you can
see the location line at the top, and Locate button remains available);
If one then collapses the "The Python Standard Library" folder, one is
then almost where one was in the first set of steps. This time, though,
one may click "Locate" to find the entry in the contents so that the
page is a bit easier to navigate.
Also try:
- Load Windows CHM file;
- Select "Global Module Index" from content;
- Click "C" link;
- Select "Carbon.AE" link (note availability of Locate button).
In this case, the Locate button IS available. Same goes for some other
sub-libraries -- e.g. compiler.ast and wsgiref.handlers -- but not all
-- e.g., xml.dom.
Expected behaviour:
When navigating to any module's doc page from its entry in the global
module index, or its entry in the index, or indeed by following any
link in the docs, it should be possible to click "Locate" to find it in
the contents tree. The document search facilities in the CHM viewer are
a bit lame, so having the contents tree at hand is very useful (I might
say essential -- but that could just be me).
(This was less of an issue in previous versions of the docs, because
the pages were split up into parts, so one could use Back once or twice
to get to the contents then click a link to go straight to the desired
section.)
Thanks.
----------
assignee: georg.brandl
components: Documentation
messages: 92565
nosy: georg.brandl, tom_seddon
severity: normal
status: open
title: Sub-optimal "Locate" button behaviour in Windows CHM file
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6900>
_______________________________________
From report at bugs.python.org Sun Sep 13 20:10:50 2009
From: report at bugs.python.org (Bernie H. Innocenti)
Date: Sun, 13 Sep 2009 18:10:50 +0000
Subject: [New-bugs-announce] [issue6901] Runaway programs often become
unresponsive to CTRL-C
In-Reply-To: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
Message-ID: <1252865450.5.0.145838694096.issue6901@psf.upfronthosting.co.za>
New submission from Bernie H. Innocenti <bernie at codewiz.org>:
On startup, the Python interpreter changes the default behavior
of SIGINT, which results in many Python programs to ignore the
keyboard interrupt exactly in the situations when users are
most likely to use it (i.e.: when the program becomes unresponsive).
Minimal testcase:
$ echo "void foo() { for(;;) {} }" >foo.c
$ gcc -shared -o foo.so foo.c
$ python -c 'import ctypes;ctypes.CDLL("./foo.so").foo()'
^C^C^C
^C
^C DAMN!
^C
This scenario mimics a Python program calling some blocking library
function. It can also happen with IO-bound functions if they loop
on read() and don't abort on short reads.
One might be tempted to say "this behavior of the Python intepreter
is by design" and suggest users to use CTRL-\ instead of CTRL-C.
However, this non-standard behavior is very annoying for users who
expect ^C to work on UNIX systems. In fact, no other compiled or
interpreted language I know of behaves this way, and Python should
not be the only exception.
While I see the usefulness of KeyboardInterrupt from the programmer
point of view, only a minority of programs actually need to trap
SIGINT and do something with it. Other language runtimes require
the programmer to manually trap SIGINT when needed. The Python
interpreter could maintain backwards compatibility by enabling
automatic SIGINT trapping when entering a "try" block that would
intercept KeyboardInterrupt.
----------
components: Interpreter Core
messages: 92576
nosy: bernie
severity: normal
status: open
title: Runaway programs often become unresponsive to CTRL-C
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6901>
_______________________________________
From report at bugs.python.org Mon Sep 14 01:36:44 2009
From: report at bugs.python.org (Eric Smith)
Date: Sun, 13 Sep 2009 23:36:44 +0000
Subject: [New-bugs-announce] [issue6902] Built-in types format incorrectly
with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
New submission from Eric Smith <eric at trueblade.com>:
Originally discussed in issue 6871. Even if an alignment of "<" is
specified, "=" is used if the padding character is "0".
>>> format(2, '0<20')
'00000000000000000002'
>>> format(2, '1<20')
'21111111111111111111'
This is a problem for at least float and integers.
This should probably be backported to 2.6 and 3.1, but I'll have to wait
and see how invasive the patch is.
----------
assignee: eric.smith
components: Interpreter Core
messages: 92586
nosy: eric.smith, marketdickinson, skrah
priority: normal
severity: normal
status: open
title: Built-in types format incorrectly with 0 padding.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6902>
_______________________________________
From report at bugs.python.org Mon Sep 14 02:18:25 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 14 Sep 2009 00:18:25 +0000
Subject: [New-bugs-announce] [issue6903] pdb - print in for iteration prints
None after printing
In-Reply-To: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za>
Message-ID: <1252887505.82.0.273261288247.issue6903@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Near the bottom of the library documentation for pdb there is an example
of a very useful alias:
alias pi for k in %1.__dict__.keys(): print("%1.",k,"=",%1.__dict__[k])
It turns out that doing print in a for loop in pdb results in None being
printed on a line after each print. For example:
(Pdb)
for n in range(3): print(n)
0
None
1
None
2
None
(Pdb)
Seems like a (minor) bug, but if not, the example should be removed or
replaced in the documentation.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 92588
nosy: MLModel, georg.brandl
severity: normal
status: open
title: pdb - print in for iteration prints None after printing
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6903>
_______________________________________
From report at bugs.python.org Mon Sep 14 02:37:25 2009
From: report at bugs.python.org (Thijs Triemstra)
Date: Mon, 14 Sep 2009 00:37:25 +0000
Subject: [New-bugs-announce] [issue6904] Broken URL for pyqt
In-Reply-To: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za>
Message-ID: <1252888645.97.0.828426454306.issue6904@psf.upfronthosting.co.za>
New submission from Thijs Triemstra <lists at collab.nl>:
using/mac.html#gui-programming-on-the-mac refers to
http://www.riverbankcomputing.co.uk/pyqt/ but this should be
http://www.riverbankcomputing.co.uk/software/pyqt
----------
assignee: georg.brandl
components: Documentation
messages: 92589
nosy: georg.brandl, thijs
severity: normal
status: open
title: Broken URL for pyqt
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6904>
_______________________________________
From report at bugs.python.org Mon Sep 14 05:54:51 2009
From: report at bugs.python.org (Yuv Gre)
Date: Mon, 14 Sep 2009 03:54:51 +0000
Subject: [New-bugs-announce] [issue6905] inspect.getargspec(print) fails
In-Reply-To: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>
Message-ID: <1252900491.43.0.484997315775.issue6905@psf.upfronthosting.co.za>
New submission from Yuv Gre <ubershmekel at gmail.com>:
>>> import inspect
>>> inspect.getargspec(print)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "F:\Python31\lib\inspect.py", line 787, in getargspec
getfullargspec(func)
File "F:\Python31\lib\inspect.py", line 814, in getfullargspec
raise TypeError('arg is not a Python function')
TypeError: arg is not a Python function
Is this normal or a known issue? I couldn't find an existing ticket.
----------
components: Library (Lib)
messages: 92591
nosy: ubershmekel
severity: normal
status: open
title: inspect.getargspec(print) fails
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6905>
_______________________________________
From report at bugs.python.org Mon Sep 14 11:29:26 2009
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Pasternak?=)
Date: Mon, 14 Sep 2009 09:29:26 +0000
Subject: [New-bugs-announce] [issue6906] Tkinter sets an unicode environment
variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
New submission from Micha? Pasternak <michal.dtz at gmail.com>:
Hi,
I was recently playing with txAmpoule & Twisted on win32. When Twisted spawns processess, the
environment is checked for unicode variables (and an exception is raised in case of). Then it
came to my attention, that importing Tkinter on win32 sets an environment variable, which value
is Unicode. Just have a look:
C:\>python
ActivePython 2.6.2.2 (ActiveState Software Inc.) based on
Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> import os
>>> os.environ['TK_LIBRARY']
u'C:\\Python26\\tcl\\tk8.5'
>>> ^Z
Why is it Unicode? Does it really have to be? Do we need that environment variable at all?
On Linux, it is different:
root at foo:~# 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.
>>> import Tkinter
>>> import os
>>> os.environ['TK_LIBRARY']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'TK_LIBRARY'
----------
components: Tkinter
messages: 92594
nosy: dotz
severity: normal
status: open
title: Tkinter sets an unicode environment variable on win32
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6906>
_______________________________________
From report at bugs.python.org Mon Sep 14 12:20:21 2009
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Sep 2009 10:20:21 +0000
Subject: [New-bugs-announce] [issue6907] xmlrpclib.make_connection() is not
thread safe
In-Reply-To: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>
Message-ID: <1252923621.29.0.493417133777.issue6907@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
The issue #6099 (part of #6267 superset) introduced a regression:
xmlrpclib.make_connection() is not thread safe. If xmlrpclib is used in two
threads, the socket is shared, but it doesn't any lock, and so data will be
mixed between the two requets. It becomes worse when I use SSL (pyopenssl
or m2crypto).
A possible solution is to use a different socket for each thread.
Note: I really love #6099, it was exactly what I needed :-)
----------
components: Extension Modules
messages: 92596
nosy: haypo
severity: normal
status: open
title: xmlrpclib.make_connection() is not thread safe
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6907>
_______________________________________
From report at bugs.python.org Mon Sep 14 16:47:19 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 14:47:19 +0000
Subject: [New-bugs-announce] [issue6908] Minor markup error in hashlib docs
In-Reply-To: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za>
Message-ID: <1252939639.99.0.306887711121.issue6908@psf.upfronthosting.co.za>
New submission from Robert Lehmann <lehmannro at gmail.com>:
The documentation for hashlib.hash.digest_size/block_size (notice the
hash) renders as documentation for hashlib.*_size, which does not exist.
Fixed by explicitly declaring membership; patch attached.
----------
assignee: georg.brandl
components: Documentation
files: hashlib-docs.patch
keywords: patch
messages: 92611
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Minor markup error in hashlib docs
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14887/hashlib-docs.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6908>
_______________________________________
From report at bugs.python.org Mon Sep 14 17:11:08 2009
From: report at bugs.python.org (jeff deifik)
Date: Mon, 14 Sep 2009 15:11:08 +0000
Subject: [New-bugs-announce] [issue6909] python 3.1 - filecmp.cmp exception
based on file name
In-Reply-To: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
Message-ID: <1252941068.66.0.745172113804.issue6909@psf.upfronthosting.co.za>
New submission from jeff deifik <jeff at jeffunit.com>:
I am calling filecmp.cmp on a two files, one of which has a name of
'./Julio_Iglesias-Un_Hombre_Solo-05-Qu\udce9_no_se_rompa_la_noche.mp3'
I get an exception from filecmp.cmp saying:
'ascii' codec can't encode character '\udce9' in position 37: ordinal
not in range(128)
I do not understand why filecmp.cmp cares what the encoding of the names
of the files are, as long as they are valid files. I would think
filecmp.cmp would only care about the content of the files.
When I give it pure ascii names, filecmp.cmp works file, however some of
my files have udce9 encoded names.
This is on a windows xp machine running cygwin (linux emulation).
I built and compiled python3.1 from source.
----------
messages: 92613
nosy: jdeifik
severity: normal
status: open
title: python 3.1 - filecmp.cmp exception based on file name
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6909>
_______________________________________
From report at bugs.python.org Mon Sep 14 17:19:41 2009
From: report at bugs.python.org (Mitchell Model)
Date: Mon, 14 Sep 2009 15:19:41 +0000
Subject: [New-bugs-announce] [issue6910] 1-char typo in language reference
doc of import
In-Reply-To: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za>
Message-ID: <1252941581.16.0.258073181914.issue6910@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Just before 6.11.1 of the Language Reference:
"Attempting to use it in class for function definitions"
should be "or" not "for"
----------
assignee: georg.brandl
components: Documentation
messages: 92614
nosy: MLModel, georg.brandl
severity: normal
status: open
title: 1-char typo in language reference doc of import
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6910>
_______________________________________
From report at bugs.python.org Mon Sep 14 17:26:59 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Mon, 14 Sep 2009 15:26:59 +0000
Subject: [New-bugs-announce] [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
New submission from Robert Lehmann <lehmannro at gmail.com>:
asynchat.async_chat grew a _collect_incoming and a _get_data method in
2.6. The constructor has been extended to conform to
asyncore.dispatcher's. This should be documented.
Apart from that, fifo and simple_producer have been deprecated, and
async_chat.ac_out_buffer was replaced by async_chat.incoming. These are
internals and were never documented.
A patch is attached.
----------
assignee: georg.brandl
components: Documentation
files: asynchat-docs.patch
keywords: patch
messages: 92616
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Document changes in asynchat
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14888/asynchat-docs.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6911>
_______________________________________
From report at bugs.python.org Mon Sep 14 19:57:28 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Sep 2009 17:57:28 +0000
Subject: [New-bugs-announce] [issue6912] Add 'with' block support to
Tools/Scripts/pindent.py
In-Reply-To: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za>
Message-ID: <1252951048.2.0.53684997295.issue6912@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
As reported by Miles Kaufmann on python-list,
Tools/Scripts/pindent.py
has not been updated to support 'with' blocks.
I suspect that it would be sufficient to add ",'with'" to
start = 'if', 'while', 'for', 'try', 'def', 'class'
Since there are no "next['def'/'class']" lines, I suspect none is needed
for 'with' either.
----------
components: Demos and Tools
messages: 92622
nosy: tjreedy
severity: normal
status: open
title: Add 'with' block support to Tools/Scripts/pindent.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6912>
_______________________________________
From report at bugs.python.org Tue Sep 15 05:31:21 2009
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 15 Sep 2009 03:31:21 +0000
Subject: [New-bugs-announce] [issue6913] Py_SetPythonHome incorrectly
documented py3.x (rev 74792)
In-Reply-To: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za>
Message-ID: <1252985481.54.0.861262446626.issue6913@psf.upfronthosting.co.za>
New submission from Campbell Barton <ideasman42 at gmail.com>:
Py_SetPythonHome takes a *wchar_t not a *char, this is obvious from
looking at the header,
However I tried using this function and couldn't get it working until I
made the home variable a static string.
when looking at the source this is obvious, but should be documented...
void
Py_SetPythonHome(wchar_t *home)
{
default_home = home;
}
----------
assignee: georg.brandl
components: Documentation
files: Py_SetPythonHome_doc.diff
keywords: patch
messages: 92640
nosy: georg.brandl, ideasman42
severity: normal
status: open
title: Py_SetPythonHome incorrectly documented py3.x (rev 74792)
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file14891/Py_SetPythonHome_doc.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6913>
_______________________________________
From report at bugs.python.org Tue Sep 15 06:07:18 2009
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 15 Sep 2009 04:07:18 +0000
Subject: [New-bugs-announce] [issue6914] Py_SetPythonHome,
undocumented behavoir
In-Reply-To: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za>
Message-ID: <1252987638.62.0.948007118413.issue6914@psf.upfronthosting.co.za>
New submission from Campbell Barton <ideasman42 at gmail.com>:
Py_SetPythonHome holds a pointer to the variable passed, this is not
documented so passing a variable on the stack will not work as expected
unless its static or allocated.
----------
components: None
messages: 92642
nosy: ideasman42
severity: normal
status: open
title: Py_SetPythonHome, undocumented behavoir
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6914>
_______________________________________
From report at bugs.python.org Tue Sep 15 06:43:16 2009
From: report at bugs.python.org (Ryan Kelly)
Date: Tue, 15 Sep 2009 04:43:16 +0000
Subject: [New-bugs-announce] [issue6915] os.listdir inconsistenly releases
the GIL on win32
In-Reply-To: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za>
Message-ID: <1252989796.76.0.19947250091.issue6915@psf.upfronthosting.co.za>
New submission from Ryan Kelly <ryan at rfk.id.au>:
The win32 implementation of os.listdir() releases the GIL around calls
to FindNextFile, but not around calls to FindFirstFile. Attached is a
simple patch to consistently release the GIL around any such calls.
----------
components: None
files: listdir_gil.patch
keywords: patch
messages: 92643
nosy: rfk
severity: normal
status: open
title: os.listdir inconsistenly releases the GIL on win32
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14892/listdir_gil.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6915>
_______________________________________
From report at bugs.python.org Tue Sep 15 07:55:56 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Tue, 15 Sep 2009 05:55:56 +0000
Subject: [New-bugs-announce] [issue6916] Remove deprecated items from
asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
New submission from Robert Lehmann <lehmannro at gmail.com>:
The patches in issue1736190 deprecated fifo and simple_producers. These
are safe for removal in Python 3.0.
I attached a patch purging fifo and simple_producers from py3k code and
tests. The docs are mostly trivial as well but also touched by my other
issue issue6911 so I'd like that to settle first, otherwise this might
result in a merge conflict.
----------
assignee: georg.brandl
components: Documentation, Library (Lib), Tests
files: asynchat.patch
keywords: patch
messages: 92645
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Remove deprecated items from asynchat
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14894/asynchat.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6916>
_______________________________________
From report at bugs.python.org Tue Sep 15 17:25:24 2009
From: report at bugs.python.org (dauerbaustelle)
Date: Tue, 15 Sep 2009 15:25:24 +0000
Subject: [New-bugs-announce] [issue6917] ".et_folder" instead of
"get_folder" in mailbox documentation
In-Reply-To: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za>
Message-ID: <1253028324.31.0.745530277772.issue6917@psf.upfronthosting.co.za>
New submission from dauerbaustelle <jonas at lophus.org>:
In the mailbox documentation,
http://docs.python.org/library/mailbox.html#mailbox.Maildir..et_folder
should be named "get_folder" instead of ".et_folder".
----------
assignee: georg.brandl
components: Documentation
messages: 92647
nosy: dauerbaustelle, georg.brandl
severity: normal
status: open
title: ".et_folder" instead of "get_folder" in mailbox documentation
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/issue6917>
_______________________________________
From report at bugs.python.org Tue Sep 15 23:21:19 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Sep 2009 21:21:19 +0000
Subject: [New-bugs-announce] [issue6918] ctypes compilation error on
SnowLeopard
In-Reply-To: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
Message-ID: <1253049679.4.0.0329687109313.issue6918@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
When I compile the trunk on MacOS X 10.6 I get a compile (or rather
link) error in ctypes:
ld: in build/temp.macosx-10.5-fat3-
2.7/Users/ronald/Projects/python/python-trunk-
clean/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o, unsupported
encoding in FDE for architecture ppc
This makes it impossible to build a univeral binary Python framework on
OSX 10.6.
I don't think I'm running into the same issue with PyObjC, it that works
I'll port PyObjC's version of ppc-darwin to the version of libffi that's
used by ctypes.
----------
assignee: ronaldoussoren
components: Macintosh, ctypes
messages: 92656
nosy: ronaldoussoren
priority: release blocker
severity: normal
status: open
title: ctypes compilation error on SnowLeopard
type: compile error
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6918>
_______________________________________
From report at bugs.python.org Wed Sep 16 06:19:14 2009
From: report at bugs.python.org (Henri Hein)
Date: Wed, 16 Sep 2009 04:19:14 +0000
Subject: [New-bugs-announce] [issue6919] Link CRT Statically
In-Reply-To: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
Message-ID: <1253074754.07.0.562289184303.issue6919@psf.upfronthosting.co.za>
New submission from Henri Hein <henri at granitetower.net>:
Suggestion: Link the CRT statically into Python26.dll/PythonNN.dll
and compiled .PYD files, at least when using the Microsoft compiler.
There has been a number of bugs related to the msvcrt.dll,
msvcr90.dll, etc. Many of these would go away if the CRT was
statically linked into PythonNN.dll.
The advantages of dynamically linking the CRT are not clear. The
binaries are decreased a bit in size, but this is countered by having
to redistribute the CRT DLL.
Switching to static linking is a little more work than just flipping a
switch, as you have to compensate for some of the initialization work
the DLL does, but it is both doable and worth doing.
----------
assignee: tarek
components: Distutils, Windows
messages: 92663
nosy: hankdane, tarek
severity: normal
status: open
title: Link CRT Statically
versions: Python 2.4, Python 2.5, Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6919>
_______________________________________
From report at bugs.python.org Wed Sep 16 10:30:53 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 16 Sep 2009 08:30:53 +0000
Subject: [New-bugs-announce] [issue6920] IDLE 3 crashes on Ctrl+Space with
"'utf8' codec can't decode bytes in position 0-1"
In-Reply-To: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za>
Message-ID: <1253089853.74.0.832814951262.issue6920@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:
on Ubuntu 8.04 -
I downloaded the sources, then:
./configure --prefix=$HOME
make && make install
in ~/bin/idle3 when I press Ctrl+Space (according to the "Edit" menu,
should show completions) idle crashes with the following traceback:
Traceback (most recent call last):
File "/homes/yinon/bin/idle3", line 5, in <module>
main()
File "/homes/yinon/lib/python3.1/idlelib/PyShell.py", line 1420, in main
root.mainloop()
File "/homes/yinon/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: 92667
nosy: Yinon
severity: normal
status: open
title: IDLE 3 crashes on Ctrl+Space with "'utf8' codec can't decode bytes in position 0-1"
type: crash
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6920>
_______________________________________
From report at bugs.python.org Wed Sep 16 17:38:43 2009
From: report at bugs.python.org (David Hanney)
Date: Wed, 16 Sep 2009 15:38:43 +0000
Subject: [New-bugs-announce] [issue6921] recursion wierdness ... related to
variable scoping?
In-Reply-To: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>
Message-ID: <1253115523.94.0.244610185437.issue6921@psf.upfronthosting.co.za>
New submission from David Hanney <spam2008 at nney.com>:
I was playing about with ideas behind b-plus-trees
and found i python bug
the important bit of code is:
for p, k in enumerate(self.keys):
self.ptrs[p].dump(indent+1, kmin=lk, kmax=k)
print sindent + "(" + str(k) + ")"
lk = k
#
# python bug?
#
show_python_bug = len(sys.argv)>1
if show_python_bug:
#
# why not this?
assert p == len(self.keys)-1
else:
#
# why do I need this instead?
p = len(self.keys)-1
i'm expecting k to still be in scope and equal len(self.keys)-1
sometimes it is and sometimes it isn't (depending on recursion depth)
you can try it for yourselves as I attach the full program:
./btree.py
runs fine
./btree.py show_python_bug
eventually breaks like this:
Traceback (most recent call last):
File "./btree.py", line 235, in <module>
page.dump()
File "./btree.py", line 223, in dump
self.ptrs[p+1].dump(indent+1, kmin=lk)
File "./btree.py", line 223, in dump
self.ptrs[p+1].dump(indent+1, kmin=lk)
File "./btree.py", line 223, in dump
self.ptrs[p+1].dump(indent+1, kmin=lk)
File "./btree.py", line 217, in dump
assert p == len(self.keys)-1
UnboundLocalError: local variable 'p' referenced before assignment
... despite executing that code many times successfully before this
happens ... strange!
I hope you can figure it out and that this report proves helpful.
----------
components: Interpreter Core
files: btree.py
messages: 92691
nosy: mrdiskodave
severity: normal
status: open
title: recursion wierdness ... related to variable scoping?
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14897/btree.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6921>
_______________________________________
From report at bugs.python.org Wed Sep 16 19:38:16 2009
From: report at bugs.python.org (Alex)
Date: Wed, 16 Sep 2009 17:38:16 +0000
Subject: [New-bugs-announce] [issue6922] Interpreter hangs up while trying
to decode invalid utf32 stream.
In-Reply-To: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
Message-ID: <1253122696.64.0.653718788287.issue6922@psf.upfronthosting.co.za>
New submission from Alex <malicious.wizard at gmail.com>:
*** Prerequisites:
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
*** Description:
'utf_32_le' and 'utf_32_be' codecs are overconsuming memory when input
data are damaged and kwarg 'errors' to str.decode is other than 'strict'.
*** Steps:
1. Start interpreter
2. Type:
'\x01'.decode('utf_32_le', 'replace')
or
'\x01'.decode('utf32', 'ignore')
or
('something'.encode('utf32') + '\x00').decode('utf32', 'ignore')
3. Execute
*** Notes:
1. seems like any stream raising UnicodeDecodeError in 'strict' mode
causes hangup in 'ignore' or 'replace'.
*** Expected result:
1. AssertionError on "assert errors == 'strict'" raised, just as
bz2_codec does, if utf32 cannot be partially decoded at all.
2. Behaviour that 'utf8' and 'utf16' implement for such cases.
*** Received result:
1. Interpreter hangs, uses up to 100% of CPU kernel and starts to
consume RAM.
2. Grows large enough to consume all the RAM it could get (takes up to
several minutes on my machine).
3. Produces following traceback:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python26\lib\encodings\utf_32_be.py", line 11, in decode
return codecs.utf_32_be_decode(input, errors, True)
MemoryError
4. Sometimes traceback is printed, but text "MemoryError" is not, just
leaving blank line in the place.
----------
components: Interpreter Core, Library (Lib), Unicode, Windows
messages: 92704
nosy: mwizard
severity: normal
status: open
title: Interpreter hangs up while trying to decode invalid utf32 stream.
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6922>
_______________________________________
From report at bugs.python.org Wed Sep 16 22:03:14 2009
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 16 Sep 2009 20:03:14 +0000
Subject: [New-bugs-announce] [issue6923] Need pthread_atfork-like
functionality in CPython
In-Reply-To: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za>
Message-ID: <1253131394.22.0.862355202249.issue6923@psf.upfronthosting.co.za>
New submission from Thomas Wouters <thomas at python.org>:
In order to properly handle multiple threads and fork()-calls from C code
(rather than os.fork()), Python should provide pthread_atfork()-like
functionality: a function to call before a fork, to acquire any locks
that need to be acquired, and a pair of functions to call after the fork,
in the parent and the child, to release or re-allocate locks. The
acquisitions should be re-entrant and should not require an existing
threadstate. Also see <http://bugs.python.org/issue1590864>.
----------
assignee: twouters
components: Interpreter Core
messages: 92715
nosy: twouters
priority: low
severity: normal
stage: needs patch
status: open
title: Need pthread_atfork-like functionality in CPython
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6923>
_______________________________________
From report at bugs.python.org Wed Sep 16 23:53:20 2009
From: report at bugs.python.org (Emmanuel Bengio)
Date: Wed, 16 Sep 2009 21:53:20 +0000
Subject: [New-bugs-announce] [issue6924] struct.unpack weird behavior with
"bi" (byte then integer)
In-Reply-To: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za>
Message-ID: <1253138000.08.0.430539071948.issue6924@psf.upfronthosting.co.za>
New submission from Emmanuel Bengio <bengioe at gmail.com>:
Using the following command in Python 2.6.1:
>>> struct.unpack("BI","12345")
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
struct.unpack("BI","12345")
error: unpack requires a string argument of length 8
I get this error message. What confused me was that doing
>>> struct.unpack("IB","12345")
(875770417, 53)
Worked just fine.
I have found out that this only happens using the native byte
order("@"), which is the default.
For Example:
>>> struct.unpack("!BI","12345")
(49, 842216501)
Works, and all other variants, =, <, > (native standard,little endian,
and small endian) also do.
I haven't found anything about that in the documentation.
Also, the requested 3 other bytes arent event used:
>>> struct.unpack("I","abcd")
(1684234849,) # see the big number starting with 16
>>> ord("x")
120
>>> struct.unpack("BI","xabcd") # we get the error
Traceback (most recent call last):
File "<pyshell#7>", line 1, in <module>
struct.unpack("BI","xabcd")
error: unpack requires a string argument of length 8
>>> struct.unpack("BI","xabcdefg")
(120, 1734763876) # not the same here
>>> struct.unpack("BI","xabcabcd")
(120, 1684234849) # same here
>>> struct.unpack("BI","x___abcd")
(120, 1684234849) # same again
----------
components: Library (Lib)
messages: 92724
nosy: Manux
severity: normal
status: open
title: struct.unpack weird behavior with "bi" (byte then integer)
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6924>
_______________________________________
From report at bugs.python.org Thu Sep 17 01:18:06 2009
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 Sep 2009 23:18:06 +0000
Subject: [New-bugs-announce] [issue6926] socket module missing IPPROTO_IPV6,
IPPROTO_IPV4
In-Reply-To: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
Message-ID: <1253143086.64.0.131724035197.issue6926@psf.upfronthosting.co.za>
New submission from Jason R. Coombs <jaraco at jaraco.com>:
It appears that somewhere between Python 2.5 and Python 2.6, some socket
constants were lost in Windows builds.
Python 2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket; socket.IPPROTO_IPV6
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'IPPROTO_IPV6'
Confirmed this problem on 32-bit builds and Python 3.1.1 also. I suspect
the compiler upgrade influenced this behavior.
Let me know if I can help track down the issue.
----------
components: IO, Windows
messages: 92730
nosy: jaraco
severity: normal
status: open
title: socket module missing IPPROTO_IPV6, IPPROTO_IPV4
type: behavior
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6926>
_______________________________________
From report at bugs.python.org Thu Sep 17 00:54:42 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 22:54:42 +0000
Subject: [New-bugs-announce] [issue6925] Doc for locals and vars
In-Reply-To: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
Message-ID: <1253141682.71.0.279725067044.issue6925@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
Doc for locals(): after correctly stating
"Update and return a dictionary representing the current local symbol table.
Note
The contents of this dictionary should not be modified; changes may not
affect the values of local variables used by the interpreter."
current doc goes on to say
"Free variables are returned by locals() when it is called in a function
block. Modifications of free variables may not affect the values used by
the interpreter. Free variables are not returned in class blocks."
As best I can understand this, it is wrong and should be removed. Free
variables within a function block are global/nonlocal names and by my
experimentation with 3.1, (including lambda expressions) are NOT
returned by locals(). If it means something else, it needs a rewrite.
The doc for var() starts "Without arguments, return a dictionary
corresponding to the current local symbol table." I suggest augmenting
this with 'update and ' (to match locals doc) and '(same as locals())'
to make that fact clear (as it is with help(vars)), even though removing
the 'Free variables' stuff will help the latter clearer also. The result
would be
Without arguments, update and return a dictionary corresponding to the
current local symbol table (same as locals()).
----------
messages: 92728
nosy: tjreedy
severity: normal
status: open
title: Doc for locals and vars
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6925>
_______________________________________
From report at bugs.python.org Thu Sep 17 01:33:33 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 23:33:33 +0000
Subject: [New-bugs-announce] [issue6927] Metaclass doc (Ref 3.3.3) errors
In-Reply-To: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za>
Message-ID: <1253144013.13.0.919755909189.issue6927@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
3.3.3. Customizing class creation
3.1/3.2 docs say
"If the metaclass keyword argument is based with the bases, it is used."
(new version for 3.x) I presume 'based' was meant to be 'passed'.
However, with that correction, would it really be correct?
I presume the metaclass compatibility issue discussed in #1294232 for
2.x is still relevant for 3.x.
The next line
"Otherwise, if there is at least one base class, its metaclass is used."
(same as for 2.x docs) does not say which 'its' is used if there is more
than one. See paragraph above and #1294232.
I do not know the actual rule well enough to improve the neglected
suggestion in the referenced issue.
----------
assignee: georg.brandl
components: Documentation
messages: 92732
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Metaclass doc (Ref 3.3.3) errors
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6927>
_______________________________________
From report at bugs.python.org Thu Sep 17 01:53:49 2009
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Sep 2009 23:53:49 +0000
Subject: [New-bugs-announce] [issue6928] Doc: Class statements and metaclass
= xxx
In-Reply-To: <1253145229.65.0.267557560742.issue6928@psf.upfronthosting.co.za>
Message-ID: <1253145229.65.0.267557560742.issue6928@psf.upfronthosting.co.za>
New submission from Terry J. Reedy <tjreedy at udel.edu>:
For 3.x, I think 7.7 Class Definitions should mention the metaclass
keyword arg and cross-reference 3.3.3 Customizing class creation. Since
it is no longer a 'special' name, let alone a 'special method name',
there is no reason to know to look for it under that heading (I didn't
until I looked for 'metaclass' in the index, which I had to know to look
for, of course).
A possible sentence after "The class name is bound to this class object
in the original local namespace." (and before discussion of @classdeco)
"To modify this process, add 'metaclass = xxx' to the list of bases and
see CCustomizing class creation." with the last three words being a blue
link to 3.3.3.
2.x would need something a bit different, or just less ;-)
----------
assignee: georg.brandl
components: Documentation
messages: 92733
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Doc: Class statements and metaclass = xxx
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6928>
_______________________________________
From report at bugs.python.org Thu Sep 17 11:51:52 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Thu, 17 Sep 2009 09:51:52 +0000
Subject: [New-bugs-announce] [issue6929] Confusion between "write" method of
rowiobase and rawfileio
In-Reply-To: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
Message-ID: <1253181112.74.0.584886320915.issue6929@psf.upfronthosting.co.za>
New submission from Pascal Chambon <chambon.pascal at gmail.com>:
It seems the properties of the write methods of these two classes are
mixed up in documentation. I've checked the sources, and actually it
seems the behviour is inverted :
rawiobase streams, which can be pipes or other limited streams, may
write less than len(b) bytes in one operation, and return ; whereas
rawfileio instances, which write on disk, will never fail writing all
the data unless the disk is full (resulting in IOError). It's rawiobase
which does one system call, not rawiofile which will try again until all
is written, isn't it ?
RawIoBase
write(b)
Write the given bytes or bytearray object, b, to the underlying raw
stream and return the number of bytes written (never less than len(b),
since if the write fails an IOError will be raised).
A BlockingIOError is raised if the buffer is full, and the
underlying raw stream cannot accept more data at the moment.
RawFileIO :
write(b)
Write the bytes or bytearray object, b, to the file, and return the
number actually written. Only one system call is made, so it is possible
that only some of the data is written.
----------
assignee: georg.brandl
components: Documentation
messages: 92751
nosy: georg.brandl, pakal
severity: normal
status: open
title: Confusion between "write" method of rowiobase and rawfileio
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6929>
_______________________________________
From report at bugs.python.org Thu Sep 17 16:09:59 2009
From: report at bugs.python.org (Jon Foster)
Date: Thu, 17 Sep 2009 14:09:59 +0000
Subject: [New-bugs-announce] [issue6930] [PATCH] PyUnicode_DecodeUTF16 docs
wrong (byteorder param)
In-Reply-To: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za>
Message-ID: <1253196599.56.0.25129944047.issue6930@psf.upfronthosting.co.za>
New submission from Jon Foster <jon.foster at cabot.co.uk>:
The documentation for the C API function PyUnicode_DecodeUTF16() does
not match the code.
If *byteorder is 1 or -1, the documentation says that the function looks
for a BOM. It doesn't. This patch updates the documentation to match
the code.
(Also, I just realised that the docs for PyUnicode_DecodeUTF32() have
the exact same bug. That is NOT fixed by this patch).
This patch also clarifies the PyUnicode_EncodeUTF16() docs.
----------
assignee: georg.brandl
components: Documentation
files: unicodedocs.patch
keywords: patch
messages: 92764
nosy: JonFoster, georg.brandl
severity: normal
status: open
title: [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14910/unicodedocs.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6930>
_______________________________________
From report at bugs.python.org Thu Sep 17 16:54:58 2009
From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=)
Date: Thu, 17 Sep 2009 14:54:58 +0000
Subject: [New-bugs-announce] [issue6931] awful performance in difflib: ndiff
and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
New submission from Hei?ar Rafn Har?arson <heidar.rafn at hrolfsskali.net>:
Relatively small set of lines with differences in most lines can destroy
the performance of difflib.HtmlDiff.make_table and difflib.ndiff.
I am using it like this:
...
htmldiffer = HtmlDiff()
return htmldiffer.make_table(src_lines, dst_lines,
fromdesc="file1",
todesc="file2",
context=True)
I have written the src_lines and dst_lins to files and tried this with
the Tools/scripts/diff.py wrapper with same results when using the
switches -m or -n.
The performance is fine when using difflib.unified_diff or switch -u on
diff.py
Attached are files that show this clearly.
left200.txt,right200.txt - 200 lines of text - duration 11 seconds.
left500.txt,right500.txt - 500 lines of text - duration 2min 58 sec
left1000.txt,right1000.txt - 1000 lines of text - duration 29min 4sec
tested on Intel dualcore T2500 2GHz with 2 GB of memory, python 2.5.2 on
Ubuntu. Same problom on python 2.6 on Fedora-11
For reference, the kdiff3 utility performs beautifully on these files.
----------
components: Library (Lib)
files: python.difflib.bug.tgz
messages: 92768
nosy: heidar.rafn
severity: normal
status: open
title: awful performance in difflib: ndiff and HtmlDiff
type: performance
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14911/python.difflib.bug.tgz
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________
From report at bugs.python.org Thu Sep 17 17:55:57 2009
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 17 Sep 2009 15:55:57 +0000
Subject: [New-bugs-announce] [issue6932] Open shelves fail when Python exits
In-Reply-To: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za>
Message-ID: <1253202957.58.0.0745460877644.issue6932@psf.upfronthosting.co.za>
New submission from Robert Lehmann <lehmannro at gmail.com>:
I'm reopening issue5483 by Zhigang Wang (zhigang) as a separate bug.
Shelves that are still open when Python terminates will try to sync. If
writeback=True, this pickles cached items.
In this example, serialization of Test() re-imports __main__, which is
already gc'd, and raises:
Exception cPickle.PicklingError: Can't pickle <class '__main__.Test'>:
it's not the same object as __main__.Test" in <bound method
Shelf.__del__ of {'a': <__main__.Test object at 0x...>}>
The error is ignored (due to Python already tearing down) but all cached
modifications are lost.
The promise "[t]he __del__() method of the Shelf class calls the close()
method, so the programmer generally need not do this explicitly" is not
true with writeback enabled.
I'm unsure if this error can be fixed (probably with atexit/weakref, but
that's more trouble than gain). I attached a patch to the docs simply
warning the user of this issue (+ documenting Shelf.close, + removing
above quote).
----------
assignee: georg.brandl
components: Documentation, Extension Modules, Library (Lib)
files: example.py
messages: 92773
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Open shelves fail when Python exits
type: behavior
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14912/example.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6932>
_______________________________________
From report at bugs.python.org Thu Sep 17 19:01:01 2009
From: report at bugs.python.org (Moray Grieve)
Date: Thu, 17 Sep 2009 17:01:01 +0000
Subject: [New-bugs-announce] [issue6933] Threading issue with Tkinter
Frame.insert
In-Reply-To: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za>
Message-ID: <1253206861.41.0.487118668051.issue6933@psf.upfronthosting.co.za>
New submission from Moray Grieve <mbg at progress.com>:
The attached file has an example where a Tk GUI is launched as a
seperate thread - this all works fine in Python 2.5, but in Python 2.6
the thread hangs.
The issue seems to be in the line;
self.messageBoxDetails.insert(INSERT, "Hello world")
Comment this line out, or use an empty string rather than "Hello World",
and the example works in both Python 2.5 and Python 2.6. I have not been
able to seen any related issues to this and wonder if this is a bug in
the 2.6 Tkinter module.
----------
components: Tkinter
files: example.py
messages: 92781
nosy: moraygrieve
severity: normal
status: open
title: Threading issue with Tkinter Frame.insert
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14914/example.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6933>
_______________________________________
From report at bugs.python.org Thu Sep 17 19:46:16 2009
From: report at bugs.python.org (Svetoslav Agafonkin)
Date: Thu, 17 Sep 2009 17:46:16 +0000
Subject: [New-bugs-announce] [issue6934] postflight.framework script (from
the Mac OS X .dmg installer) fails (patch given).
In-Reply-To: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
Message-ID: <1253209576.62.0.0516947954037.issue6934@psf.upfronthosting.co.za>
New submission from Svetoslav Agafonkin <svetlyo at gmail.com>:
postflight.framework fails during installation:
. . .
Sep 17 17:36:53 mcfro Installer[1613]: run postflight script for Python
Framework
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 9:
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]:
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 14:
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 19:
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]:
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: /Volumes/Python
3.1.1/Python.mpkg/Contents/Packages/PythonFramework-
3.1.pkg/Contents/Resources/postflight: line 24:
/Library/Frameworks/Python.framework/Versions/3.1/bin/python: No such
file or directory
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]:
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]: chown: admin:
Invalid argument
Sep 17 17:36:53 mcfro runner[1633]: postflight[1660]:
The first problem is that in
/Library/Frameworks/Python.framework/Versions/3.1/bin there is no
executable 'python' anymore - there is 'python3.1', etc.
Also chown at the end should set the group to 'admin', not the owner.
I've attached a patch that fixes these issues. (the problem with chown
is also present in the installer for 2.6.x ).
----------
assignee: ronaldoussoren
components: Installation, Macintosh
files: postflight.framework.patch
keywords: patch
messages: 92786
nosy: ronaldoussoren, slavi
severity: normal
status: open
title: postflight.framework script (from the Mac OS X .dmg installer) fails (patch given).
type: compile error
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14916/postflight.framework.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6934>
_______________________________________
From report at bugs.python.org Fri Sep 18 01:30:26 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 17 Sep 2009 23:30:26 +0000
Subject: [New-bugs-announce] [issue6935] Version updates needed in tutorial
In-Reply-To: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za>
Message-ID: <1253230226.4.0.664611927484.issue6935@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Footnote 1 in section 2.1 of the Tutorial and the example of invoking
Python in the middle of the page need their version number upped to 3.2
in both the invocation and the greeting.
The same page in the 3.1 documentation should have the 'a' removed from
the version number in the greeting.
----------
assignee: georg.brandl
components: Documentation
messages: 92798
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Version updates needed in tutorial
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6935>
_______________________________________
From report at bugs.python.org Fri Sep 18 01:38:03 2009
From: report at bugs.python.org (Mitchell Model)
Date: Thu, 17 Sep 2009 23:38:03 +0000
Subject: [New-bugs-announce] [issue6936] Import needed to quit Python?
In-Reply-To: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za>
Message-ID: <1253230683.38.0.361310672505.issue6936@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
Section 2.1 of the tutorial describes using import sys; sys.exit() if ^D
or ^Z doesn't work. However, both quit() and exit() work, as documented
in the "Built-in Constants" section of the Library documentation. Is
there something about them that should be hidden from the ordinary user
that they aren't used in place of the import sys; sys.exit()
combination? Seems easier to just say use "quit() or exit()", especially
for beginners following the tutorial who won't know what import or sys
are, or even the dot notation.
----------
assignee: georg.brandl
components: Documentation
messages: 92799
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Import needed to quit Python?
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6936>
_______________________________________
From report at bugs.python.org Fri Sep 18 07:10:44 2009
From: report at bugs.python.org (aaditya sood)
Date: Fri, 18 Sep 2009 05:10:44 +0000
Subject: [New-bugs-announce] [issue6937] multiprocessing lock on OS X Snow
Leopard dumps core
In-Reply-To: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
Message-ID: <1253250644.35.0.00627250039523.issue6937@psf.upfronthosting.co.za>
New submission from aaditya sood <aaditya at sood.net.in>:
On a Snow Leopard system, doing this core dumps:
import multiprocessing
lck1=multiprocessing.Lock()
with lck1:
print "foo"
The stack trace:
Process: Python [23100]
Path:
/System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
Identifier: Python
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: zsh [23055]
Date/Time: 2009-09-18 10:39:39.611 +0530
OS Version: Mac OS X 10.6.1 (10B504)
Report Version: 6
Interval Since Last Report: 83665 sec
Crashes Since Last Report: 60
Per-App Crashes Since Last Report: 55
Anonymous UUID: 38A426BB-52F7-4282-9FA8-A04AB8896489
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000043000000ee
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 org.python.python 0x0000000100096763
_PyArg_ParseTupleAndKeywords_SizeT + 113
1 _multiprocessing.so 0x00000001001fa8c8 sem_timedwait_save
+ 456
2 org.python.python 0x00000001000891df PyEval_EvalFrameEx
+ 15001
3 org.python.python 0x000000010008accf PyEval_EvalCodeEx
+ 1803
4 org.python.python 0x000000010008ad62 PyEval_EvalCode + 54
5 org.python.python 0x00000001000a265a Py_CompileString + 78
6 org.python.python 0x00000001000a44dd
PyRun_InteractiveOneFlags + 503
7 org.python.python 0x00000001000a4615
PyRun_InteractiveLoopFlags + 206
8 org.python.python 0x00000001000a4685
PyRun_AnyFileExFlags + 76
9 org.python.python 0x00000001000b0286 Py_Main + 2718
10 org.python.python.app 0x0000000100000e6c start + 52
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000004300000043 rbx: 0x0000000100200150 rcx:
0x00000001001fc7f0 rdx: 0x00000001001fb632
rdi: 0x00000001001af050 rsi: 0x000000010003af24 rbp:
0x00007fff5fbfeff0 rsp: 0x00007fff5fbfef20
r8: 0x0000000100096748 r9: 0x00007fff5fbff030 r10:
0x0000000000000000 r11: 0x00000001001fa86f
r12: 0x00000000ffffffff r13: 0x00000001004a4570 r14:
0x0000000100123100 r15: 0x00000001001af050
rip: 0x0000000100096763 rfl: 0x0000000000010206 cr2: 0x00000043000000ee
Binary Images:
0x100000000 - 0x100000ff7 org.python.python.app 2.6 (2.6)
<BDEA119D-4E2F-D97F-07BA-713A6E5A39B6>
/System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
0x100004000 - 0x100114ff7 org.python.python 2.6.1 (2.6.1)
<01EBD0D4-F181-045F-C7A8-B7B3C5D4204F>
/System/Library/Frameworks/Python.framework/Versions/2.6/Python
0x1001f0000 - 0x1001f2ff7 readline.so ??? (???)
<A8236667-A9DD-30A5-6DE8-201C6EF317E6>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/readline.so
0x1001f8000 - 0x1001fbfff _multiprocessing.so ??? (???)
<03672D74-6FAC-DE76-6DE6-604A8C0F2D50>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_multiprocessing.so
0x1004b0000 - 0x1004ccff7 libedit.2.dylib ??? (???)
<F9D005F8-74B8-CC05-2697-24C49E0CC1EF> /usr/lib/libedit.2.dylib
0x1004db000 - 0x1004e0fff itertools.so ??? (???)
<06555874-952C-C770-64BF-6BC7A2455E10>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so
0x1004e8000 - 0x1004f4fff cPickle.so ??? (???)
<98485D07-D504-74EB-B3A1-4EBB2474BFE6>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cPickle.so
0x1004fa000 - 0x1004fbfff cStringIO.so ??? (???)
<7600C3A8-3C81-2A81-0853-B09107768C8C>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/cStringIO.so
0x100540000 - 0x100541ff7 _functools.so ??? (???)
<1CE29F88-7B8C-77CC-5E87-555BA210EA8F>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_functools.so
0x100545000 - 0x100546ff7 time.so ??? (???)
<5F01F2A9-8557-5DF1-F006-44E02E0469CE>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/time.so
0x10054d000 - 0x100550fff _collections.so ??? (???)
<1F62A5C3-6E6C-D0BC-7AA6-DA2820B5F157>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_collections.so
0x100556000 - 0x100559fff operator.so ??? (???)
<68C1CC88-5F73-E029-5C19-685BBADACFA6>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/operator.so
0x10055f000 - 0x10055ffff _weakref.so ??? (???)
<89F1302D-1CFA-7B9B-4425-70DA55215DAE>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_weakref.so
0x1005a3000 - 0x1005a7ff7 _struct.so ??? (???)
<33156F5C-52ED-7167-533F-15D6CF031150>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/_struct.so
0x1005ad000 - 0x1005affe7 binascii.so ??? (???)
<5CFE3DC5-850B-B79D-8310-0BA97540841A>
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/binascii.so
0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???)
<B633F790-4DDB-53CD-7ACF-2A3682BCEA9F> /usr/lib/dyld
0x7fff80bc1000 - 0x7fff80bc5ff7 libmathCommon.A.dylib ??? (???)
<95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
0x7fff829f4000 - 0x7fff82bb2ff7 libSystem.B.dylib ??? (???)
<66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib
0x7fff85ebc000 - 0x7fff85efbfef libncurses.5.4.dylib ??? (???)
<E0A07C12-D912-DF26-9E38-C50484D96EB0> /usr/lib/libncurses.5.4.dylib
0x7fff85f81000 - 0x7fff85f92fef libz.1.dylib ??? (???)
<3A7A4C48-A4C8-A78A-8B87-C0DDF6601AC8> /usr/lib/libz.1.dylib
0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???)
<66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib
Model: MacBookPro2,2, BootROM MBP22.00A5.B07, 2 processors, Intel Core 2
Duo, 2.16 GHz, 2 GB, SMC 1.12f5
Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87),
Atheros 5416: 2.0.19.4
Bluetooth: Version 2.2.1f7, 2 service, 1 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS541612J9SA00, 111.79 GB
Parallel ATA Device: HL-DT-ST DVDRW GWA4080MA
USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8501, 0xfd400000
USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8240, 0x5d200000
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.),
0x021a, 0x1d200000
USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8205,
0x7d100000
----------
components: Extension Modules
messages: 92801
nosy: aaditya
severity: normal
status: open
title: multiprocessing lock on OS X Snow Leopard dumps core
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6937>
_______________________________________
From report at bugs.python.org Fri Sep 18 11:06:51 2009
From: report at bugs.python.org (Zhang Cong)
Date: Fri, 18 Sep 2009 09:06:51 +0000
Subject: [New-bugs-announce] [issue6938] Incorrect multiprocessing log
string in managers.py (python 2.6.2)
In-Reply-To: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za>
Message-ID: <1253264811.0.0.554251286265.issue6938@psf.upfronthosting.co.za>
New submission from Zhang Cong <ftofficer at ftofficer.com>:
There is an issue in multiprocessing library.
Lib/multiprocessing/managers.py:413:
util.debug('disposing of obj with id %d', ident)
It is '%d' here, but 'ident' is a string.
This always cause an TypeError from logging module once enable logging
on multiprocessing.
Patch is attached to fix the issue.
----------
components: Library (Lib)
files: managers-log.patch
keywords: patch
messages: 92818
nosy: ftofficer
severity: normal
status: open
title: Incorrect multiprocessing log string in managers.py (python 2.6.2)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14922/managers-log.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6938>
_______________________________________
From report at bugs.python.org Fri Sep 18 15:21:53 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 18 Sep 2009 13:21:53 +0000
Subject: [New-bugs-announce] [issue6939] shadows around the io truncate()
semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
New submission from Pascal Chambon <chambon.pascal at gmail.com>:
Hello
I'm having trouble around the behaviour of the io module's truncate
methods, in py3k. If I remember well, under unix and older versions of
Python (with other file types), truncate never move the fiel pointer
(and had to fake that behaviour under windows as well, by
saving/restoring the file pointer).
However, I see nothing in the documentation of the io module about that,
and studying the _fileio.c code, it seems that now the file pointer is
(under all OS) moved to the truncation point, and left there.
Maybe it requires discusions on the mailing list, but personally I think
that the common unix behaviour (letting the file pointer untouched)
would be better for everyone, and that the doc should claim it.
Also, additional notes about the behaviour of that truncation (reminding
people that on some OS, the padding is zero-filled, on others it's
not...) would be great.
Current doc of io in py3k :
http://docs.python.org/py3k/library/io.html#io.IOBase.truncate
truncate(size=None)
Truncate the file to at most size bytes. size defaults to the
current file position, as returned by tell().
Cheers
Pascal
----------
components: IO
messages: 92822
nosy: pakal
severity: normal
status: open
title: shadows around the io truncate() semantics
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/issue6939>
_______________________________________
From report at bugs.python.org Fri Sep 18 15:58:09 2009
From: report at bugs.python.org (Rajarshi)
Date: Fri, 18 Sep 2009 13:58:09 +0000
Subject: [New-bugs-announce] [issue6940] cannot compute sizeof wchar_t on OS
X 10.5.7, Python 2.6.2
In-Reply-To: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za>
Message-ID: <1253282289.6.0.748940498634.issue6940@psf.upfronthosting.co.za>
New submission from Rajarshi <rajarshi.guha at gmail.com>:
OS 10.5.7, Python 2.6.2 sources.
When I execute:
/configure --enable-framework=/Library/Frameworks \
--enable-universalsdk=/ \
MACOSX_DEPLOYMENT_TARGET=10.5 \
--with-universal-archs=all \
--with-readline-dir=/usr/local
configure fails with the error
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
However, if I replace all with 64-bit, it works fine. I note that this
issue was reported for OS X 10.4 and fixed. But this still happens
gcc information is
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5490~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5490)
----------
components: Build
messages: 92824
nosy: rajarshi
severity: normal
status: open
title: cannot compute sizeof wchar_t on OS X 10.5.7, Python 2.6.2
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6940>
_______________________________________
From report at bugs.python.org Fri Sep 18 21:58:12 2009
From: report at bugs.python.org (Joshua Purcell)
Date: Fri, 18 Sep 2009 19:58:12 +0000
Subject: [New-bugs-announce] [issue6941] Help
Message-ID: <1253303892.82.0.946602565128.issue6941@psf.upfronthosting.co.za>
Changes by Joshua Purcell <spamail.08jpurcellserver at gmail.com>:
----------
nosy: 08jpurcell
severity: normal
status: open
title: Help
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________
From report at bugs.python.org Sat Sep 19 01:53:52 2009
From: report at bugs.python.org (Ross Patterson)
Date: Fri, 18 Sep 2009 23:53:52 +0000
Subject: [New-bugs-announce] [issue6942] email.generator.Generator memory
consumption
In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
Message-ID: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
New submission from Ross Patterson <me at rpatterson.net>:
Due to repeated use of StringIO as a way to "look ahead" into subparts
while checking that multipart boundaries are unique, memory consumption
during email.generator.Generator.flatten() can be up to 3 times the
original message size.
I implemented a subclass of email.generator.Generator that works around
this using email.message.Message.walk() to check message headers and
string (final) payloads for the boundary without duplicating their
contents into a StringIO.
It assumes that the boundary only ever might be duplicated in a single
part's headers or in a single part's payload when that part's payload is
a string. IOW, it assumes that the boundary will not be duplicated by
some combination of all the parts' and recursive subparts' headers and
string payloads.
If this assumption is safe, then this implementation should work. If
this assumption is not safe, then perhaps a different boundary format
can be used which will make this assumption safe?
You can find my implementation at http://gitorious.org/rpatterson-
imappipe/rpatterson-
imappipe/blobs/master/rpatterson/imappipe/generator.py
----------
components: Library (Lib)
messages: 92853
nosy: rpatterson
severity: normal
status: open
title: email.generator.Generator memory consumption
type: resource usage
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6942>
_______________________________________
From report at bugs.python.org Sat Sep 19 05:18:42 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Sep 2009 03:18:42 +0000
Subject: [New-bugs-announce] [issue6943] setup.py fails to find headers of
system libffi
In-Reply-To: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
Message-ID: <1253330322.94.0.647706563321.issue6943@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
I use --with-system-ffi option, but setup.py fails to find headers of
system libffi which are placed outside standard include directory,
which causes using of internal copy of libffi.
In Gentoo, headers of libffi-3.0.8 are installed into
/usr/lib/libffi-3.0.8/include directory, because their content is
specific to given architecture.
I'm attaching the patch which cause using of `pkg-config libffi --
(Unfortunately subprocess module cannot be used in setup.py, so I'm
using os.popen().)
----------
components: Build
files: python-fix_search_for_libffi_headers.patch
keywords: patch
messages: 92856
nosy: Arfrever, loewis
severity: normal
status: open
title: setup.py fails to find headers of system libffi
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/file14928/python-fix_search_for_libffi_headers.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6943>
_______________________________________
From report at bugs.python.org Sat Sep 19 07:36:10 2009
From: report at bugs.python.org (Marien Zwart)
Date: Sat, 19 Sep 2009 05:36:10 +0000
Subject: [New-bugs-announce] [issue6944] socket.getnameinfo raises
SystemError on bogus input
In-Reply-To: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za>
Message-ID: <1253338570.09.0.666408311611.issue6944@psf.upfronthosting.co.za>
New submission from Marien Zwart <m_zwart at 123mail.org>:
socket.getnameinfo passes a PyObject* to PyArg_ParseTuple without
checking if it's a tuple first. That means it raises SystemError on
invalid input where TypeError would make more sense:
>>> socket.getnameinfo('localhost', 0)
SystemError: new style getargs format but argument is not a tuple
An explicit check for TypeError seems like the best way to fix this.
Patch (against Python 3.1.1, but it looked like this applies easily to
other branches too) attached, which also removes a bit of dead code.
----------
components: Extension Modules
files: diff.patch
keywords: patch
messages: 92858
nosy: marienz
severity: normal
status: open
title: socket.getnameinfo raises SystemError on bogus input
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14929/diff.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6944>
_______________________________________
From report at bugs.python.org Sat Sep 19 11:26:59 2009
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 19 Sep 2009 09:26:59 +0000
Subject: [New-bugs-announce] [issue6945] pprint.pprint does not pprint
unsortable dicts in Python 3
In-Reply-To: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
Message-ID: <1253352419.89.0.0604229047427.issue6945@psf.upfronthosting.co.za>
New submission from Armin Ronacher <armin.ronacher at active-4.com>:
Currently pprint does not work on dicts it cannot sort. Because in
Python 3 sorted(x.items()) is no longer guaranteed to work a new sorting
solution has to be found.
----------
messages: 92862
nosy: aronacher
severity: normal
status: open
title: pprint.pprint does not pprint unsortable dicts in Python 3
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6945>
_______________________________________
From report at bugs.python.org Sat Sep 19 11:35:44 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 19 Sep 2009 09:35:44 +0000
Subject: [New-bugs-announce] [issue6946] Document: Missing link to
datetime.datetime
In-Reply-To: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za>
Message-ID: <1253352944.46.0.750733496688.issue6946@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
Please see http://docs.python.org/genindex-D.html.
"datetime (class in datetime), [1]"
links to same address. I think "[1]" should point to
http://docs.python.org/library/datetime.html#datetime-datetime.
----------
assignee: georg.brandl
components: Documentation
messages: 92863
nosy: georg.brandl, ocean-city
severity: normal
status: open
title: Document: Missing link to datetime.datetime
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6946>
_______________________________________
From report at bugs.python.org Sat Sep 19 11:44:45 2009
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 19 Sep 2009 09:44:45 +0000
Subject: [New-bugs-announce] [issue6947] Fix distutils test on windows (SO
extension)
In-Reply-To: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za>
Message-ID: <1253353485.29.0.889372129006.issue6947@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:
This will fix distutils test error on windows.
----------
assignee: tarek
components: Distutils, Tests
files: test_distutils.patch
keywords: patch
messages: 92864
nosy: ocean-city, tarek
severity: normal
status: open
title: Fix distutils test on windows (SO extension)
versions: Python 2.6
Added file: http://bugs.python.org/file14931/test_distutils.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6947>
_______________________________________
From report at bugs.python.org Sat Sep 19 16:59:00 2009
From: report at bugs.python.org (kewlar)
Date: Sat, 19 Sep 2009 14:59:00 +0000
Subject: [New-bugs-announce] [issue6948] list
In-Reply-To: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za>
Message-ID: <1253372340.63.0.203470162856.issue6948@psf.upfronthosting.co.za>
New submission from kewlar <bolshenog at bk.ru>:
>>> a = [[0,0,0],[0,0,0],[0,0,0]]
>>> a
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
>>> a[1][1] = 1
>>> a
[[0, 0, 0], [0, 1, 0], [0, 0, 0]]
>>> b = [[0]*3]*3
>>> b
[[0, 0, 0], [0, 0, 0], [0, 0, 0]]
>>> b[1][1] = 1
>>> b
[[0, 1, 0], [0, 1, 0], [0, 1, 0]]
>>>
----------
messages: 92869
nosy: nutregina
severity: normal
status: open
title: list
type: performance
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6948>
_______________________________________
From report at bugs.python.org Sat Sep 19 18:09:31 2009
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Sep 2009 16:09:31 +0000
Subject: [New-bugs-announce] [issue6949] Support Berkeley DB 4.8
In-Reply-To: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
Message-ID: <1253376571.72.0.252894663402.issue6949@psf.upfronthosting.co.za>
New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:
Python doesn't detect Berkeley DB 4.8. After updating setup.py, _bsddb
module fails to build due to some changes in Berkeley DB.
I'm attaching patch which seems to fix these problems.
Changes in setup.py were made by me.
Changes in Modules/_bsddb.c were copied from bsddb3-4.8.0 [1].
[1] http://www.jcea.es/programacion/pybsddb.htm
----------
components: Build
files: python-support_bdb-4.8.patch
keywords: patch
messages: 92871
nosy: Arfrever
severity: normal
status: open
title: Support Berkeley DB 4.8
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14933/python-support_bdb-4.8.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6949>
_______________________________________
From report at bugs.python.org Sat Sep 19 18:24:21 2009
From: report at bugs.python.org (kai zhu)
Date: Sat, 19 Sep 2009 16:24:21 +0000
Subject: [New-bugs-announce] [issue6950] online documentation error:
PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
In-Reply-To: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za>
Message-ID: <1253377461.16.0.726323849113.issue6950@psf.upfronthosting.co.za>
New submission from kai zhu <kaizhu256 at gmail.com>:
according to bytearrayobject.c, PyByteArray_Resize should return int (not
PyObject *)
error found @
http://docs.python.org/dev/py3k/c-api/bytearray.html
http://docs.python.org/c-api/bytearray.html
----------
assignee: georg.brandl
components: Documentation
messages: 92872
nosy: georg.brandl, kaizhu
severity: normal
status: open
title: online documentation error: PyObject* PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6950>
_______________________________________
From report at bugs.python.org Sun Sep 20 10:05:16 2009
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Sep 2009 08:05:16 +0000
Subject: [New-bugs-announce] [issue6951] OS X IDLE has two Preferences menus
on 2.6.x with Tk > 8.4.7
In-Reply-To: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>
Message-ID: <1253433916.83.0.225412308187.issue6951@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Release blocker
On OS X IDLE 2.6 shows two Preference menu items, the second dimmed out,
but only when running with an installed Tk 8.4 > 8.4.7.
This is the same problem identified in Issue6100 and was fixed in trunk
but not backported. Now that the Apple-supplied 8.4 Tk in 10.6 is 8.4.19,
the problem is more serious on 2.6. The attached patch backports r72946
from trunk.
----------
assignee: ronaldoussoren
components: IDLE, Macintosh
files: patch-nad0027-26.txt
messages: 92883
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: OS X IDLE has two Preferences menus on 2.6.x with Tk > 8.4.7
versions: Python 2.6
Added file: http://bugs.python.org/file14937/patch-nad0027-26.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6951>
_______________________________________
From report at bugs.python.org Sun Sep 20 13:29:46 2009
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 20 Sep 2009 11:29:46 +0000
Subject: [New-bugs-announce] [issue6952] deprecated conversion from string
constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
New submission from Barry Alan Scott <barry-scott at users.sourceforge.net>:
Many Python API functions are causing GCC to rightly complain
that const char * strings are being passed to python functions
that take char * but do not need to modify the args.
g++ reports example.cxx:633: warning: deprecated conversion from string
constant to ?char*?
The example I encountered today, while testing PyCXX against
G++ 4.2.1 on Mac OS X, was PyObject_CallMethod
but it is not limited to this function.
Would a patch help progress this issue?
----------
components: Interpreter Core
messages: 92890
nosy: barry-scott
severity: normal
status: open
title: deprecated conversion from string constant to char *
type: compile error
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6952>
_______________________________________
From report at bugs.python.org Sun Sep 20 16:13:32 2009
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Sep 2009 14:13:32 +0000
Subject: [New-bugs-announce] [issue6953] readline documenation needs work
In-Reply-To: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
Message-ID: <1253456012.32.0.661240289209.issue6953@psf.upfronthosting.co.za>
New submission from Ronald Oussoren <ronaldoussoren at mac.com>:
The documentation for the readline module is a bit too minimal.
1) function 'add_history' is described at the end of the documentation,
not near the other functions for manipulation the history stack.
2) the index for remove_history_item and replace_history_item is 0-
based,
while the index for get_history_item is 1-based.
The latter is a confusing API in the underlying readline library and
should IMO be described in Python's documentation.
(If readline were a new addition to the stdlib I'd prefer to fix the
interface, but that would have too many backward compatibility issues at
this point in time).
----------
assignee: georg.brandl
components: Documentation
messages: 92893
nosy: georg.brandl, ronaldoussoren
severity: normal
status: open
title: readline documenation needs work
type: feature request
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6953>
_______________________________________
From report at bugs.python.org Sun Sep 20 22:27:43 2009
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Sep 2009 20:27:43 +0000
Subject: [New-bugs-announce] [issue6954] DISTUTILS_DEBUG causes stack trace,
really simple fix
In-Reply-To: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
Message-ID: <1253478463.14.0.399738185505.issue6954@psf.upfronthosting.co.za>
New submission from Ned Batchelder <nedbat at users.sourceforge.net>:
If you set the environment variable DISTUTILS_DEBUG=1, distutils will
run with DEBUG, which will trace internal activity. But one of the
traces is incorrect, and leads to this stack trace:
Traceback (most recent call last):
File "setup.py", line 116, in <module>
**more_setup_args
File "c:\python31\lib\distutils\core.py", line 123, in setup
dist.parse_config_files()
File "c:\python31\lib\distutils\dist.py", line 357, in parse_config_files
self.announce(" reading", filename)
File "c:\python31\lib\distutils\dist.py", line 911, in announce
log.log(level, msg)
File "c:\python31\lib\distutils\log.py", line 31, in log
self._log(level, msg, args)
File "c:\python31\lib\distutils\log.py", line 20, in _log
if level >= self.threshold:
TypeError: unorderable types: str() >= int()
The fix is simple: at line 356 of dist.py, change:
if DEBUG:
self.announce(" reading", filename)
to:
if DEBUG:
self.announce(" reading " + filename)
----------
assignee: tarek
components: Distutils
messages: 92916
nosy: nedbat, tarek
severity: normal
status: open
title: DISTUTILS_DEBUG causes stack trace, really simple fix
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6954>
_______________________________________
From report at bugs.python.org Mon Sep 21 05:03:05 2009
From: report at bugs.python.org (lovelygoo2)
Date: Mon, 21 Sep 2009 03:03:05 +0000
Subject: [New-bugs-announce] [issue6955] Max() Not Working Properly
In-Reply-To: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za>
Message-ID: <1253502185.93.0.333528519987.issue6955@psf.upfronthosting.co.za>
New submission from lovelygoo2 <smergibblegibberish at usa.com>:
>>> max(['34', '7'])
'7'
>>> #This happens because it is comparing strings.
>>> #I have found a way to fix it though.
>>> def Max(li):
... greatest=li[0]
... for item in li:
... for item2 in li:
... if int(item)<int(item2) or int(item)<greatest:
... break
... else:
... greatest=int(item)
... return(greatest)
----------
components: IDLE
messages: 92920
nosy: lovelygoo2
severity: normal
status: open
title: Max() Not Working Properly
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6955>
_______________________________________
From report at bugs.python.org Mon Sep 21 12:54:21 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 21 Sep 2009 10:54:21 +0000
Subject: [New-bugs-announce] [issue6956] Test creation in
unittest.TestProgram should be done in one place
In-Reply-To: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za>
Message-ID: <1253530461.77.0.303608237398.issue6956@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Requested by Fernando Perez on the Testing in Python mailing list.
Test creation in TestProgram is done in both parseArgs and createTests.
It would be better if it was only done in createTests so that
controlling test creation only required the overloading of a single method.
> in TestProgram.parseArgs we have:
>
> if len(args) == 0 and self.defaultTest is None:
> self.test =
self.testLoader.loadTestsFromModule(self.module)
> return
>
> and then later:
>
> def createTests(self):
> self.test = self.testLoader.loadTestsFromNames(self.testNames,
> self.module)
>
> So basically if you want to control how tests are created, you can't
just override createTests, because parseArgs also does test creation
> (but only sometimes, depending on certain conditions).
> I think that parseArgs should perhaps only parse args, and createTests
should only create tests, but I'm weird like that :) For the case
> above, it could set a flag that createTests can then later use to
decide what to do, but parseArgs shouldn't be doing test creation IMO.
----------
assignee: michael.foord
components: Library (Lib)
messages: 92929
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: Test creation in unittest.TestProgram should be done in one place
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6956>
_______________________________________
From report at bugs.python.org Mon Sep 21 13:06:00 2009
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Sep 2009 11:06:00 +0000
Subject: [New-bugs-announce] [issue6957] Extension modules fail to build on
OS X 10.6 using python.org 2.x/3.x
In-Reply-To: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
Message-ID: <1253531160.04.0.821468324712.issue6957@psf.upfronthosting.co.za>
New submission from Ned Deily <nad at acm.org>:
Potential 2.6.3 release blocker
On OS X 10.6 (Snow Leopard), if you attempt to install a package with a
extension module using a Python from a python.org OS X installer (say,
2.6.x or 3.1.x), the c compilation steps will likely fail in one of two
ways:
1. Recent python.org installers are built using the OS X 10.4 SDK so
that one installer image will work on 10.4, 10.5 and now 10.6 (in
theory, 10.3.x as well). Building of extension modules also require gcc
and the SDKs, which are included as part of Apple's Xcode tools.
However, with 10.6 Xcode, the 10.4 SDK is not installed by default so
the extension module build will fail due to missing include files. Once
the problem is known, it can be solved easily by installing the SDK from
the release DVD that comes with the system or upgrade.
2. Even with the 10.4 SDK installed on 10.6, the compilation fails with:
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error:
stdarg.h: No such file or directory
This can be especially baffling to those unfamiliar with nested include
files because the base file stdarg.h does exist in that directory.
The root cause here is that Snow Leopard now uses gcc-4.2 by default but
the 10.4 SDK does not include headers for 4.2. The solution is to force
use of gcc-4.0, the default on 10.4 and 10.5 and included in 10.6, by
defining the CC environment variable:
$ export CC=/usr/bin/gcc-4.0
$ python setup.py install
or
$ easy_install xxx
Even for experienced developers, these can be non-trivial problems to
resolve although the solutions, once known, are easy to implement.
Unfortunately, all types of python users can run into these issues
simply by trying to install and use a package that includes an extension
module. There are a growing number of hits on the web from people
trying to install popular packages such as MySQLdb, PIL, and lxml using
a python.org Python on 10.6. Note this isn't a problem for users of the
Apple-supplied Pythons (2.6 and 2.5) on 10.6 since they do not use the
10.4 SDK.
There are two separate issues here I think:
1. What, if anything, to do for users of installers already out in the
field?
2. What to do to mitigate the problems for yet-to-be released installers
(e.g. 2.6.3)?
Documenting and publicizing the problems somehow may be the only viable
option for 1. For 2, there is the possibility of some additional
actions, perhaps a warning in the installer readme or some such. It
probably would make sense to contact the maintainers of such packages so
that they can add something to their web pages and documentation.
----------
assignee: ronaldoussoren
components: Extension Modules, Macintosh
messages: 92930
nosy: ned.deily, ronaldoussoren
severity: normal
status: open
title: Extension modules fail to build on OS X 10.6 using python.org 2.x/3.x
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6957>
_______________________________________
From report at bugs.python.org Mon Sep 21 13:23:17 2009
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 21 Sep 2009 11:23:17 +0000
Subject: [New-bugs-announce] [issue6958] Add Python command line flags to
configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
New submission from Thomas Heller <theller at ctypes.org>:
I want the Python executable to have command line flags which allow
simple configuration of the logging module. Use cases are to run
applications/scripts (which use libraries that use logging calls) with
different logging output without having to edit (ugly) logging config files.
The attached patch demonstrates the idea; it allows to run 'python -l
<options> ...' and passes <options> to a new function
logging._parse_python_options(<options>).
----------
components: Interpreter Core, Library (Lib)
files: logging.patch
keywords: patch
messages: 92932
nosy: theller
severity: normal
status: open
title: Add Python command line flags to configure logging
type: feature request
Added file: http://bugs.python.org/file14941/logging.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6958>
_______________________________________
From report at bugs.python.org Mon Sep 21 20:46:12 2009
From: report at bugs.python.org (cscscs)
Date: Mon, 21 Sep 2009 18:46:12 +0000
Subject: [New-bugs-announce] [issue6959] OS X 10.6 / Snow Leopard
Message-ID: <1253558772.91.0.545762042171.issue6959@psf.upfronthosting.co.za>
Changes by cscscs <chris at schleiermachers.de>:
----------
nosy: cscscs
severity: normal
status: open
title: OS X 10.6 / Snow Leopard
type: compile error
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6959>
_______________________________________
From report at bugs.python.org Mon Sep 21 23:34:12 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:34:12 +0000
Subject: [New-bugs-announce] [issue6960] test_telnetlib gives spurious output
In-Reply-To: <1253568852.27.0.259606507401.issue6960@psf.upfronthosting.co.za>
Message-ID: <1253568852.27.0.259606507401.issue6960@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I just got the following traceback:
Exception in thread Thread-538:
Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/threading.py", line 509, in
_bootstrap_inner
self.run()
File "/home/antoine/py3k/__svn__/Lib/threading.py", line 462, in run
self._target(*self._args, **self._kwargs)
File "/home/antoine/py3k/__svn__/Lib/test/test_telnetlib.py", line 25,
in server
conn, addr = serv.accept()
File "/home/antoine/py3k/__svn__/Lib/socket.py", line 120, in accept
fd, addr = self._accept()
socket.error: [Errno 4] Interrupted system call
Interestingly, it happens *after* test_telnetlib returned successfully.
----------
components: Tests
messages: 92962
nosy: jackdied, pitrou
priority: normal
severity: normal
status: open
title: test_telnetlib gives spurious output
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6960>
_______________________________________
From report at bugs.python.org Mon Sep 21 23:36:18 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Sep 2009 21:36:18 +0000
Subject: [New-bugs-announce] [issue6961] test_distutils failure
In-Reply-To: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
Message-ID: <1253568978.09.0.00053236217628.issue6961@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
I get the following (deterministic) failure on the py3k branch:
test_distutils
0 blocks
find:
`/home/antoine/tmp/tmpX6PtRb/foo/build/bdist.linux-x86_64/rpm/BUILDROOT/foo-0.1-1.x86_64/usr/lib/debug':
Aucun fichier ou dossier de ce type
0 blocks
find:
`/home/antoine/tmp/tmpNJkuVH/foo/build/bdist.linux-x86_64/rpm/BUILDROOT/foo-0.1-1.x86_64/usr/lib/debug':
Aucun fichier ou dossier de ce type
test test_distutils failed -- Traceback (most recent call last):
File "/home/antoine/py3k/__svn__/Lib/distutils/tests/test_util.py",
line 145, in test_get_platform
self.assertEquals(get_platform(), 'macosx-10.4-universal')
AssertionError: 'macosx-10.4-intel' != 'macosx-10.4-universal'
1 test failed:
test_distutils
----------
assignee: tarek
components: Distutils, Tests
messages: 92963
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils failure
type: behavior
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6961>
_______________________________________
From report at bugs.python.org Tue Sep 22 00:26:52 2009
From: report at bugs.python.org (thewtex)
Date: Mon, 21 Sep 2009 22:26:52 +0000
Subject: [New-bugs-announce] [issue6962] traceback.format_exception_only
does not return SyntaxError carot correctly
In-Reply-To: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
Message-ID: <1253572012.9.0.846902756749.issue6962@psf.upfronthosting.co.za>
New submission from thewtex <matt at mmmccormick.com>:
On Python 2.6.2, and possibly other versions, in the traceback module,
format_exception_only does not behave correctly when printout out a
SyntaxError. An extra newline is inserted before the carot. E.g.
38 exceptionType, exceptionValue, exceptionTraceback =
sys.exc_info()
39 sys.stderr.write("Exception:\n")
40 ex = traceback.format_exception_only(exceptionType,
exceptionValue)
41 sys.stderr.write(repr(ex))
42 for line in ex:
43 sys.stderr.write(line)
yields, e.g.
Exception:
[' File "/home/matt/apps/posac/source/posac/posac_main.py", line 12\n',
' def run()\n', ' \n^\n', 'SyntaxError: invalid syntax\n']
File "/home/matt/apps/posac/source/posac/posac_main.py", line 12
def run()
^
SyntaxError: invalid syntax
When it should be:
Exception:
[' File "/home/matt/apps/posac/source/posac/posac_main.py", line 12\n',
' def run()\n', ' ^\n', 'SyntaxError: invalid syntax\n']
File "/home/matt/apps/posac/source/posac/posac_main.py", line 12
def run()
^
SyntaxError: invalid syntax
Attached is a patch. This patch has been tested on gentoo linux.
----------
messages: 92966
nosy: thewtex
severity: normal
status: open
title: traceback.format_exception_only does not return SyntaxError carot correctly
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6962>
_______________________________________
From report at bugs.python.org Tue Sep 22 04:28:32 2009
From: report at bugs.python.org (Charles Cazabon)
Date: Tue, 22 Sep 2009 02:28:32 +0000
Subject: [New-bugs-announce] [issue6963] Add worker process lifetime to
multiprocessing.Pool - patch included
In-Reply-To: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
Message-ID: <1253586512.1.0.332909972993.issue6963@psf.upfronthosting.co.za>
New submission from Charles Cazabon <charlesc-python at pyropus.ca>:
Worker processes with multiprocessing.Pool live for the duration of the
Pool. If the tasks they run happen to leak memory (from a C extension
module, or from creating cycles of unreachable objects, etc) or open
files or other resources, there's no easy way to clean them up.
Similarly, if one task passed to the pool allocates a large amount of
memory, but further tasks are small, that additional memory isn't
returned to the system because the process involved hasn't exited.
A common approach to this problem (as used by Apache, mod_wsgi, and
various other software) is to allow worker processes to exit (and be
replaced with fresh processes) after completing a specified amount of
work. The attached patch (against Python 2.6.2, but applies to various
other versions with some fuzz) implements this as optional new behaviour
in multiprocessing.Pool(). An additional optional argument is specified
for the maximum number of tasks a worker process performs before it
exits and is replaced with a fresh worker process.
----------
components: Library (Lib)
files: worker-lifetime-python2.6.2.patch
keywords: patch
messages: 92971
nosy: charlesc
severity: normal
status: open
title: Add worker process lifetime to multiprocessing.Pool - patch included
type: feature request
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14946/worker-lifetime-python2.6.2.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6963>
_______________________________________
From report at bugs.python.org Tue Sep 22 11:16:48 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 22 Sep 2009 09:16:48 +0000
Subject: [New-bugs-announce] [issue6964] import new fails
In-Reply-To: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
Message-ID: <1253611008.63.0.50071403337.issue6964@psf.upfronthosting.co.za>
New submission from Rene Dudfield <illume at users.sourceforge.net>:
python3.1
>>> import new
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named new
2to3-3.1 doesn't mention how to change it.
----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 92974
nosy: illume
severity: normal
status: open
title: import new fails
type: behavior
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6964>
_______________________________________
From report at bugs.python.org Tue Sep 22 11:21:58 2009
From: report at bugs.python.org (djc)
Date: Tue, 22 Sep 2009 09:21:58 +0000
Subject: [New-bugs-announce] [issue6965] tmpnam should not be used if
tempfile or mkstemp are available
In-Reply-To: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
Message-ID: <1253611318.55.0.148600850079.issue6965@psf.upfronthosting.co.za>
New submission from djc <dirkjan at ochtman.nl>:
I have a bug report in the Gentoo tracker
(http://bugs.gentoo.org/show_bug.cgi?id=221183):
"This is a rather strange request, but please bear me.
While building Posix module, python checks (among others) for
tmpfile, tmpnam and tmpnam_r
however man pages state explicitly, that in case tmpfile is available, other
two should not be used
if libpython2.5.a is built with either of them, linker complains each
time it's
added
While this doesn't break anything, it's still a bit annoying.
so I propose to remove functionality as an enhancement:
to change in Modules/posixmodule.c
#ifdef HAVE_TMPNAM
to
#ifdef HAVE_TMPNAM && !defined(HAVE_TMPFILE)
Your thoughts?"
man 3 tmpnam state "Never use this function. Use mkstemp(3) or
tmpfile(3) instead.".
Not sure whether this is exposed anywhere, but I figured this bug would
be better handled upstream from Gentoo.
----------
components: Extension Modules
messages: 92975
nosy: djc
severity: normal
status: open
title: tmpnam should not be used if tempfile or mkstemp are available
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6965>
_______________________________________
From report at bugs.python.org Tue Sep 22 11:28:07 2009
From: report at bugs.python.org (Johan Tufvesson)
Date: Tue, 22 Sep 2009 09:28:07 +0000
Subject: [New-bugs-announce] [issue6966] Ability to refer to arguments in
TestCase.fail* methods
In-Reply-To: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
Message-ID: <1253611687.96.0.247846871836.issue6966@psf.upfronthosting.co.za>
New submission from Johan Tufvesson <jot at hms.se>:
In the unittest module, TestCase class:
If one wants to provide a more descriptive fail message compared to the
default, it is often valuable to be able to refer to the arguments
evaluated by the fail*- (or assert*-) method. This can be accomplished
by binding names to the evaluated values before the call to the
fail*-methods, and then providing a string with the values embedded as
needed. This, however, can be quite cumbersome when there are a lot of
calls to fail*-methods.
Today:
Arg1 = RealValue()
Arg2 = ExpectedValue()
self.failUnlessEqual(Arg1, Arg2, "Got {0}, but expected
{1}.".format(Arg1, Arg2))
Proposed solution:
In the fail*-methods, check if the msg argument is some kind of string
(basestring?), and run the format() method on the string with the
supplied arguments. This would result in code like this:
self.failUnlessEqual(RealValue(), ExpectedValue(), "Got {0}, but
expected {1}.")
----------
components: Library (Lib)
messages: 92977
nosy: tuben
severity: normal
status: open
title: Ability to refer to arguments in TestCase.fail* methods
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6966>
_______________________________________
From report at bugs.python.org Tue Sep 22 12:21:23 2009
From: report at bugs.python.org (Sascha)
Date: Tue, 22 Sep 2009 10:21:23 +0000
Subject: [New-bugs-announce] [issue6967] codec windows1256 should be windows
windows-1256
In-Reply-To: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za>
Message-ID: <1253614883.36.0.531547285438.issue6967@psf.upfronthosting.co.za>
New submission from Sascha <python-bugreport at discorner.de>:
It seem that there's a dash missing.
http://docs.python.org/dev/library/codecs.html#standard-encodings
>>> u'Sorry, this in here makes no sense'.encode('windows1256')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
LookupError: unknown encoding: windows1256
On the other hand windows-1256 works.
----------
assignee: georg.brandl
components: Documentation
files: codecs.rst.patch
keywords: patch
messages: 92980
nosy: DerSascha, georg.brandl
severity: normal
status: open
title: codec windows1256 should be windows windows-1256
versions: Python 2.5, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file14948/codecs.rst.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6967>
_______________________________________
From report at bugs.python.org Tue Sep 22 14:32:57 2009
From: report at bugs.python.org (Rene Dudfield)
Date: Tue, 22 Sep 2009 12:32:57 +0000
Subject: [New-bugs-announce] [issue6968] numpy extensions to distutils...
are a source of improvements for distutils
In-Reply-To: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za>
Message-ID: <1253622777.76.0.936745302949.issue6968@psf.upfronthosting.co.za>
New submission from Rene Dudfield <illume at users.sourceforge.net>:
Hi,
numpy includes a numpy/distutils package which has a lot of
goodies/fixes which might be able to be incorporated into the main
distutils.
Adding this note so distutils maintainers are aware of it.
cheers,
----------
assignee: tarek
components: Distutils
messages: 92986
nosy: illume, tarek
severity: normal
status: open
title: numpy extensions to distutils... are a source of improvements for distutils
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6968>
_______________________________________
From report at bugs.python.org Tue Sep 22 15:45:11 2009
From: report at bugs.python.org (Kandalintsev Alexandre)
Date: Tue, 22 Sep 2009 13:45:11 +0000
Subject: [New-bugs-announce] [issue6969] configparser
In-Reply-To: <1253627111.3.0.369651461039.issue6969@psf.upfronthosting.co.za>
Message-ID: <1253627111.3.0.369651461039.issue6969@psf.upfronthosting.co.za>
New submission from Kandalintsev Alexandre <bug_hunter at messir.net>:
Hello! Seems configparser is broken in recent versions of py3k. Please also check older
versions of python.
$ python3 ./cfgexample.py
Traceback (most recent call last):
File "./cfgexample.py", line 9, in <module>
config.write(configfile)
File "/usr/local/py3k/lib/python3.2/configparser.py", line 394, in write
fp.write("[%s]\n" % section)
TypeError: must be bytes or buffer, not str
$ cat ./cfgexample.py
import configparser
config = configparser.RawConfigParser()
config.add_section('Section1')
config.set('Section1', 'int', '15')
with open('example.cfg', 'wb') as configfile:
config.write(configfile)
$ python3 --version
Python 3.2a0
I've built this version of python:
$ hg head
changeset: 4765:488e143fad23
branch: py3k
tag: tip
user: tarek.ziade
date: Tue Sep 22 12:08:13 2009 +0200
summary: [svn r75013] Merged revisions 74812 via svnmerge from
----------
components: Library (Lib)
messages: 92993
nosy: exe
severity: normal
status: open
title: configparser
versions: Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6969>
_______________________________________
From report at bugs.python.org Tue Sep 22 17:37:06 2009
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Sep 2009 15:37:06 +0000
Subject: [New-bugs-announce] [issue6970] Redundant calls made to comparison
methods.
In-Reply-To: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
Message-ID: <1253633826.69.0.906783936542.issue6970@psf.upfronthosting.co.za>
New submission from Mark Dickinson <dickinsm at gmail.com>:
Here's some strange behaviour in py3k:
newton:py3k dickinsm$ ./python.exe
Python 3.2a0 (py3k:75015, Sep 22 2009, 16:25:12)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
... def __eq__(self, other):
... print("In A.__eq__", self, other)
... return NotImplemented
...
>>> class B:
... def __eq__(self, other):
... print("In B.__eq__", self, other)
... return NotImplemented
...
>>> A() == B()
In A.__eq__ <__main__.A object at 0x34d030> <__main__.B object at 0x448210>
In B.__eq__ <__main__.B object at 0x448210> <__main__.A object at 0x34d030>
In B.__eq__ <__main__.B object at 0x448210> <__main__.A object at 0x34d030>
In A.__eq__ <__main__.A object at 0x34d030> <__main__.B object at 0x448210>
False
I'd expect to see only one call to A.__eq__ and one call to B.__eq__.
The cause seems to be that:
- slot_tp_richcompare (in typeobject.c) makes two calls to half_richcompare,
one with the original arguments and one with reverse arguments, *and*
- do_richcompare (in object.c) also makes two calls to the tp_richcompare
slot; again, one with the original arguments and one with the reversed
arguments.
I tried removing the second block of slot_tp_richcompare (still in py3k);
make and make test succeeded without any problems. Removing this block does
change behaviour though, so probably should not happen until 3.2, given that
no-one appears to have reported the current behaviour actually causing any
problems.
The duplicate calls also exist in 2.x; figuring out a solution there (and
being sure that the solution does the right thing) looks complicated, thanks
to all the rich-compare/three-way-compare interactions.
----------
components: Interpreter Core
messages: 93000
nosy: mark.dickinson
severity: normal
stage: needs patch
status: open
title: Redundant calls made to comparison methods.
type: behavior
versions: Python 2.7, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6970>
_______________________________________
From report at bugs.python.org Tue Sep 22 23:50:30 2009
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 22 Sep 2009 21:50:30 +0000
Subject: [New-bugs-announce] [issue6971] Add the SIO_KEEPALIVE_VALS option
to socket.ioctl
In-Reply-To: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
Message-ID: <1253656230.46.0.20355250145.issue6971@psf.upfronthosting.co.za>
New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:
Adding the SIO_KEEPALIVE_VALS option to socket.ioctl on windows allows a
windows user to specify the timeout and interval for TCP keepalive support
differently from the defaults specified in RFC 1122 on a per-socket basis.
The 'option' is a tuple corresponging to the 'struct tcp_keepalive'
expected by WSAIoctl
See http://msdn.microsoft.com/en-us/library/dd877220(VS.85).aspx for
details.
----------
components: IO
files: wsaioctl.patch
keywords: easy, patch, patch
messages: 93020
nosy: krisvale
severity: normal
status: open
title: Add the SIO_KEEPALIVE_VALS option to socket.ioctl
versions: Python 2.7
Added file: http://bugs.python.org/file14950/wsaioctl.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6971>
_______________________________________
From report at bugs.python.org Wed Sep 23 00:10:52 2009
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 22 Sep 2009 22:10:52 +0000
Subject: [New-bugs-announce] [issue6972] zipfile.ZipFile
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
New submission from Ralf Schmitt <schmir at gmail.com>:
ZipFile.extractall happily overwrites any file on the filesystem. One
can put files with a name like "//etc/password" in a zip file and
extractall will overwrite /etc/password (with sufficient rights).
The docs say:
ZipFile.extractall([path[, members[, pwd]]])
Extract all members from the archive to the current working
directory. path specifies a different directory to extract to. members
is optional and must be a subset of the list returned by namelist(). pwd
is the password used for encrypted files.
I read that as: it will put all files into path or a subdirectory.
Using names like "../../../etc/password" also leads to files being
written outside that path directory.
----------
components: Library (Lib)
messages: 93021
nosy: schmir
severity: normal
status: open
title: zipfile.ZipFile
type: security
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________
From report at bugs.python.org Wed Sep 23 00:47:48 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Tue, 22 Sep 2009 22:47:48 +0000
Subject: [New-bugs-announce] [issue6973] subprocess.Popen.send_signal
doesn't check whether the process has terminated
In-Reply-To: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
Message-ID: <1253659668.76.0.344119676181.issue6973@psf.upfronthosting.co.za>
New submission from Milko Krachounov <python at milko.3mhz.net>:
When subprocess.Popen.send_signal is called, it simply calls
os.kill(self.pid, ...) without checking whether the child has already
terminated. If the child has been terminated, and Popen.wait() or
Popen.poll() have been called, a process with PID self.pid no longer
exists, and what's worse, could belong to a totally unrelated process.
A better behavior would be to raise an exception when self.returncode is
not None. Alternatively, self.pid might be set to None after the process
has been terminated, as it is no longer meaningful. Or to another value
that would be invalid pid and invalid argument to os.kill and os.wait,
but unlike None would still evaluate to True.
----------
components: Library (Lib)
messages: 93022
nosy: milko.krachounov
severity: normal
status: open
title: subprocess.Popen.send_signal doesn't check whether the process has terminated
type: behavior
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6973>
_______________________________________
From report at bugs.python.org Wed Sep 23 07:47:07 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:47:07 +0000
Subject: [New-bugs-announce] [issue6974] test_posix getcwd test leaves tmp
dir
In-Reply-To: <1253684827.18.0.268921836633.issue6974@psf.upfronthosting.co.za>
Message-ID: <1253684827.18.0.268921836633.issue6974@psf.upfronthosting.co.za>
New submission from Ian Donaldson <iand at ekit-inc.com>:
whilst debugging the getcwd test on Solaris 9 I noticed that
the rmtree() failed, as on Solaris rmdir(2) returns EINVAL
if cwd is the named directory.
Fix is to reorder the rmtree and chdir, see attached patch.
----------
components: Tests
files: EKIT.PATCH4
messages: 93026
nosy: iandekit
severity: normal
status: open
title: test_posix getcwd test leaves tmp dir
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14954/EKIT.PATCH4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6974>
_______________________________________
From report at bugs.python.org Wed Sep 23 07:55:13 2009
From: report at bugs.python.org (Sylwester Warecki)
Date: Wed, 23 Sep 2009 05:55:13 +0000
Subject: [New-bugs-announce] [issue6975] symlinks incorrectly resolved on
Linux
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
New submission from Sylwester Warecki <swarecki at cox.net>:
Hi
The behavior of os.realpath function on Linux is different from the one
presented by the system.
Although the path (pointing to the linked dir) is correct
and is recognized by os.path.exists once it is resolved
by the realpath() it does not exist - at the end of the
resolved path you will see the additional parent directory name.
you will see
..... /two/two at the end of the path.
Below is the code that shows the issue.
def linkGen():
import os
print os.getcwd()
test = "./test"
os.system( "rm -rf " + test )
#os.mkdir( test )
os.makedirs( test + "/one" )
os.makedirs( test + "/two" )
os.symlink( "../two", test + "/two/this_dir" )
os.symlink( "../two/this_dir/this_dir/this_dir/this_dir/", test +
"/one/that_dir" )
print test + "/one/that_dir", "EXISTS?",
print os.path.exists( test + "/one/that_dir" )
print os.path.realpath( test + "/one/that_dir" ), "EXISTS?",
print os.path.exists( os.path.realpath( test + "/one/that_dir" ) )
os.system( "ls -l " + test + "/one/that_dir" )
# the line above will show that system can see the directory just fine
linkGen()
----------
components: Library (Lib)
messages: 93027
nosy: swarecki
severity: normal
status: open
title: symlinks incorrectly resolved on Linux
type: behavior
versions: Python 2.5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________
From report at bugs.python.org Wed Sep 23 07:55:37 2009
From: report at bugs.python.org (Ian Donaldson)
Date: Wed, 23 Sep 2009 05:55:37 +0000
Subject: [New-bugs-announce] [issue6976] getcwd hangs and leaks mem on
Solaris <= 9 in very long file name case
In-Reply-To: <1253685337.93.0.462290997823.issue6976@psf.upfronthosting.co.za>
Message-ID: <1253685337.93.0.462290997823.issue6976@psf.upfronthosting.co.za>
New submission from Ian Donaldson <iand at ekit-inc.com>:
test_posix hung on Solaris 9 ... traced to getcwd test hanging.
This in turn was traced to the very long filename case...
It seems posixmodule was modified (since py2.4.3 at least)
to retry getcwd with a bigger buffer if ERANGE occurs.
However on Solaris 9 its not documented that ERANGE also
occurs if getcwd(3) can't cope with the path length, even
if the buffer is big enough. This causes posix_getcwd() to
loop malloc'ing a bigger buffer, forever.
I enclose a patch that limits the damage, to 1Mbyte at least.
(not sure if more recent Solaris 9 patches than we have
provide another solution)
On Solaris 10, there is no problem as the getcwd() is implemented
as a system call.
----------
components: Build
files: EKIT.PATCH5
messages: 93028
nosy: iandekit
severity: normal
status: open
title: getcwd hangs and leaks mem on Solaris <= 9 in very long file name case
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file14955/EKIT.PATCH5
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6976>
_______________________________________
From report at bugs.python.org Wed Sep 23 14:08:13 2009
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Sep 2009 12:08:13 +0000
Subject: [New-bugs-announce] [issue6977] Getopt documentation ambiguity
In-Reply-To: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
Message-ID: <1253707693.16.0.204754165605.issue6977@psf.upfronthosting.co.za>
New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:
the following
>>> getopt.getopt('--testing=dr'.split(), '', ['testing'])[0]
would raise 'option --testing must not have an argument'.
Documentation reads, however: "Long options which require an argument
should be followed by an equal sign ('=')." Which is equivalent to
"options that don't require an argument, should not be followed by the
equal sign". The fact that in my example argument is not required does
not mean that argument cannot be passed.
----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 93033
nosy: SilentGhost, georg.brandl
severity: normal
status: open
title: Getopt documentation ambiguity
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6977>
_______________________________________
From report at bugs.python.org Wed Sep 23 15:35:35 2009
From: report at bugs.python.org (Kees Bos)
Date: Wed, 23 Sep 2009 13:35:35 +0000
Subject: [New-bugs-announce] [issue6978] compiler.transformer dict key bug
d[1, ] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
New submission from Kees Bos <k.bos at zx.nl>:
compiler.parse("d[1] = 1") should have a single tuple as subs
>>> compiler.parse("d[1] = 1")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN',
[Const(1)])], Const(1))]))
>>> compiler.parse("d[1,] = 2")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN',
[Const(1)])], Const(2))]))
>>> compiler.parse("d[1,2] = 3")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1),
Const(2)])], Const(3))]))
>>> compiler.parse("d[(1,)] = 2")
Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN',
[Tuple([Const(1)])])], Const(2))]))
----------
components: Library (Lib)
files: compiler.transformer.patch
keywords: patch
messages: 93034
nosy: kees
severity: normal
status: open
title: compiler.transformer dict key bug d[1,] = 1
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file14957/compiler.transformer.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6978>
_______________________________________
From report at bugs.python.org Wed Sep 23 18:04:44 2009
From: report at bugs.python.org (Benjamin)
Date: Wed, 23 Sep 2009 16:04:44 +0000
Subject: [New-bugs-announce] [issue6979] Passing output arguments to an
ActiveX application
In-Reply-To: <1253721884.72.0.921997932907.issue6979@psf.upfronthosting.co.za>
Message-ID: <1253721884.72.0.921997932907.issue6979@psf.upfronthosting.co.za>
New submission from Benjamin <benjamin.caron at laposte.net>:
Hi.
I hope I'm in the good thing to expose my problem...
I try to make a script in Python working under ControlDesk, a dSpace
simulator.
In this script I call an ActiveX application given by an external
software, System Monitor, to get some information from my ECU (Engine
Control Unit).
I can access to the ActiveX, I can call functions but only ones which
don't need output argument.
When I use functions which need only input argument, it's working
perfectly.
If I want to use functions which need some output argument, I have a
message error from Python...
========================================================================
Here is an example of a working script:
***************************************
import os
import win32com.client
if __name__ == '__main__':
print ""
Kit = "C:\\U\\TNR_MES_2009\\THR2RAT11BA01.m"
SysMonApp = win32com.client.Dispatch("System Monitor API")
if SysMonApp == None:
print "Pas d'instance System Monitor"
#endif
Err = SysMonApp.SetLiveUpdates(True)
if Err != 0:
print Err
#endif
print "LiveUpdates Actif"
Err = SysMonApp.MatlabImport(Kit)
if Err !=0:
print Err
#endif
print "Import kit .m termine"
SysMonApp = None
print "Fin du script"
#endif
========================================================================
Here is an example of a NON-working script:
import os
import win32com.client
from ctypes import *
if __name__ == '__main__':
print ""
Kit = "C:\\U\\TNR_MES_2009\\THR2RAT11BA01.m"
SysMonApp = win32com.client.Dispatch("System Monitor API")
if SysMonApp == None:
print "Pas d'instance System Monitor"
#endif
#OnlineSt = False
OnlineSt = c_double()
Err = SysMonApp.GetOnline(byref(OnlineSt))
if Err != 0:
print Err
#endif
if OnlineSt == True:
print "ECU Online"
else:
print "ECU Offline"
#endif
SysMonApp = None
print "Fin du script"
#endif
========================================================================
The error message is:
Traceback (most recent call last):
File "C:\Python26\Lib\site-
packages\pythonwin\pywin\framework\scriptutils.py", line 325, in
RunScript
exec codeObject in __main__.__dict__
File "C:\U\TNR_MES_2009\EssaiSysMonSeul_Output_KO.py", line 16, in
<module>
Err = SysMonApp.GetOnline(byref(OnlineSt))
File "<COMObject System Monitor API>", line 2, in GetOnline
TypeError: Objects of type 'CArgObject' can not be converted to a COM
VARIANT
========================================================================
As you can see I use the ctype library to try pass output argument,
using byref.
But I also try to pass argument directly under python, without ctypes:
OnlineSt = False
Err = SysMonApp.GetOnline(OnlineSt)
and I had the folowing error message:
Traceback (most recent call last):
File "C:\Python26\Lib\site-
packages\pythonwin\pywin\framework\scriptutils.py", line 325, in
RunScript
exec codeObject in __main__.__dict__
File "C:\U\TNR_MES_2009\EssaiSysMonSeul_Output_KO.py", line 16, in
<module>
Err = SysMonApp.GetOnline(OnlineSt)
File "<COMObject System Monitor API>", line 2, in GetOnline
com_error: (-2147352571, 'Le type ne correspond pas.', None, 1)
========================================================================
The help for the activeX function explain that the output arguments
need to be pass as pointer:
GetOnline
Returns whether the ECU is online or not.
Arguments:
bool* bResult - whether the ECU is online or offline.
Do you have any idea to solve this problem?
Many thanks
Benjamin
----------
components: Library (Lib)
messages: 93043
nosy: benji13
severity: normal
status: open
title: Passing output arguments to an ActiveX application
type: compile error
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6979>
_______________________________________
From report at bugs.python.org Wed Sep 23 20:30:25 2009
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 23 Sep 2009 18:30:25 +0000
Subject: [New-bugs-announce] [issue6980] fix ctypes build failure on
armel-linux-gnueabi with -mfloat-abi=softfp
In-Reply-To: <1253730625.9.0.970320332999.issue6980@psf.upfronthosting.co.za>
Message-ID: <1253730625.9.0.970320332999.issue6980@psf.upfronthosting.co.za>
New submission from Matthias Klose <doko at debian.org>:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41443
should be imported.
I'm checking this in on the 2.6 branch for the upcoming 2.6.3 release.
----------
assignee: theller
components: ctypes
messages: 93047
nosy: doko, theller
severity: normal
status: open
title: fix ctypes build failure on armel-linux-gnueabi with -mfloat-abi=softfp
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6980>
_______________________________________
From report at bugs.python.org Wed Sep 23 21:35:03 2009
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 23 Sep 2009 19:35:03 +0000
Subject: [New-bugs-announce] [issue6981] locale.getdefaultlocale() envvars
default code and documentation mismatch
In-Reply-To: <1253734503.58.0.404575668112.issue6981@psf.upfronthosting.co.za>
Message-ID: <1253734503.58.0.404575668112.issue6981@psf.upfronthosting.co.za>
New submission from Ville Skytt? <ville.skytta at iki.fi>:
The default list of locale.getdefaultlocale() is documented to be the
one of GNU gettext; in the source docs in Python 2.7 trunk:
"envvars defaults to the search path used in GNU gettext; it must
always contain the variable name 'LANG'."
...and at http://docs.python.org/dev/library/locale.html in addition to
that:
"The GNU gettext search path contains 'LANGUAGE', 'LC_ALL',
'LC_CTYPE', and 'LANG', in that order."
This is correct, cf.
http://www.gnu.org/software/gettext/manual/gettext.html#Locale-Environment-Variables
However, the code in locale.py does not match the documentation; the
patch in issue #1166948 (svn r39572) moved LANGUAGE to the end of the
list. I suggest putting it back at the beginning as documented (the
other change in r39572 is ok).
The py3k branch appears to have the same problem.
----------
components: Library (Lib)
messages: 93048
nosy: scop
severity: normal
status: open
title: locale.getdefaultlocale() envvars default code and documentation mismatch
type: behavior
versions: Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6981>
_______________________________________
From report at bugs.python.org Wed Sep 23 22:31:41 2009
From: report at bugs.python.org (egreen)
Date: Wed, 23 Sep 2009 20:31:41 +0000
Subject: [New-bugs-announce] [issue6982] make clean does not remove pickle
files
In-Reply-To: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
Message-ID: <1253737901.18.0.867547962916.issue6982@psf.upfronthosting.co.za>
New submission from egreen <egreen at operamail.com>:
make clean and make distclean don't remove the grammar pickles generated
by load_grammar in Lib/lib2to3/pgen2/driver.py
(Lib/lib2to3/Grammar3.2.0.alpha.0.pickle,
Lib/lib2to3/PatternGrammar3.2.0.alpha.0.pickle).
Proposed patch attached. It removes all *.pickle files, which I assume
is safe. (Patch also corrects a comment.)
----------
components: 2to3 (2.x to 3.0 conversion tool), Build
files: clean-pickles.patch
keywords: patch
messages: 93049
nosy: egreen
severity: normal
status: open
title: make clean does not remove pickle files
versions: Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14960/clean-pickles.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6982>
_______________________________________
From report at bugs.python.org Thu Sep 24 02:23:43 2009
From: report at bugs.python.org (Stef Walter)
Date: Thu, 24 Sep 2009 00:23:43 +0000
Subject: [New-bugs-announce] [issue6983] Add specific get_platform() for
freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
New submission from Stef Walter <stef at memberwebs.com>:
In Lib/distutils/util.py in the get_platform() function there's OS
specific code to create a string which describes the current platform.
This usually includes the OS + version + arch.
FreeBSD specific code is missing from this function. Currently
get_platform() returns a string specific to the security patch level of
freebsd. For example:
freebsd-7.2-RELEASE-p3-i386
This results in eggs that only work on a specific patch level release of
FreeBSD and are not portable between (for example) 7.2-RELEASE-p2 and
7.2-RELEASE-p3.
However FreeBSD is actually binary compatible within a major version
number. For example 7.1 and 7.2 are binary compatible.
This patch adds freebsd specific code to get_platform() after which it
will return a string like:
freebsd-7-i386
----------
assignee: tarek
components: Distutils
files: patch-python-distutils-osrel.diff
keywords: patch
messages: 93050
nosy: stefw, tarek
severity: normal
status: open
title: Add specific get_platform() for freebsd
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14961/patch-python-distutils-osrel.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________
From report at bugs.python.org Thu Sep 24 07:41:45 2009
From: report at bugs.python.org (Yinon Ehrlich)
Date: Thu, 24 Sep 2009 05:41:45 +0000
Subject: [New-bugs-announce] [issue6984] typo in Unicode HOWTO
In-Reply-To: <1253770905.47.0.191308978171.issue6984@psf.upfronthosting.co.za>
Message-ID: <1253770905.47.0.191308978171.issue6984@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:
at http://docs.python.org/dev/3.0/howto/unicode.html:
Uniode should be Unicode
----------
assignee: georg.brandl
components: Documentation
messages: 93052
nosy: Yinon, georg.brandl
severity: normal
status: open
title: typo in Unicode HOWTO
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6984>
_______________________________________
From report at bugs.python.org Thu Sep 24 12:38:13 2009
From: report at bugs.python.org (Krzysztof Szawala)
Date: Thu, 24 Sep 2009 10:38:13 +0000
Subject: [New-bugs-announce] [issue6985] range() fails with long integers
In-Reply-To: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
Message-ID: <1253788693.35.0.162320870047.issue6985@psf.upfronthosting.co.za>
New submission from Krzysztof Szawala <kszawala at slb.com>:
range() method fails with the following error message:
"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items
"
when passing a valid integer value of 9999999999.
This value is obtained from OptParse command-line option as a valid
ingeter.
Applies to both Windows and Linux (32 and 64-bit).
----------
components: Interpreter Core
messages: 93063
nosy: kszawala
severity: normal
status: open
title: range() fails with long integers
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6985>
_______________________________________
From report at bugs.python.org Thu Sep 24 13:21:06 2009
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Sep 2009 11:21:06 +0000
Subject: [New-bugs-announce] [issue6986] _json crash on scanner/encoder
initialization error
In-Reply-To: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
Message-ID: <1253791266.79.0.0913001727674.issue6986@psf.upfronthosting.co.za>
New submission from STINNER Victor <victor.stinner at haypocalc.com>:
scanner_init() and encoder_init() don't manage errors correctly.
scanner_init() gets context.encoding argument without checking context
type, nor GetAttrString() error. It should check for NULL result...
which is done in the same function for other attributes (strict,
object_hook, object_pairs_hook, parse_float, parse_int, parse_constant).
Example to reproduce the crash:
import _json
_json.make_scanner(1)
encoder_init() copies a refence (for each argument) without incrementing
the reference counter. And then encoder_clear() decrements the
reference, counter, which may crash Python.
Example to reproduce the crash:
import _json
_json.make_encoder(
(False, True),
-826484143518891896,
-56.0,
"a",
)
# do anything creating/destroying new objects
" abc ".strip()
len(" xef ".strip())
Attached patches for the crashes.
----------
files: _json_encoder_init.patch
keywords: patch
messages: 93068
nosy: haypo
severity: normal
status: open
title: _json crash on scanner/encoder initialization error
Added file: http://bugs.python.org/file14964/_json_encoder_init.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6986>
_______________________________________
From report at bugs.python.org Thu Sep 24 14:05:23 2009
From: report at bugs.python.org (dorina)
Date: Thu, 24 Sep 2009 12:05:23 +0000
Subject: [New-bugs-announce] [issue6987] Idle not start
In-Reply-To: <1253793923.16.0.575458471833.issue6987@psf.upfronthosting.co.za>
Message-ID: <1253793923.16.0.575458471833.issue6987@psf.upfronthosting.co.za>
New submission from dorina <dorina_n2005 at yahoo.com>:
Hello!
I installed Python31 on WinXp,but IDLE doesn't start. I tried at
command prompt
python Lib\idlelib\idle.py
the result is in attachement.
please help...
thanks.
----------
components: IDLE
files: err1.JPG
messages: 93072
nosy: dorina_n2005
severity: normal
status: open
title: Idle not start
versions: Python 3.1
Added file: http://bugs.python.org/file14966/err1.JPG
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6987>
_______________________________________
From report at bugs.python.org Thu Sep 24 15:54:08 2009
From: report at bugs.python.org (Bill Fenner)
Date: Thu, 24 Sep 2009 13:54:08 +0000
Subject: [New-bugs-announce] [issue6988] shlex.split() converts unicode
input to UCS-4 output with varying byte order
In-Reply-To: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
Message-ID: <1253800448.93.0.534160477927.issue6988@psf.upfronthosting.co.za>
New submission from Bill Fenner <fenner at gmail.com>:
In python 2.5, shlex handled unicode input fine:
Python 2.5.1 (r251:54863, Jun 15 2008, 18:24:51)
[GCC 4.3.0 20080428 (Red Hat 4.3.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split( u'Hello, World!' )
['Hello,', 'World!']
In python 2.6, shlex turns unicode input into UCS-4 output, thus utterly
confusing execl:
Python 2.6 (r26:66714, Jun 8 2009, 16:07:29)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split( u'Hello, World' )
['H\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00,\x00\x00\x00',
'\x00\x00\x00W\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00']
Even weirder, the two return strings have different byte order (see
'H\x00\x00\x00' vs. '\x00\x00\x00W'!)
----------
components: Library (Lib)
messages: 93074
nosy: fenner
severity: normal
status: open
title: shlex.split() converts unicode input to UCS-4 output with varying byte order
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6988>
_______________________________________
From report at bugs.python.org Thu Sep 24 21:07:35 2009
From: report at bugs.python.org (Ashish)
Date: Thu, 24 Sep 2009 19:07:35 +0000
Subject: [New-bugs-announce] [issue6989] Python-2.6.2
In-Reply-To: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
Message-ID: <1253819255.25.0.700651410183.issue6989@psf.upfronthosting.co.za>
New submission from Ashish <pimple9 at gmail.com>:
I am getting error while compiling python-2.6.2
OS - Solaris 10 8/07 s10s_u4wos_12b SPARC
bash-3.00$ isainfo -v
64-bit sparcv9 applications
asi_blk_init
32-bit sparc applications
asi_blk_init v8plus div32 mul32
Paths and defined
PATH=/usr/local/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/sfw/bin:/usr/sfw/sbin:/opt/SUNWspci/bin:/usr/ccs/bin:/usr/bin:$PATH
export LD_LIBRARY_PATH="/usr/lib/sparcv9:/usr/local/lib/sparcv9"
export LDFLAGS="-mcpu=v9 -m64"
export LDDFLAGS="-mcpu=v9 -m64 -G"
export CC="gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"
Configure seems to be runs fine. ( Attched File for configure )
sudo ./configure --with-universal-archs="64 bit"
--prefix=/opt/Python-2.6.2/
But getting error after running make
bash-3.00$ sudo make
\gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 -c -fno-strict-aliasing
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Objects/floatobject.o Objects/floatobject.c
/var/tmp//ccBDYDRE.s: Assembler messages:
/var/tmp//ccBDYDRE.s:7339: Error: Illegal operands: There are only 32
single precision f registers; [0-31]
*** Error code 1
make: Fatal error: Command failed for target `Objects/floatobject.o'
Please advice.
----------
components: Installation
files: Configure.txt
messages: 93088
nosy: ashish
severity: normal
status: open
title: Python-2.6.2
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file14968/Configure.txt
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6989>
_______________________________________
From report at bugs.python.org Fri Sep 25 05:28:00 2009
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 25 Sep 2009 03:28:00 +0000
Subject: [New-bugs-announce] [issue6990] threading.local subclasses don't
cleanup their state and it gets recycled
In-Reply-To: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
Message-ID: <1253849280.29.0.910949880833.issue6990@psf.upfronthosting.co.za>
New submission from Philip Jenvey <pjenvey at users.sourceforge.net>:
When threading.local subclasses are cleared during a reference cycle the
local's internal key is nulled before the local is deallocated. That's a
problem because local only deletes its state (ldicts) from threads
during deallocation, and doesn't do so at all when its key is null.
So leaving ldicts around is one thing, but what's worse is they can be
recycled by new local objects later -- since ldicts are mapped to
threadstates by said key, and said key is based on the local's pointer.
If a new local is malloced at the old one's address it can end up with
the original's ldicts (depending on which thread it's allocated from).
Attached is a test against trunk showing this. Should we delete the
ldicts during clear, recreate the key during dealloc, or something else?
----------
components: Interpreter Core
files: derived_local_cycle_dealloc.diff
keywords: patch
messages: 93099
nosy: amaury.forgeotdarc, pjenvey
severity: normal
status: open
title: threading.local subclasses don't cleanup their state and it gets recycled
type: security
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file14969/derived_local_cycle_dealloc.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6990>
_______________________________________
From report at bugs.python.org Fri Sep 25 07:29:27 2009
From: report at bugs.python.org (Naoki INADA)
Date: Fri, 25 Sep 2009 05:29:27 +0000
Subject: [New-bugs-announce] [issue6991] logging encoding failes some
situation
In-Reply-To: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
Message-ID: <1253856567.46.0.952425276077.issue6991@psf.upfronthosting.co.za>
New submission from Naoki INADA <songofacandy at gmail.com>:
When stream is codecs.writer object, stream.write(string) does
string.decode() internally and it may cause UnicodeDecodeError.
Then, fallback to utf-8 is not good.
I think good fallback logic is:
* When message is unicode, message.encode(stream.encoding or 'ascii',
'backslashreplace')
* When message is bytes, message.encode('string_escape')
Attached patch contains this logic, refactoring and test.
----------
components: Library (Lib)
files: logging_encode.patch
keywords: patch
messages: 93100
nosy: naoki
severity: normal
status: open
title: logging encoding failes some situation
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file14970/logging_encode.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6991>
_______________________________________
From report at bugs.python.org Fri Sep 25 17:03:13 2009
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 25 Sep 2009 15:03:13 +0000
Subject: [New-bugs-announce] [issue6992] multiple authors in setup.by
In-Reply-To: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
Message-ID: <1253890993.76.0.809715312651.issue6992@psf.upfronthosting.co.za>
New submission from anatoly techtonik <techtonik at gmail.com>:
setup.py should allow to specify multiple authors in package description.
----------
assignee: tarek
components: Distutils
messages: 93105
nosy: tarek, techtonik
severity: normal
status: open
title: multiple authors in setup.by
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________
From report at bugs.python.org Fri Sep 25 17:52:21 2009
From: report at bugs.python.org (Nikolay Dyankov)
Date: Fri, 25 Sep 2009 15:52:21 +0000
Subject: [New-bugs-announce] [issue6993] importing of "time" module is
terribly slow
In-Reply-To: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>
Message-ID: <1253893941.48.0.714052811653.issue6993@psf.upfronthosting.co.za>
New submission from Nikolay Dyankov <ndyankov at gmail.com>:
The behaviour described below is not always reproduced.
The attached test script simply tries to import a couple of dns-python
modules, which in turn import other ones. No code is being executed.
You expect it to exit for less than a second but it does not. Instead,
it hangs when "time" module is being imported (eventually it exits after
a long time).
Attached are stdout log and system call log produced by strace with
timestamps.
I don't know what causes it but I'm getting it on at least two machines
(the second being virtual):
$ cat /etc/fedora-release
Fedora release 10 (Cambridge)
$ uname -a
Linux kiki 2.6.27.30-170.2.82.fc10.i686.PAE #1 SMP Mon Aug 17 08:24:23
EDT 2009 i686 i686 i386 GNU/Linux
$ python -c "import sys; print sys.version"
2.5.2 (r252:60911, Sep 30 2008, 15:41:38)
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)]
$ cat /etc/redhat-release
CentOS release 5.3 (Final)
$ uname -a
Linux proxy.sc.com 2.6.18-128.el5 #1 SMP Wed Jan 21 10:44:23 EST 2009
i686 i686 i386 GNU/Linux
$ python -c "import sys; print sys.version"
2.4.3 (#1, Jan 21 2009, 01:10:13)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]
I don't think it's related to dns-python(that's why I am posting it
here) but for reference the version used is 1.7.1.
The timestamps in stdout.log and strace.log clearly show the slowdown:
# strace.log
18:18:53 ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfac06b0) = -1 EINVAL
(Invalid argument)
18:18:53 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e4f000
18:18:53 read(6, "F\t\262\276\261s\223I"..., 4096) = 8
18:19:01 read(6, ")v\244\36\v=U\336"..., 4096) = 8
18:19:11 close(6) = 0
18:19:11 munmap(0xb7e4f000, 4096) = 0
18:19:11 gettimeofday({1253891951, 431529}, NULL) = 0
# stdout.log
18:18:53 dns.entropy
18:18:53 time
18:19:11 hashlib
18:19:11 _hashlib
----------
components: Library (Lib)
files: dns-test.tar.gz
messages: 93108
nosy: ndyankov
severity: normal
status: open
title: importing of "time" module is terribly slow
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file14972/dns-test.tar.gz
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6993>
_______________________________________
From report at bugs.python.org Fri Sep 25 18:00:19 2009
From: report at bugs.python.org (Natalia B. Bidart)
Date: Fri, 25 Sep 2009 16:00:19 +0000
Subject: [New-bugs-announce] [issue6994] enumerate dosctring has a typo
In-Reply-To: <1253894419.07.0.333044923608.issue6994@psf.upfronthosting.co.za>
Message-ID: <1253894419.07.0.333044923608.issue6994@psf.upfronthosting.co.za>
New submission from Natalia B. Bidart <nataliabidart at gmail.com>:
Current docstring states:
Return an enumerate object. iterable must be an other object that
supports iteration.
It should be:
Return an enumerate object. iterable must be another object that
supports iteration.
----------
assignee: georg.brandl
components: Documentation
messages: 93109
nosy: georg.brandl, nessita
severity: normal
status: open
title: enumerate dosctring has a typo
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6994>
_______________________________________
From report at bugs.python.org Fri Sep 25 19:41:49 2009
From: report at bugs.python.org (bahaelaila7)
Date: Fri, 25 Sep 2009 17:41:49 +0000
Subject: [New-bugs-announce] [issue6995] Python 3.1 interpreter crashes on
windows
In-Reply-To: <1253900509.04.0.855711882942.issue6995@psf.upfronthosting.co.za>
Message-ID: <1253900509.04.0.855711882942.issue6995@psf.upfronthosting.co.za>
New submission from bahaelaila7 <bahaelaila7 at gmail.com>:
python3.1 (both amd64 and 32-bit edition) crash whenever i try to start
python.exe.
i've tried that on many windows editions, XP, Vista, Seven,,, for each,
64 and 32 bits editions , virtually and normally...........always get
the same error, as shown in
http://img33.imageshack.us/img33/7498/screenshot1za.png
----------
files: Screenshot-1.png
messages: 93117
nosy: bahaelaila7
severity: normal
status: open
title: Python 3.1 interpreter crashes on windows
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14974/Screenshot-1.png
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6995>
_______________________________________
From report at bugs.python.org Fri Sep 25 19:43:21 2009
From: report at bugs.python.org (Deepak Parashar)
Date: Fri, 25 Sep 2009 17:43:21 +0000
Subject: [New-bugs-announce] [issue6996] Python 2.6.2 & 3.1.1 Installer
In-Reply-To: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>
Message-ID: <1253900601.22.0.618435318544.issue6996@psf.upfronthosting.co.za>
New submission from Deepak Parashar <deepakp at sybase.com>:
Need Python 2.6.2 & 3.1.1 Installer for Windows 64 Bit (for Pentium /
Intel CPU)
----------
components: Installation, Windows
messages: 93118
nosy: deepakp
severity: normal
status: open
title: Python 2.6.2 & 3.1.1 Installer
type: resource usage
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6996>
_______________________________________
From report at bugs.python.org Fri Sep 25 21:17:02 2009
From: report at bugs.python.org (Dylan)
Date: Fri, 25 Sep 2009 19:17:02 +0000
Subject: [New-bugs-announce] [issue6997] python26 compiled on snow leopard
x86_64
In-Reply-To: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>
Message-ID: <1253906222.81.0.207824512361.issue6997@psf.upfronthosting.co.za>
New submission from Dylan <dmahoney74 at gmail.com>:
Hi guys,
I consider myself self-taught average geek. after a long time trying
many things to get python2.6.2 to build with macports it fails every
time until i used this specific argument in the work folder below
cd
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2
configure and make as followed (this is what i know works, i know there
is possibly a shorter more proficient way to do this so don't blame me i
just got this thing to compile is all.)
sudo DEFAULT_ARCH=x86_64 MACOSX_DEPLOYMENT_TARGET=10.6 ./configure
--with-universal-archs=64-bit
Please share this among devs at macports Thought I'd mention my success
here first.
- Dylan Mahoney
----------
components: Build
messages: 93128
nosy: monway
severity: normal
status: open
title: python26 compiled on snow leopard x86_64
type: feature request
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6997>
_______________________________________
From report at bugs.python.org Fri Sep 25 21:58:00 2009
From: report at bugs.python.org (Michael Markert)
Date: Fri, 25 Sep 2009 19:58:00 +0000
Subject: [New-bugs-announce] [issue6998] Bug in Tutorial (introduction.rst)
In-Reply-To: <1253908680.28.0.431854993556.issue6998@psf.upfronthosting.co.za>
Message-ID: <1253908680.28.0.431854993556.issue6998@psf.upfronthosting.co.za>
New submission from Michael Markert <markert.michael at gmail.com>:
There is a `print` statement in line 225 of introduction.rst instead of
a print function, rendering the snippet buggy in Python3.
----------
assignee: georg.brandl
components: Documentation
messages: 93132
nosy: cofi, georg.brandl
severity: normal
status: open
title: Bug in Tutorial (introduction.rst)
versions: Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6998>
_______________________________________
From report at bugs.python.org Fri Sep 25 22:07:58 2009
From: report at bugs.python.org (Andrew McNabb)
Date: Fri, 25 Sep 2009 20:07:58 +0000
Subject: [New-bugs-announce] [issue6999] TypeError in pathfix.py
In-Reply-To: <1253909278.7.0.408125784392.issue6999@psf.upfronthosting.co.za>
Message-ID: <1253909278.7.0.408125784392.issue6999@psf.upfronthosting.co.za>
New submission from Andrew McNabb <amcnabb at mcnabbs.org>:
Tools/scripts/pathfix.py crashes with a TypeError:
Traceback (most recent call last):
File "Tools/scripts/pathfix.py", line 149, in <module>
main()
File "Tools/scripts/pathfix.py", line 54, in main
if recursedown(arg): bad = 1
File "Tools/scripts/pathfix.py", line 82, in recursedown
elif ispython(name):
File "Tools/scripts/pathfix.py", line 64, in ispython
return ispythonprog.match(name) >= 0
TypeError: unorderable types: NoneType() >= int()
It looks like an easy fix would be to change line 64 from:
return ispythonprog.match(name) >= 0
to:
return bool(ispythonprog.match(name))
After making this change, I got another crash, this time due to a
UnicodeDecodeError. Apparently, the file
(Demo/distutils/test2to3/setup.py) has a character encoded in ISO-8859.
Since pathfix.py is only concerned with ASCII text in the first line of
a file, it seems that it should probably operate on bytes instead of
unicode strings.
By the way, it's a little odd (but not technically invalid) that the
format string on line 146 is: '#! %s\n'. I would normally expect to see
no whitespace: '#!%s\n'.
Anyway, I'm attaching a patch that fixes addresses all of the above
issues and which seems to make pathfix.py work for all files in the
Python 3.1.1 source tree.
----------
components: Demos and Tools
files: python-3.1.1-pathfix.patch
keywords: patch
messages: 93134
nosy: amcnabb
severity: normal
status: open
title: TypeError in pathfix.py
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file14975/python-3.1.1-pathfix.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6999>
_______________________________________
From report at bugs.python.org Fri Sep 25 22:52:42 2009
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 25 Sep 2009 20:52:42 +0000
Subject: [New-bugs-announce] [issue7000] optional second argument of
string.keywords not documented
In-Reply-To: <1253911962.13.0.839858916311.issue7000@psf.upfronthosting.co.za>
Message-ID: <1253911962.13.0.839858916311.issue7000@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
string.capwords has an optional second argument, sep, which is not
documented
----------
assignee: georg.brandl
components: Documentation
messages: 93139
nosy: MLModel, georg.brandl
severity: normal
status: open
title: optional second argument of string.keywords not documented
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7000>
_______________________________________
From report at bugs.python.org Fri Sep 25 23:02:51 2009
From: report at bugs.python.org (Gregor Lingl)
Date: Fri, 25 Sep 2009 21:02:51 +0000
Subject: [New-bugs-announce] [issue7001] turtle.py bug-fixes,
backported from 3.1 [issue5923]
In-Reply-To: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
Message-ID: <1253912571.33.0.993006582742.issue7001@psf.upfronthosting.co.za>
New submission from Gregor Lingl <gregorlingl at users.sourceforge.net>:
Among the changes of turtle.py from Python 3.0 to Python 3.1 there were
three bugfixes. Those bugs appear also in the Python 2.6 version of
turtle.py
imho these should be fixed for Python 2.6.3
The appended diffs contain the (backported) fixes of these bugs,
(1) in TurtleScreen.update()
(2) in TurtleScreen.onkey()
(3) in _Screen.__init__ and _Screen.setup
The last one entails the need of adding one line into turtleDemo.py.
This change does not affect the correct working of turtleDemo with the
Python 2.6.2 turtle and demos.
----------
files: turtle_262_263.diff
keywords: patch
messages: 93142
nosy: gregorlingl
severity: normal
status: open
title: turtle.py bug-fixes, backported from 3.1 [issue5923]
versions: Python 2.6
Added file: http://bugs.python.org/file14976/turtle_262_263.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7001>
_______________________________________
From report at bugs.python.org Sat Sep 26 02:36:09 2009
From: report at bugs.python.org (Ashish)
Date: Sat, 26 Sep 2009 00:36:09 +0000
Subject: [New-bugs-announce] [issue7002] help me to set variables - 64 bit
In-Reply-To: <1253925369.17.0.283500501852.issue7002@psf.upfronthosting.co.za>
Message-ID: <1253925369.17.0.283500501852.issue7002@psf.upfronthosting.co.za>
New submission from Ashish <pimple9 at gmail.com>:
Hello,
I am compiling python 2.6.2 and 3.1.
I tried to compile 64 bit ( ELF 64-bit )python but it gets 32 bit ( ELF
32-bit ).
bash-3.00$ sudo file /usr/local/Python-2.6.2/bin/python
/usr/local/Python-2.6.2/bin/python: ELF 32-bit MSB executable, PowerPC
or cisco 4500, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked
(uses shared libs), not stripped
Will you please help me to set variables and parameters to compile
python for 64 bit on following architect
1. Linux - OS - Red Hat Enterprise Linux AS release 4 (Nahant Update 6)
Arch - ppc64
2. HP-UX - OS - HP-UX hpi64qa B.11.23 U ia64 (tb)
3. AIX 5 - AIX 5300-07
Thanks
Ashish
----------
components: Build
messages: 93151
nosy: ashish
severity: normal
status: open
title: help me to set variables - 64 bit
type: compile error
versions: Python 2.6, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7002>
_______________________________________
From report at bugs.python.org Sat Sep 26 04:57:40 2009
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Sep 2009 02:57:40 +0000
Subject: [New-bugs-announce] [issue7003] finish documentation of user local
paths
In-Reply-To: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>
Message-ID: <1253933860.16.0.325369023174.issue7003@psf.upfronthosting.co.za>
New submission from Benjamin Peterson <benjamin at python.org>:
This appears at the end of the site documentation:
XXX Update documentation XXX document python -m site ?user-base ?user-site
It should be remedied.
----------
assignee: christian.heimes
messages: 93153
nosy: benjamin.peterson, christian.heimes
severity: normal
status: open
title: finish documentation of user local paths
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7003>
_______________________________________
From report at bugs.python.org Sun Sep 27 02:04:59 2009
From: report at bugs.python.org (Jon Parise)
Date: Sun, 27 Sep 2009 00:04:59 +0000
Subject: [New-bugs-announce] [issue7004] Py_RETURN_BOOL() convenience macro
In-Reply-To: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
Message-ID: <1254009899.52.0.128079117198.issue7004@psf.upfronthosting.co.za>
New submission from Jon Parise <jon at indelible.org>:
I've sometimes found it useful to define a convenience macro named
Py_RETURN_BOOL(x) which is essentially:
#define Py_RETURN_BOOL(x) if (x) Py_RETURN_TRUE; else Py_RETURN_FALSE
It's useful for implementing functions which return Boolean values based
on simple conditions.
I think it's readable and doesn't detract from regular program flow,
although it does hide the condition behind a macro, which detracts a bit
from the code's debug-ability.
----------
components: Interpreter Core
files: Py_RETURN_BOOL.patch
keywords: patch
messages: 93164
nosy: jon
severity: normal
status: open
title: Py_RETURN_BOOL() convenience macro
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file14982/Py_RETURN_BOOL.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7004>
_______________________________________
From report at bugs.python.org Sun Sep 27 08:14:04 2009
From: report at bugs.python.org (Mats Kindahl)
Date: Sun, 27 Sep 2009 06:14:04 +0000
Subject: [New-bugs-announce] [issue7005] ConfigParser does not handle
options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
New submission from Mats Kindahl <mats at sun.com>:
When ConfigParser is used to read in a my.cnf file (MySQL Server
Configuration File), it fails for options that do not have value.
ConfigParser is designed to require a value for each option, but some
systems, such as MySQL option file reader, accepts options without
values. Reading a my.cnf file is almost certain to include options
without values. The server can accept options with values even though
the value is not necessary, but there are some tools that do not allow
values for options that do not require them.
There is an attached patch that optionally will allow options to not
have a value. In order to distinguish options with no value from options
with the empty string, None is assigned to options without values.
The default behavior is to not allow options without values.
----------
components: Library (Lib)
files: cfgparser-1.patch
keywords: patch
messages: 93168
nosy: mkindahl
severity: normal
status: open
title: ConfigParser does not handle options without values
versions: Python 2.6
Added file: http://bugs.python.org/file14985/cfgparser-1.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________
From report at bugs.python.org Sun Sep 27 16:23:55 2009
From: report at bugs.python.org (Milko Krachounov)
Date: Sun, 27 Sep 2009 14:23:55 +0000
Subject: [New-bugs-announce] [issue7006] The replacement suggested for
callable(x) in py3k is not equivalent
In-Reply-To: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
Message-ID: <1254061435.03.0.676892081826.issue7006@psf.upfronthosting.co.za>
New submission from Milko Krachounov <python at milko.3mhz.net>:
hasattr(x, '__call__') has been suggested as a replacement for
callable(x) in the documentation and in the warning when running
python2.6 with -3. It is also what 2to3 replaces it with. However, the
two are not equivalent.
1. I can add a __call__ attribute to my object with "obj.__call__ =
lambda x:x". That will not make the object callable, callable() on
Python 2.6 returns False, but hasattr(obj, '__call__') returns True.
2. I can implement a __getattr__ that returns something for every
possible attribute name. Again, this doesn't make the object callable,
nor does callable(obj) in Python 2.6 return True.
I think a closer replacement for "callable(x)" would be "'__call__' in
vars(type(x))".
----------
assignee: georg.brandl
components: 2to3 (2.x to 3.0 conversion tool), Documentation, Interpreter Core
messages: 93171
nosy: georg.brandl, milko.krachounov
severity: normal
status: open
title: The replacement suggested for callable(x) in py3k is not equivalent
type: behavior
versions: Python 2.6, Python 3.0, Python 3.1
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7006>
_______________________________________
From report at bugs.python.org Sun Sep 27 19:08:59 2009
From: report at bugs.python.org (Mitchell Model)
Date: Sun, 27 Sep 2009 17:08:59 +0000
Subject: [New-bugs-announce] [issue7007] Tiny inconsistency in the
orthography of "url encoded" in the doc of urllib.parse
In-Reply-To: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>
Message-ID: <1254071339.25.0.500752949705.issue7007@psf.upfronthosting.co.za>
New submission from Mitchell Model <mlm at acm.org>:
The documentation of urllib.parse contains:
URL encoded
a ?url-encoded? string
I am not sure what the official usage is, either in Python or more
generally. Actually, in formal W3C documents the term used is percent-
encoding (with the hyphen, even when used as a noun). I don't expect
anyone to use "percent-encoding" but maybe, especially as an adjective,
the phrase in Python documentation should consistently be "url-encoded"?
----------
messages: 93179
nosy: MLModel
severity: normal
status: open
title: Tiny inconsistency in the orthography of "url encoded" in the doc of urllib.parse
versions: Python 3.0, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7007>
_______________________________________
From report at bugs.python.org Sun Sep 27 19:23:26 2009
From: report at bugs.python.org (Nick Devenish)
Date: Sun, 27 Sep 2009 17:23:26 +0000
Subject: [New-bugs-announce] [issue7008] str.title() misbehaves with
apostrophes
In-Reply-To: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
Message-ID: <1254072206.87.0.820338448521.issue7008@psf.upfronthosting.co.za>
New submission from Nick Devenish <N.e.devenish at sussex.ac.uk>:
str.title() capitalizes the first letter after an apostrophe:
>>> "This isn't right".title()
"This Isn'T Right"
The library function string.capwords, which appears to have exactly the
same responsibility, doesn't exhibit this behavior:
>>> string.capwords("This isn't right")
"This Isn't Right"
Tested on 2.6.2 on Mac OS X
----------
messages: 93180
nosy: nickd
severity: normal
status: open
title: str.title() misbehaves with apostrophes
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7008>
_______________________________________
From report at bugs.python.org Mon Sep 28 05:56:46 2009
From: report at bugs.python.org (James G. sack (jim))
Date: Mon, 28 Sep 2009 03:56:46 +0000
Subject: [New-bugs-announce] [issue7009] random.randint docs
In-Reply-To: <1254110206.1.0.201137828001.issue7009@psf.upfronthosting.co.za>
Message-ID: <1254110206.1.0.201137828001.issue7009@psf.upfronthosting.co.za>
New submission from James G. sack (jim) <jgsack at users.sourceforge.net>:
Docs for 2.6.2 (http://docs.python.org/library/random.html?
highlight=random#module-random)
presently say
"""
random.randint(a, b)
Return a random integer N such that a <= N <= b.
"""
It should say
...a <= N < b
I wonder if there are other mistakes there in upper limit docs?
~jim
----------
assignee: georg.brandl
components: Documentation
messages: 93190
nosy: georg.brandl, jgsack
severity: normal
status: open
title: random.randint docs
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7009>
_______________________________________
From report at bugs.python.org Mon Sep 28 09:43:58 2009
From: report at bugs.python.org (Per Rosengren)
Date: Mon, 28 Sep 2009 07:43:58 +0000
Subject: [New-bugs-announce] [issue7010] Rounding when converting float
tuple to str
In-Reply-To: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
Message-ID: <1254123838.49.0.741570253146.issue7010@psf.upfronthosting.co.za>
New submission from Per Rosengren <per.rosengren at gmail.com>:
When a floating point value is stored, the actual value stored is
something at most some small number eps larger or smaller than the
original value. Python knows this, so if it stores 0.1, and then prints
the stored value, it rounds off decimals less significant than eps.
For some reason, if it prints a tuple with the same value, it doesn't do
the rounding properly. This behavior is incorrect, and very annoying for
instance when printing manually entered constants in tuples.
'''Shows that floats in tuples are not rounded like floats.
>>> print(.1)
0.1
>>> print((.1,))
(0.10000000000000001,)
'''
import doctest
doctest.testmod(verbose=True)
----------
components: Interpreter Core
messages: 93193
nosy: scientist47
severity: normal
status: open
title: Rounding when converting float tuple to str
type: behavior
versions: Python 2.6, Python 3.0
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7010>
_______________________________________
From report at bugs.python.org Mon Sep 28 11:21:28 2009
From: report at bugs.python.org (Patrick Gerken)
Date: Mon, 28 Sep 2009 09:21:28 +0000
Subject: [New-bugs-announce] [issue7011] tarinfo has problems with longlinks
In-Reply-To: <1254129688.2.0.826079779508.issue7011@psf.upfronthosting.co.za>
Message-ID: <1254129688.2.0.826079779508.issue7011@psf.upfronthosting.co.za>
New submission from Patrick Gerken <patrick.gerken at computer.org>:
Sadly, I am unable to debug it enough to be able to provide a thorough
test case. I can provide information of how to reproduce the problem on
request. I have a tar file and a diff to tarfile.py with some pdbs that
only get activated in the middle of the file just before the problematic
data.
Installing an egg fails, and setuptools eats the original error.
The original error is this:
ValueError: 'invalid literal for int(): \xcf\xcf\xdf\xfc\xe9\xcd\xa9\xa9'
That happens in the call to next in the class TarFile. Here we read in a
chunk of filedata, and let TarInfo parse it. But the chunk of data is
actually the beginning of an image in the tar file.
Here is a more thorough report of my pdb findings:
Environment:
I created an egg on linux, which resulted in a tar.gz file. Installing
that egg fails, because the tarfile library has problems reading the tar
file. tar itself can extract the full file without problems.
I have a self compiled python 2.4.6.
The last file that is apparently read correctly form TarFile.next, is a
LONGLINK, tarinfo.type == 'L'
This type has a method callback in TarInfo.TYPE_METH, which it uses for
returning the real TarInfo object. That goes into proc_gnulong of
tarfile.py.
This proc_gnulong method calls next again, to get the real file info, I
think.
The next buffer that is read out, contains a file name that is exactly
100chars long, and seems to be a directory, because it has a trailing
slash. but its filetype is '0'.
I suspected the error here, and to cross check, I checked the output of
"tar -tf" on the tar file. I expect tar to return the filenames in the
same order as python reads them in. Before the directory that next seems
to find, there is his parent directory in there. The previous tarinfo
object is exactly about this parent directory. So it looks like, we
actually have a directory entry here.
Enough wild guesses and more observations: The next call of
TarInfo.next() creates a TarInfo object again, here at about line 693,
he checks if the file is a regular file but ends with a slash. If so, he
changes the file type from '0', regular file, to '5', DIRTYPE. He
actually does that with our TarInfo object.
The TarInfo object is created successfully and the next method continues
to run. Then, around line 1650, there is a check, if tarinfo.isreg() or
tarinfo.type not in SUPPORTED_TYPES:...
Here the offset for reading the next TarInfo Buffer is increased by the
size of the actual file size in the tar file. But not for our TarInfo
object, because it is not regular file any longer. If I pad the offset
manually, everything continues to work. But I won't do it this time.
The call to next finishes, and after a while TarInfo.next() is called again.
This time, next tries to read a chunk of data again, but this time, the
chunk of data is an actual file content, it starts with 'GIF89a...',
which makes sense, the directory contains images. Here parsing of the
tar file fails.
----------
components: Library (Lib)
messages: 93198
nosy: do3cc
severity: normal
status: open
title: tarinfo has problems with longlinks
versions: Python 2.4
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7011>
_______________________________________
From report at bugs.python.org Mon Sep 28 14:26:24 2009
From: report at bugs.python.org (Rohde Fischer)
Date: Mon, 28 Sep 2009 12:26:24 +0000
Subject: [New-bugs-announce] [issue7012] Tabs is better than spaces for
identation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
New submission from Rohde Fischer <krdata at gmail.com>:
Although it's probably futile, I'll still give it a try.
I can see in your tutorial that you desire 4 spaces over tabs. I have
never seen a good argument for spaces (and I've seen a lot), so I'll
try to convince that tabs is the way (god damn it we don't live in 1980
any more).
>From the tutorial: "Tabs introduce confusion, and are best left out." -
only if you're switching in the middle of a document, tabs and spaces
are equally confusing (I would say they're the opposite, but ok).
There's no difference on that part.
Then some of the arguments I've heard is that some editors shows tabs
badly, although true, then most proper editors it's possible to adjust
that to your personal preference, removing that possibility you are
removing a nice (although not entirely needed) flexibility.
In a program with 200 lines of code we have roughly 600 extra
keystrokes with spaces, unless using a proper editor which shows tabs
nicely.
Tabs use less space, which is usable when uploading and downloading
code a lot (which you do when using version control).
Posting on forums is a problem with tabs. True, but then you can use
proper utilities for that, and although I don't use forums for code
issues I would seriously question the forum if a code-related forum
didn't convert tabs, and even if it doesn't then I would still use a
pastebin utility, since it offers all those nice features like syntax
highlighting and auto conversion of tabs.
4 spaces is prettier than tabs converted to 8 spaces. True but yet
again most editors can adjust that or actually use 4 spaces per
default, but if I like 2 spaces I can't do that without introducing
confusion, so spaces actually introduces more confusion than tabs.
Good editors makes spaces transparent and behave like tabs, true but
good editors also makes tabs look pretty. But editing manual spaces is
hell compared to the ugliness of a bad editor, and I prefer usability
over pretty.
This don't look good with tabs
string = "some multiline whatever string"+
" and continued"
string = "some multiline whatever string"+
" and continued"
True, but not unreadable, and if insisting on pretty you can switch to
tabs for identation spaces for multiline prettyness.
So until I see good arguments for spaces I would really like to see the
standard switched to tabs, since I see no good reason for claiming
spaces is better ... actually so see reason to claim otherwise.
----------
components: None
messages: 93205
nosy: rohdef
severity: normal
status: open
title: Tabs is better than spaces for identation
type: feature request
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7012>
_______________________________________
From report at bugs.python.org Mon Sep 28 18:40:31 2009
From: report at bugs.python.org (Andrei Korostelev)
Date: Mon, 28 Sep 2009 16:40:31 +0000
Subject: [New-bugs-announce] [issue7013] Httplib read routine is not
tolerant to not well-formed chunked http responses.
In-Reply-To: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>
Message-ID: <1254156031.22.0.214966362027.issue7013@psf.upfronthosting.co.za>
New submission from Andrei Korostelev <andrei at korostelev.net>:
HTTPResponse._read_chunked cannot handle "slightly" ill-formed HTTP
response not ended with 0 chunk-size. I did not make an analysis what
type of webservers generate such responses, but one of them is bing.com
(former msn.com).
Example correct chunked http response:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
B
first chunk
A
last chunk
0
Example chunked http rsponse not ended with zero length:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
B
first chunk
A
last chunk
Suggested solution: when an empty line is met where a hexadecimal
chunk-size is expected, treat it as the end of HTTP response.
--- C:\Python25\Lib\httplib.py.orig 2008-02-12 20:48:24.000000000 +-0200
+++ C:\Python25\Lib\httplib.py.patched 2009-09-28 18:30:33.000000000 +-0200
@@ -542,12 +542,16 @@
while True:
if chunk_left is None:
line = self.fp.readline()
i = line.find(';')
if i >= 0:
line = line[:i] # strip chunk-extensions
+ # handle ill-formed response not ended with 0 chunk-size
+ line = line.strip()
+ if not line:
+ break
chunk_left = int(line, 16)
if chunk_left == 0:
break
if amt is None:
value += self._safe_read(chunk_left)
elif amt < chunk_left:
Attached patches for Python-2.5, Python-2.6 and Python-3.1.
----------
components: Library (Lib)
files: httplib.python-2.5.diff
keywords: patch
messages: 93215
nosy: Andrei Korostelev
severity: normal
status: open
title: Httplib read routine is not tolerant to not well-formed chunked http responses.
type: behavior
versions: Python 2.5, Python 2.6, Python 3.1
Added file: http://bugs.python.org/file14988/httplib.python-2.5.diff
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7013>
_______________________________________
From martin at v.loewis.de Mon Sep 28 22:01:42 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Sep 2009 22:01:42 +0200
Subject: [New-bugs-announce] [issue7012] Tabs is better than spaces for
identation
In-Reply-To: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
References: <1254140784.83.0.333409306881.issue7012@psf.upfronthosting.co.za>
Message-ID: <4AC11626.5070701@v.loewis.de>
> Then some of the arguments I've heard is that some editors shows tabs
> badly, although true, then most proper editors it's possible to adjust
> that to your personal preference
That is no option for Python. In Python, it is part of the LANGUAGE
SYNTAX that a tab is 8 columns. Changing that may change the very
meaning of a Python program (i.e. an editor configured to four column
tabs may render a program to MEAN something different than when
formatted to eight column tabs).
So a tab is 8 columns, period.
> In a program with 200 lines of code we have roughly 600 extra
> keystrokes with spaces, unless using a proper editor which shows tabs
> nicely.
I think you should get a different editor then. I press tab in my
editor and still get four spaces.
> Tabs use less space, which is usable when uploading and downloading
> code a lot (which you do when using version control).
That's negligible, compared to the rest of the file.
From report at bugs.python.org Mon Sep 28 22:53:00 2009
From: report at bugs.python.org (Michael Foord)
Date: Mon, 28 Sep 2009 20:53:00 +0000
Subject: [New-bugs-announce] [issue7014] Logging incompatible with IronPython
In-Reply-To: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>
Message-ID: <1254171180.57.0.897501678845.issue7014@psf.upfronthosting.co.za>
New submission from Michael Foord <michael at voidspace.org.uk>:
Logging is incompatible with IronPython 2.6.
See: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24714
The core of the issue is that logging assumes that if sys._getframe is
not defined then frames can still be accessed through exceptions.
For IronPython this isn't true - *if* sys._getframe is not available in
IronPython (frames have to be specifically enabled) then frames are not
available at all.
Are there any platforms now where sys._getframe will be unavailable but
frames are still available? I don't think this applies to Jython where
frames are always available in recent versions (2.5 - and this would
only be backported to 2.6).
----------
assignee: michael.foord
components: Library (Lib)
messages: 93233
nosy: michael.foord, vinay.sajip
severity: normal
stage: needs patch
status: open
title: Logging incompatible with IronPython
type: crash
versions: Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7014>
_______________________________________
From report at bugs.python.org Tue Sep 29 08:38:10 2009
From: report at bugs.python.org (Rishikesh K Rajak)
Date: Tue, 29 Sep 2009 06:38:10 +0000
Subject: [New-bugs-announce] [issue7015] Getting call trace while executing
"modules spam" at help prompt
In-Reply-To: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
Message-ID: <1254206290.75.0.617783726921.issue7015@psf.upfronthosting.co.za>
New submission from Rishikesh K Rajak <risrajak at linux.vnet.ibm.com>:
[root@ ~]# python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help()
Welcome to Python 2.6! This is the online help utility.
If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.
Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules. To quit this help utility and
return to the interpreter, just type "quit".
To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics". Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".
help> modules spam
Here is a list of matching modules. Enter any module name to get more help.
** (.:18352): WARNING **: Trying to register gtype 'WnckWindowState' as
flags when in fact it is of type 'GEnum'
** (.:18352): WARNING **: Trying to register gtype 'WnckWindowActions'
as flags when in fact it is of type 'GEnum'
** (.:18352): WARNING **: Trying to register gtype
'WnckWindowMoveResizeMask' as flags when in fact it is of type 'GEnum'
Adding pauses to default speech formatting strings.
Adding pauses to Gecko speech formatting strings.
Adding pauses to soffice speech formatting strings.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.6/site.py", line 433, in __call__
return pydoc.help(*args, **kwds)
File "/usr/lib64/python2.6/pydoc.py", line 1720, in __call__
self.interact()
File "/usr/lib64/python2.6/pydoc.py", line 1738, in interact
self.help(request)
File "/usr/lib64/python2.6/pydoc.py", line 1757, in help
self.listmodules(split(request)[1])
File "/usr/lib64/python2.6/pydoc.py", line 1862, in listmodules
apropos(key)
File "/usr/lib64/python2.6/pydoc.py", line 1962, in apropos
ModuleScanner().run(callback, key)
File "/usr/lib64/python2.6/pydoc.py", line 1927, in run
for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
File "/usr/lib64/python2.6/pkgutil.py", line 110, in walk_packages
__import__(name)
File "/usr/lib/python2.6/site-packages/gdb/__init__.py", line 19, in
<module>
import gdb.command.require
File "/usr/lib/python2.6/site-packages/gdb/command/require.py", line
21, in <module>
class RequireCommand (gdb.Command):
AttributeError: 'module' object has no attribute 'Command'
>>>
----------
assignee: georg.brandl
components: Documentation
messages: 93253
nosy: georg.brandl, rishikesh
severity: normal
status: open
title: Getting call trace while executing "modules spam" at help prompt
type: crash
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7015>
_______________________________________
From report at bugs.python.org Tue Sep 29 08:57:14 2009
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Sep 2009 06:57:14 +0000
Subject: [New-bugs-announce] [issue7016] .pyc files are set executable if
the .py file is too
In-Reply-To: <1254207434.5.0.560245182019.issue7016@psf.upfronthosting.co.za>
Message-ID: <1254207434.5.0.560245182019.issue7016@psf.upfronthosting.co.za>
New submission from Steven D'Aprano <steve at pearwood.info>:
In Python 2.6, .pyc files inherit the executable bit from their .py
file. This can lead to strangeness:
$ echo pass > test.py
$ chmod u+x test.py
$ python2.6 -c "import test"
$ ls -l test.pyc
-rwxrw-r-- 1 steve steve 94 2009-09-29 16:54 test.pyc
$ ./test.pyc
: command not found ??
----------
components: Interpreter Core
messages: 93254
nosy: stevenjd
severity: normal
status: open
title: .pyc files are set executable if the .py file is too
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7016>
_______________________________________
From report at bugs.python.org Tue Sep 29 09:07:30 2009
From: report at bugs.python.org (Chris Adamson)
Date: Tue, 29 Sep 2009 07:07:30 +0000
Subject: [New-bugs-announce] [issue7017] os.listdir behaviour
In-Reply-To: <1254208050.64.0.613024688273.issue7017@psf.upfronthosting.co.za>
Message-ID: <1254208050.64.0.613024688273.issue7017@psf.upfronthosting.co.za>
New submission from Chris Adamson <cadamson at internode.on.net>:
When I iterate through a list created using os.listdir it seems to grow
as I create files in that directory. I want a static copy of the list of
files in the directory prior to me writing new files into it.
Here is my code:
fileList = os.listdir(temporaryDirectory)
for curFile in fileList:
# print the file list to see if it is indeed growing
print FileList
fp = file(os.path.join(temporaryDirectory, "." + curFile), 'w')
# write stuff
fp.close()
Here is the output:
['a', 'b', 'c']
['a', 'b', 'c', '.a']
['a', 'b', 'c', '.a', '.b']
['a', 'b', 'c', '.a', '.b', '.c']
So the list is growing and eventually curFile iterates through the list
of files that were created. This behaviour was unwanted in my case and I
couldn't find any documentation about this.
----------
components: None
messages: 93255
nosy: bigaddo
severity: normal
status: open
title: os.listdir behaviour
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7017>
_______________________________________
From report at bugs.python.org Tue Sep 29 12:59:16 2009
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Sep 2009 10:59:16 +0000
Subject: [New-bugs-announce] [issue7018] Recommend "*" over "#" in getargs.c
typecodes
In-Reply-To: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za>
Message-ID: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za>
New submission from Antoine Pitrou <pitrou at free.fr>:
In ? Parsing arguments and building values ? (c-api/arg.html), it should
be made clear that "*" typecodes are recommended over the "#" typecodes,
which are inherently unsafe.
(more generally, the page is totally unreadable, a solution might be to
group the typecodes by family: numbers, strings/buffers, objects; also,
there are so many choices that it's confusing which ones should be
preferred)
----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 93276
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Recommend "*" over "#" in getargs.c typecodes
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7018>
_______________________________________
From report at bugs.python.org Tue Sep 29 16:35:59 2009
From: report at bugs.python.org (Carl Friedrich Bolz)
Date: Tue, 29 Sep 2009 14:35:59 +0000
Subject: [New-bugs-announce] [issue7019] unmarshaling of artificial strings
can produce funny longs.
In-Reply-To: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
Message-ID: <1254234959.01.0.461220036741.issue7019@psf.upfronthosting.co.za>
New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:
When unmarshalling a hand-written string it is possible to break the
invariants of longs:
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.
>>> x = marshal.loads('l\x02\x00\x00\x00\x00\x00\x00\x00')
>>> print x
00000
>>> x == 0
False
>>> bool(x)
True
>>> x + 1
1L
I would expect this to raise an error instead.
----------
components: Interpreter Core
messages: 93295
nosy: cfbolz
severity: normal
status: open
title: unmarshaling of artificial strings can produce funny longs.
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7019>
_______________________________________
From report at bugs.python.org Wed Sep 30 04:20:34 2009
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 30 Sep 2009 02:20:34 +0000
Subject: [New-bugs-announce] [issue7020] regression in pywin32 build due to
2.6.3rc1
In-Reply-To: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
Message-ID: <1254277234.44.0.988933728928.issue7020@psf.upfronthosting.co.za>
New submission from Sridhar Ratnakumar <sridharr at activestate.com>:
Today's 2.6.3rc1 introduced an regression in building pywin32. Peruse
the following error:
=========================================================
creating build\lib.win32-2.6\pywin32_system32
C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL
/nologo /INCREMENTAL:NO
/LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\libs
/LIBPATH:E:\apy\py263\build\py2_6_3rc1-win32-x86-apy26-rrun\python\PCbuild
/LIBPATH:build\temp.win32-2.6\Release "/LIBPATH:C:\Program
Files\Microsoft SDKs\Windows\v6.0\lib" advapi32.lib user32.lib ole32.lib
oleaut32.lib /EXPORT:initpywintypes
build\temp.win32-2.6\Release\win32\src\PyACL.obj
build\temp.win32-2.6\Release\win32\src\PyDEVMODE.obj
build\temp.win32-2.6\Release\win32\src\PyHANDLE.obj
build\temp.win32-2.6\Release\win32\src\PyIID.obj
build\temp.win32-2.6\Release\win32\src\PyLARGE_INTEGER.obj
build\temp.win32-2.6\Release\win32\src\PyOVERLAPPED.obj
build\temp.win32-2.6\Release\win32\src\PySECURITY_ATTRIBUTES.obj
build\temp.win32-2.6\Release\win32\src\PySECURITY_DESCRIPTOR.obj
build\temp.win32-2.6\Release\win32\src\PySID.obj
build\temp.win32-2.6\Release\win32\src\PyTime.obj
build\temp.win32-2.6\Release\win32\src\PyUnicode.obj
build\temp.win32-2.6\Release\win32\src\PyWAVEFORMATEX.obj
build\temp.win32-2.6\Release\win32\src\PyWinTypesmodule.obj
/OUT:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd
/IMPLIB:build\temp.win32-2.6\Release\win32\src\pywintypes.lib
/MANIFESTFILE:build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest
/MACHINE:x86 /BASE:0x1e7d0000 /DEBUG
/PDB:build\temp.win32-2.6\Release\pywintypes.pdb
Creating library
build\temp.win32-2.6\Release\win32\src\pywintypes.lib and object
build\temp.win32-2.6\Release\win32\src\pywintypes.exp
C:\Program Files\Microsoft SDKs\Windows\v6.0\bin\mt.exe -nologo
-manifest build\temp.win32-2.6\Release\win32\src\pywintypes.pyd.manifest
-outputresource:build\lib.win32-2.6\pywin32_system32\pywintypes.pyd;2
Unable to import verstamp, no version info will be added
error: can't copy
'build\temp.win32-2.6\Release\win32\src\pywintypes26.lib': doesn't exist
or not a regular file
=========================================================
With 2.6.2 .. this error did not happen.
The file build\temp.win32-2.6\Release\win32\src\pywintypes.lib exists
(but without the version number).
Was something substantial changed in distutils?
(I am currently investigating this issue; more details will follow)
----------
assignee: tarek
components: Distutils
messages: 93341
nosy: srid, tarek
severity: normal
status: open
title: regression in pywin32 build due to 2.6.3rc1
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7020>
_______________________________________
From report at bugs.python.org Wed Sep 30 04:55:59 2009
From: report at bugs.python.org (Konstantin M. Khankin)
Date: Wed, 30 Sep 2009 02:55:59 +0000
Subject: [New-bugs-announce] [issue7021] subprocess.Popen doesn't work
without "executable="
In-Reply-To: <1254279359.58.0.557199390007.issue7021@psf.upfronthosting.co.za>
Message-ID: <1254279359.58.0.557199390007.issue7021@psf.upfronthosting.co.za>
New submission from Konstantin M. Khankin <homecreate at list.ru>:
I'm need to call sendmail. So I wrote:
http://paste.org.ru/?imuoia
os.stat there is to confirm that python can have access to sendmail
executable
That code returned an exception:
http://paste.org.ru/?jbxadp
But documentation says, that I can write executable name with args in
"args=" parameter. But program didn't work until I wrote
"/usr/sbin/sendmail" both in the "executable=" and "args=" parameters
----------
components: Library (Lib)
messages: 93344
nosy: hc
severity: normal
status: open
title: subprocess.Popen doesn't work without "executable="
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7021>
_______________________________________
From report at bugs.python.org Wed Sep 30 08:52:42 2009
From: report at bugs.python.org (Pascal Chambon)
Date: Wed, 30 Sep 2009 06:52:42 +0000
Subject: [New-bugs-announce] [issue7022] Doc update for io module
In-Reply-To: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
Message-ID: <1254293562.36.0.276551925074.issue7022@psf.upfronthosting.co.za>
New submission from Pascal Chambon <chambon.pascal at gmail.com>:
*Propositions of doc update*
*RawIOBase*.read(n: int) -> bytes
Read up to n bytes from the object and return them. Fewer than n bytes
may be returned if the operating system call returns fewer than n bytes.
If 0 bytes are returned, and n was not 0, this indicates end of file. If
the object is in non-blocking mode and no bytes are available, the call
returns None.
<warning - this proposition requires patching teh current implementation
as well>:
*RawIOBase*.readinto(b: bytearray, [start: int = None], [end: int =
None]) -> int
start and end are used as slice indexes, so that the bytearray taken
into account is actually range = b[start:end] (or b[start:], b[:end] or
b[:], depending on the arguments which are not None).
Read up to len(range) bytes from the object and store them in b, returning
the number of bytes read. Like .read, fewer than len(range) bytes may be
read, and 0 indicates end of file if len(range) is not 0.
None is returned if a non-blocking object has no bytes available. The
length of b is never changed.
----------
assignee: georg.brandl
components: Documentation, IO
messages: 93352
nosy: georg.brandl, pakal
severity: normal
status: open
title: Doc update for io module
type: feature request
versions: Python 3.1, Python 3.2
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7022>
_______________________________________
From report at bugs.python.org Wed Sep 30 11:36:53 2009
From: report at bugs.python.org (zengke)
Date: Wed, 30 Sep 2009 09:36:53 +0000
Subject: [New-bugs-announce] [issue7023] Marshal doesn't release GIL while
dumping
In-Reply-To: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>
Message-ID: <1254303413.34.0.0761757905328.issue7023@psf.upfronthosting.co.za>
New submission from zengke <superisaac.ke at gmail.com>:
If marshal.dumps() is handling a large data, It keeps acquiring the GIL
and may take several seconds, Other threads therefor are blocked.
marshal.loads should also be friendly to other threads.
----------
components: Library (Lib)
files: marshal_threads.patch
keywords: patch
messages: 93354
nosy: zengke
severity: normal
status: open
title: Marshal doesn't release GIL while dumping
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15006/marshal_threads.patch
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7023>
_______________________________________
From report at bugs.python.org Wed Sep 30 16:48:39 2009
From: report at bugs.python.org (Harshad Modi)
Date: Wed, 30 Sep 2009 14:48:39 +0000
Subject: [New-bugs-announce] [issue7024] webbrowser : Could not open ftp
server using webbrowser.open()
In-Reply-To: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
Message-ID: <1254322119.3.0.661355666564.issue7024@psf.upfronthosting.co.za>
New submission from Harshad Modi <hmo at tinyerp.com>:
Hi,
I try to open ftp site using webbrowser.open('ftp://localhost:21') in
python2.6.
but It can not open and give error like :
Error showing url: The specified location is not mounted
It is working good in python2.5
so can anybod help me ? what am I wrong ?
Thanks in Adcance.
----------
messages: 93368
nosy: hmo
severity: normal
status: open
title: webbrowser : Could not open ftp server using webbrowser.open()
versions: Python 2.6
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7024>
_______________________________________
From 2008.psbc at gmail.com Thu Sep 10 10:47:11 2009
From: 2008.psbc at gmail.com (guohua huang)
Date: Thu, 10 Sep 2009 08:47:11 -0000
Subject: [New-bugs-announce] curses textpad module can input chinese
character.
Message-ID: <d95dfc9d0909100147h21fca2c3l51d2601e812f781d@mail.gmail.com>
curses
textpad.py
class Textbox:
def do_command(self, ch):
line 67
old : if ascii.isprint(ch) :
update: if ascii.isprint(ch) or ( ch < curses.KEY_MIN and ascii.ismeta(ch)
) :
???????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20090910/a665f81e/attachment.htm>
From 2008.psbc at gmail.com Thu Sep 10 10:59:47 2009
From: 2008.psbc at gmail.com (guohua huang)
Date: Thu, 10 Sep 2009 08:59:47 -0000
Subject: [New-bugs-announce] curses textpad module can input/output chinese
character.
Message-ID: <d95dfc9d0909100159o183d2f18y3d29dd46ac3eebd7@mail.gmail.com>
curses
textpad.py
class Textbox:
def do_command(self, ch):
line 67
old : if ascii.isprint(ch) :
update: if ascii.isprint(ch) or ( ch < curses.KEY_MIN and ascii.ismeta(ch)
) :
???????????
resolved chinese character input
line 144
old : result = result +
chr(ascii.ascii(self.win.inch(y, x)))
update: result = result + chr(self.win.inch(y, x))
???????????
resolv chinese character output
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20090910/f7ea1088/attachment.htm>