From report at bugs.python.org Tue Jan 1 00:52:12 2008
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 31 Dec 2007 23:52:12 -0000
Subject: [New-bugs-announce] [issue1715] Make pydoc list submodules
Message-ID: <1199145132.63.0.00647784499418.issue1715@psf.upfronthosting.co.za>
New submission from Gustavo J. A. M. Carneiro:
Often python extension modules define submodules like this:
static PyObject *
initfoo_xpto(void)
{
PyObject *m;
m = Py_InitModule3("foo.xpto", foo_xpto_functions, NULL);
[...]
return m;
}
PyMODINIT_FUNC
initfoo(void)
{
PyObject *m;
PyObject *submodule;
m = Py_InitModule3("foo", foo_functions, NULL);
[...]
submodule = initfoo_xpto();
Py_INCREF(submodule);
PyModule_AddObject(m, "xpto", submodule);
}
Unfortunately pydoc does not list these submodules. Attached patch
fixes it.
----------
components: Demos and Tools
files: pydoc-submodules.diff
messages: 59067
nosy: gustavo
severity: normal
status: open
title: Make pydoc list submodules
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9038/pydoc-submodules.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1715>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pydoc-submodules.diff
Type: text/x-patch
Size: 702 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20071231/90b0608d/attachment.bin
From report at bugs.python.org Tue Jan 1 03:38:29 2008
From: report at bugs.python.org (Christopher Tur Lesniewski-Laas)
Date: Tue, 01 Jan 2008 02:38:29 -0000
Subject: [New-bugs-announce] [issue1716] String format operator '%i' fails
for large floats
Message-ID: <1199155109.22.0.179885625842.issue1716@psf.upfronthosting.co.za>
New submission from Christopher Tur Lesniewski-Laas:
To reproduce:
>>> '%i' % 12345678901.0
TypeError: int argument required
Contrast with:
>>> '%i' % 1234567890.0
'1234567890'
Previous experience led me to expect that the '%i' format code would
work for all numerical types. Admittedly, there's nothing in the docs
promising this, but it works *almost* all the time.
In fact, the operator fails to convert floats which are too big to fit
into a machine long. The code for the '%i' operator handles objects of
type long specially, and then uses PyInt_AsLong to handle all other
objects (in formatint).
The ideal solution would be to ask the object to convert itself into an
int *before* the special test for type long; this would give the
expected behavior.
An acceptable solution would be to make the behavior consistent by
refusing all floats passed as the argument to '%i', but I expect this
would break a lot of code. Of course, right now most of that code is
broken anyway, since it will throw a TypeError when the input float
happens to be large.
----------
components: Interpreter Core
messages: 59068
nosy: ctl
severity: normal
status: open
title: String format operator '%i' fails for large floats
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1716>
__________________________________
From report at bugs.python.org Tue Jan 1 17:39:25 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 01 Jan 2008 16:39:25 -0000
Subject: [New-bugs-announce] [issue1717] Get rid of more refercenes to
__cmp__
Message-ID: <1199205565.64.0.0495465164968.issue1717@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Should I apply this? There are more places that reference __cmp__ in
the library. OTOH there are some folks who would like to see __cmp__
make a come-back as a shorthand for defining 6 comparison operators, for
totally-ordered types. (I'm still waiting for a PEP describing this
though.) Even in that case I'm not sure that the code I'm proposing to
delete here would be useful.
----------
assignee: gvanrossum
components: Interpreter Core
files: nocmp.diff
keywords: patch
messages: 59072
nosy: gvanrossum
priority: low
severity: normal
status: open
title: Get rid of more refercenes to __cmp__
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9039/nocmp.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1717>
__________________________________
From report at bugs.python.org Tue Jan 1 23:55:35 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 01 Jan 2008 22:55:35 -0000
Subject: [New-bugs-announce] [issue1718] Tarfile fails to fully extract
tar.bz2/tar.gz package
Message-ID: <1199228135.83.0.661994029416.issue1718@psf.upfronthosting.co.za>
New submission from Ismail Donmez:
Running python 2.5 maintainance branch,
Test code is :
import tarfile
f = file(r"nss-3.12_alpha2.tar.bz2", "rb")
tar = tarfile.open(fileobj=f, mode="r|bz2")
try:
for m in tar:
tar.extract(m)
finally:
tar.close()
f.close()
You can get the file from
http://cekirdek.pardus.org.tr/~ismail/dist/nss-3.12_alpha2.tar.bz2 .
When the script finishes it only creates mozilla/security/nss directory,
if you extract with tar you will see that it also creates
mozilla/security/coreconf directory.
Tarfile created with 1.19 on Linux i686. I can reproduce the same
problem with tar.gz version of the same file.
----------
components: Library (Lib)
messages: 59077
nosy: cartman
severity: normal
status: open
title: Tarfile fails to fully extract tar.bz2/tar.gz package
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1718>
__________________________________
From report at bugs.python.org Wed Jan 2 05:30:04 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 02 Jan 2008 04:30:04 -0000
Subject: [New-bugs-announce] [issue1719] Cosmetic patch for doc/code
mismatch (msilib.UuidCreate)
Message-ID: <1199248204.42.0.654207997691.issue1719@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Doc says msilib.UUIDCreate(), while code says msilib.UuidCreate()
(Case differs) maybe doc is wrong?
----------
components: Documentation
files: msilib.patch
messages: 59089
nosy: ocean-city
severity: normal
status: open
title: Cosmetic patch for doc/code mismatch (msilib.UuidCreate)
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9041/msilib.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1719>
__________________________________
From report at bugs.python.org Wed Jan 2 15:46:34 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 02 Jan 2008 14:46:34 -0000
Subject: [New-bugs-announce] [issue1720] VC6 build patch for release-maint25
Message-ID: <1199285194.09.0.0105963062735.issue1720@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Hello. This patch adds missing _msi support.
I confirmed msi file was successfully created for simple
.py extension via "setup.py bdist_msi". Thank you.
----------
components: Build
files: vc6-release-maint25.patch
messages: 59094
nosy: ocean-city
severity: normal
status: open
title: VC6 build patch for release-maint25
versions: Python 2.5
Added file: http://bugs.python.org/file9043/vc6-release-maint25.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720>
__________________________________
From report at bugs.python.org Wed Jan 2 17:12:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Jan 2008 16:12:59 -0000
Subject: [New-bugs-announce] [issue1721] _tkinter.c:903: AsObj: Assertion
`size < size * sizeof(Tcl_UniChar)' failed
Message-ID: <1199290379.17.0.733909203656.issue1721@psf.upfronthosting.co.za>
New submission from Christian Heimes:
$ ./python Lib/idlelib/idle.py
python: /home/heimes/dev/python/py3k/Modules/_tkinter.c:903: AsObj:
Assertion `size < size * sizeof(Tcl_UniChar)' failed.
Aborted
The code works when I change the assertion from "<" to "<=". My Python
3.0 is compiled with unicode=UCS-4 and Tcl is the default installation
of Ubuntu (probably UCS-2?).
----------
components: IDLE, Tkinter
keywords: py3k
messages: 59095
nosy: tiran
priority: normal
severity: normal
status: open
title: _tkinter.c:903: AsObj: Assertion `size < size * sizeof(Tcl_UniChar)' failed
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721>
__________________________________
From report at bugs.python.org Wed Jan 2 19:31:39 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 02 Jan 2008 18:31:39 -0000
Subject: [New-bugs-announce] [issue1722] Undocumented urllib functions
Message-ID: <1199298699.61.0.103680011754.issue1722@psf.upfronthosting.co.za>
Changes by Barry A. Warsaw:
----------
components: Documentation
nosy: barry
priority: low
severity: normal
status: open
title: Undocumented urllib functions
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722>
__________________________________
From report at bugs.python.org Thu Jan 3 00:16:57 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Wed, 02 Jan 2008 23:16:57 -0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue1723=5D_Respuesta_autom?=
=?utf-8?q?=C3=A1tica_de_Yahoo!?=
Message-ID: <750844.18848.qm@web32806.mail.mud.yahoo.com>
New submission from Gabriel Genellina:
Estoy de vacaciones hasta el 15 de enero!
On holiday until Jan 15!
----------
messages: 59110
nosy: gagenellina
severity: normal
status: open
title: Respuesta autom?tica de Yahoo!
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1723>
__________________________________
From report at bugs.python.org Thu Jan 3 00:43:20 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Jan 2008 23:43:20 -0000
Subject: [New-bugs-announce] [issue1724] Py_SIZE() macro used as an lvalue
Message-ID: <1199317400.01.0.0409797151443.issue1724@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
Don't know if this was intended. Here's a example from rev 56476 in
arraymodule.c:
- op->ob_size = size;
+ Py_Size(op) = size;
----------
assignee: loewis
components: Interpreter Core
messages: 59111
nosy: loewis, rhettinger
severity: normal
status: open
title: Py_SIZE() macro used as an lvalue
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724>
__________________________________
From report at bugs.python.org Thu Jan 3 01:04:55 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Jan 2008 00:04:55 -0000
Subject: [New-bugs-announce] [issue1725] -1e-1000 converted incorrectly
Message-ID: <1199318695.81.0.228774290881.issue1725@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Since 1e-1000 == 0.0 (on an IEEE-754 platform anyway), I would expect
-1e-1000 to be -0.0. But it does not appear that way:
>>> 1e-1000
0.0
>>> -0.0
-0.0
>>> -1e-1000
0.0
However (correctly):
>>> (-1.0) * 1e-1000
-0.0
>>> -(1e-1000)
-0.0
I suspect the optimization for -x where x is a float literal is
incorrectly triggering here.
----------
messages: 59113
nosy: gvanrossum
severity: normal
status: open
title: -1e-1000 converted incorrectly
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725>
__________________________________
From report at bugs.python.org Thu Jan 3 11:32:48 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 03 Jan 2008 10:32:48 -0000
Subject: [New-bugs-announce] [issue1726] Remove Python/atof.c from
PCBuild/pythoncore.vcproj
Message-ID: <1199356368.04.0.413165256482.issue1726@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Probably this file is not needed for VisualC++.
I don't know this is harmful or not.
----------
components: Build
files: remove_atof_c.patch
messages: 59126
nosy: ocean-city
severity: minor
status: open
title: Remove Python/atof.c from PCBuild/pythoncore.vcproj
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9047/remove_atof_c.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726>
__________________________________
From report at bugs.python.org Thu Jan 3 11:44:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 03 Jan 2008 10:44:42 -0000
Subject: [New-bugs-announce] [issue1727] VC6 build patch for python3000
Message-ID: <1199357082.52.0.581010434607.issue1727@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
Build succeeded. So many errors on test_mailbox.py, and following error
on test_float.py were reported.
======================================================================
FAIL: test_nan_from_str (__main__.InfNanTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_float.py", line 203, in test_nan_from_str
self.assert_(isnan(float("nan")))
AssertionError: None
# I renamed 'fortran' in Include/abstract.h to 'fort' because VC6
said 'fortran' is preserved word for compatibility sake.
----------
components: Build
files: vc6-py3k.patch
messages: 59127
nosy: ocean-city
severity: normal
status: open
title: VC6 build patch for python3000
versions: Python 3.0
Added file: http://bugs.python.org/file9048/vc6-py3k.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1727>
__________________________________
From report at bugs.python.org Thu Jan 3 20:26:30 2008
From: report at bugs.python.org (astronouth7303)
Date: Thu, 03 Jan 2008 19:26:30 -0000
Subject: [New-bugs-announce] [issue1728] distutils.cmd breaks inspect
Message-ID: <1199388390.0.0.11060735615.issue1728@psf.upfronthosting.co.za>
New submission from astronouth7303:
Something about distutils/cmd.py breaks inspect.findsource(). I am
unsure if this is a bug with DistUtils or the inspect module.
>>> import inspect, distutils.cmd
>>> inspect.findsource(distutils.cmd.install_misc.get_outputs)
Causes findsource() to receive an IndexError.
>From some hacking, I've found that the root cause appears to be that
linecache.getlines() returns a number of lines that do not match the
actual file. (In my case, getlines() returns 405 lines when
distutils/cmd.py has 478 lines.)
This bug causes pydoc to break when it is pointed at distutils.cmd.
This is on Ubuntu Gutsy, Python 2.5.1
----------
components: None
messages: 59145
nosy: astronouth7303
severity: normal
status: open
title: distutils.cmd breaks inspect
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1728>
__________________________________
From report at bugs.python.org Thu Jan 3 20:39:27 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 03 Jan 2008 19:39:27 -0000
Subject: [New-bugs-announce] [issue1729] Allow float('infinity') as well as
float('inf')
Message-ID: <1199389167.5.0.55009136517.issue1729@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
This request relates to issue 1635:
http://bugs.python.org/issue1635
which allows cross-platform creation of infinities and nans.
The IEEE754 standard, the C99 standard, and the standard on which
Decimal is based all allow creation of an infinity from the string
'Infinity' (case-independent), as well as from 'inf'. Is there any
reason not to allow this for floats? I'm happy to create a patch.
----------
components: Interpreter Core
messages: 59146
nosy: marketdickinson
severity: minor
status: open
title: Allow float('infinity') as well as float('inf')
type: rfe
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729>
__________________________________
From report at bugs.python.org Thu Jan 3 22:32:00 2008
From: report at bugs.python.org (Robin Stocker)
Date: Thu, 03 Jan 2008 21:32:00 -0000
Subject: [New-bugs-announce] [issue1730] Documentation corrections for os
module
Message-ID: <1199395920.46.0.540210712887.issue1730@psf.upfronthosting.co.za>
New submission from Robin Stocker:
I saw a minor inconsistency in the documentation of the os module and
then somehow ended up proof-reading the whole file :). The result of
this is attached as a patch against trunk.
Summary of the changes:
- Use the imperative tense in method descriptions
- Some more links using semantic markup
- Added example for file.seek
- Consistently use "" instead of '' in text
- or-ed, OR'd replaced with ORed
- bit-wise replaced with bitwise
Diffstat for the patch::
Doc/c-api/newtypes.rst | 2
Doc/library/fcntl.rst | 2
Doc/library/functions.rst | 2
Doc/library/msvcrt.rst | 2
Doc/library/os.rst | 155
+++++++++++++++++++++---------------------
Doc/library/stdtypes.rst | 9 +-
Doc/library/winsound.rst | 2
Doc/reference/expressions.rst | 18 ++--
Lib/test/test_doctest.py | 2
Modules/fcntlmodule.c | 2
10 files changed, 101 insertions(+), 95 deletions(-)
I hope the changes are ok.
----------
components: Documentation
files: os-module-corrections.patch
messages: 59160
nosy: robin.stocker
severity: normal
status: open
title: Documentation corrections for os module
Added file: http://bugs.python.org/file9051/os-module-corrections.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1730>
__________________________________
From report at bugs.python.org Fri Jan 4 00:28:41 2008
From: report at bugs.python.org (Thomas Dybdahl Ahle)
Date: Thu, 03 Jan 2008 23:28:41 -0000
Subject: [New-bugs-announce] [issue1731] Random errors on interpreter
shutdown
Message-ID: <1199402921.07.0.182156121035.issue1731@psf.upfronthosting.co.za>
New submission from Thomas Dybdahl Ahle:
I have a pygtk program, that uses a fairly lot of threads in a pool. All
of these threads are setDaemon to ensure the application shuts down when
I call gtk.main_quit()
About every second time I close the app, I get one or more errors from
places in the program where a thread seams to have woken up, and now
find all attributes None.
This time I even got a message relating til the GIL:
...
for errortype in (IOError, LogOnError, socket.error, EOFError):
exceptions.AttributeError 'NoneType' object has no attribute 'error'
python: Python/pystate.c:497: PyGILState_Ensure: Assertion (assertion)
'autoInterpreterState' failed.
Afbrudt (SIGABRT)
the socket reference simply comes from "import socket" in the beginning
of the module.
As the errors only occur during application shutdown, it has no
practical effect, but it confuses users to post tons of bug reports.
----------
components: Interpreter Core
messages: 59174
nosy: lobais
severity: normal
status: open
title: Random errors on interpreter shutdown
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731>
__________________________________
From report at bugs.python.org Fri Jan 4 04:01:37 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jan 2008 03:01:37 -0000
Subject: [New-bugs-announce] [issue1732] Doc build fails with a KeyError
Message-ID: <1199415697.63.0.117760365705.issue1732@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
. . .
Traceback (most recent call last):
File "tools/sphinx-build.py", line 24, in <module>
sys.exit(main(sys.argv))
File "/home/rhettinger/py26/Doc/tools/sphinx/__init__.py", line 141,
in main
builderobj.build_update()
File "/home/rhettinger/py26/Doc/tools/sphinx/builder.py", line 199, in
build_update
summary='%d source files that are out of date' % len(to_build))
File "/home/rhettinger/py26/Doc/tools/sphinx/builder.py", line 249, in
build
self.finish()
File "/home/rhettinger/py26/Doc/tools/sphinx/builder.py", line 440, in
finish
download_base_url = self.config['download_base_url'],
KeyError: 'download_base_url'
make: *** [build] Error 1
----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 59209
nosy: georg.brandl, rhettinger
severity: normal
status: open
title: Doc build fails with a KeyError
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1732>
__________________________________
From report at bugs.python.org Fri Jan 4 06:42:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 04 Jan 2008 05:42:42 -0000
Subject: [New-bugs-announce] [issue1733] Maybe PC/VS7.1/pythoncore.vcproj is
missing Modules/md5module.c
Message-ID: <1199425362.34.0.0306392142535.issue1733@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
I addressed this in issue1727, but I thought it could be better to
create new tracker item. Probably attached patch is needed. Thank you.
----------
components: Build
files: md5module.patch
messages: 59215
nosy: ocean-city
severity: normal
status: open
title: Maybe PC/VS7.1/pythoncore.vcproj is missing Modules/md5module.c
versions: Python 3.0
Added file: http://bugs.python.org/file9055/md5module.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1733>
__________________________________
From report at bugs.python.org Fri Jan 4 06:50:39 2008
From: report at bugs.python.org (L. Peter Deutsch)
Date: Fri, 04 Jan 2008 05:50:39 -0000
Subject: [New-bugs-announce] [issue1734] no effect if metaclass modifies dict
Message-ID: <1199425839.96.0.974178478266.issue1734@psf.upfronthosting.co.za>
New submission from L. Peter Deutsch:
In the following, dir(Node) should include the name 'z', and Node.z
should be 'Node'. However, dir(Node) does not include 'z', and Node.z is
undefined (AttributeError). This is directly contrary to the Python
documentation, which says "metaclasses can modify dict".
class MetaNode(type):
def __init__(cls, name, bases, cdict):
cdict['z'] = name
type.__init__(name, bases, cdict)
class Node(object):
__metaclass__ = MetaNode
print dir(Node)
print Node.z
----------
components: Interpreter Core
messages: 59216
nosy: lpd
severity: normal
status: open
title: no effect if metaclass modifies dict
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1734>
__________________________________
From report at bugs.python.org Fri Jan 4 12:02:40 2008
From: report at bugs.python.org (Eric Andresen)
Date: Fri, 04 Jan 2008 11:02:40 -0000
Subject: [New-bugs-announce] [issue1735] tarfile.TarFile.extractall not
setting directory permissions correctly
Message-ID: <1199444560.86.0.587752807874.issue1735@psf.upfronthosting.co.za>
New submission from Eric Andresen:
The tarfile.TarFile.extractall() method is [by default] silently failing
to set directory permissions and times on all but the lexically-latest
directory extracted. This is due to an unintentional re-use of the
'path' variable.
The provided patch renames the second 'path' variable to 'dirpath' which
resolves the problem.
----------
components: Library (Lib)
files: python-tarfile-extractall-fix.patch
messages: 59219
nosy: eandres
severity: normal
status: open
title: tarfile.TarFile.extractall not setting directory permissions correctly
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9056/python-tarfile-extractall-fix.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1735>
__________________________________
From report at bugs.python.org Fri Jan 4 15:53:48 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 04 Jan 2008 14:53:48 -0000
Subject: [New-bugs-announce] [issue1736] Three bugs of FCICreate (PC/_msi.c)
Message-ID: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
I have fixed three bugs of msilib.FCICreate()
1. msilib.FCICreate("a.cab") creates ".a.cab" (extra leading dot)
In recent cab SDK's FCI-FDI.doc,
# quote start
The szCab field should contain a string which contains the name of the
first cabinet to be created (e.g. ?APP1.CAB?). In the event of
multiple cabinets being created, the GetNextCab function called by the
FCIAddFile API allows subsequent cabinet names to be specified.
The szCabPath field should contain the complete path of where to create
the cabinet (e.g. ?C:\MYFILES\?).
# quote end
Currently, _msi.c separate "C:\\MYFILES\\APP1.CAB" to szCabPath "C:"
and szCab "\\MYFILES\\APP1.CAB".
2. Probably, "long names" error check doesn't count null-terminator now.
3. Usually, multibyte character may contain "\\" as trailing-byte.
(like "?" in Japanese) Not to count this as path separator, I used
CharNext().
Thank you.
----------
components: Library (Lib)
files: _msi.patch
messages: 59228
nosy: ocean-city
severity: normal
status: open
title: Three bugs of FCICreate (PC/_msi.c)
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9058/_msi.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736>
__________________________________
From report at bugs.python.org Fri Jan 4 17:03:35 2008
From: report at bugs.python.org (Dariusz Suchojad)
Date: Fri, 04 Jan 2008 16:03:35 -0000
Subject: [New-bugs-announce] [issue1737] Windows installer issue
(ObjectBrowser.py)
Message-ID: <1199462615.21.0.577334644902.issue1737@psf.upfronthosting.co.za>
New submission from Dariusz Suchojad:
Hello,
for some reasons I cannot install Python 2.5.1 using the default MSI
package which may be found here
http://www.python.org/ftp/python/2.5.1/python-2.5.1.msi. This only
happens on two of my PC's at work but I cannot reproduce it at home.
The only difference I could find between those Windows is that the
PC's at work are connected to Active Directory domain whereas my home
machine isn't. I tried to install Python as a domain user and also
as a local administrator but every time I encountered the very same
screen (see attached file objectbrowser.png) and then the installation
process rollbacks. I'd like to investigate
it further but I have no slightest idea where to start. Do you perhaps
have any suggestions? It's all Windows XP SP2.
----------
components: Installation, Windows
files: objectbrowser.png
messages: 59234
nosy: dsuch
severity: normal
status: open
title: Windows installer issue (ObjectBrowser.py)
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9060/objectbrowser.png
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1737>
__________________________________
From report at bugs.python.org Fri Jan 4 22:30:31 2008
From: report at bugs.python.org (Oliver Nelson)
Date: Fri, 04 Jan 2008 21:30:31 -0000
Subject: [New-bugs-announce] [issue1738] filecmp.dircmp does exact match only
Message-ID: <1199482231.61.0.263318145026.issue1738@psf.upfronthosting.co.za>
Changes by Oliver Nelson:
----------
components: None
nosy: flxkid
severity: normal
status: open
title: filecmp.dircmp does exact match only
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
__________________________________
From report at bugs.python.org Sat Jan 5 12:20:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Jan 2008 11:20:54 -0000
Subject: [New-bugs-announce] [issue1739] Testing CIA.vc
Message-ID: <1199532054.55.0.0263033629621.issue1739@psf.upfronthosting.co.za>
New submission from Martin v. L?wis:
Will this text show up in CIA?
----------
messages: 59284
nosy: loewis
severity: normal
status: open
title: Testing CIA.vc
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739>
__________________________________
From report at bugs.python.org Sun Jan 6 02:40:07 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Jan 2008 01:40:07 -0000
Subject: [New-bugs-announce] [issue1740] use unittest for test_logging
Message-ID: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
Lib/test.test_logging.py doesn't use unittest. Here is a patch (against
SVN trunk) to fix the problem.
----------
components: Tests
files: logtest.patch
messages: 59348
nosy: pitrou
severity: normal
status: open
title: use unittest for test_logging
versions: Python 2.6
Added file: http://bugs.python.org/file9073/logtest.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________
From report at bugs.python.org Sun Jan 6 11:42:25 2008
From: report at bugs.python.org (Gerdus van Zyl)
Date: Sun, 06 Jan 2008 10:42:25 -0000
Subject: [New-bugs-announce] [issue1741] .pypirc not found on windows
Message-ID: <1199616145.41.0.131606702507.issue1741@psf.upfronthosting.co.za>
Changes by Gerdus van Zyl:
----------
components: Distutils
nosy: gerdus
severity: normal
status: open
title: .pypirc not found on windows
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1741>
__________________________________
From report at bugs.python.org Sun Jan 6 13:14:00 2008
From: report at bugs.python.org (Jesse Towner)
Date: Sun, 06 Jan 2008 12:14:00 -0000
Subject: [New-bugs-announce] [issue1742] os.path.relpath fails when path ==
start
Message-ID: <1199621640.67.0.296185501304.issue1742@psf.upfronthosting.co.za>
Changes by Jesse Towner:
----------
components: Library (Lib)
nosy: townerj
severity: major
status: open
title: os.path.relpath fails when path == start
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742>
__________________________________
From report at bugs.python.org Sun Jan 6 13:47:41 2008
From: report at bugs.python.org (Rich)
Date: Sun, 06 Jan 2008 12:47:41 -0000
Subject: [New-bugs-announce] [issue1743] IDLE fails to launch
Message-ID: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
New submission from Rich:
Launching IDLE from the start menu has no effect, no windows open.
Command line Python still works. Reinstalling Python does not fix the
problem.
I haven't changed my system configuration since everything was working.
Any ideas for things to check to fix this on my system would be much
appreciated!
----------
components: IDLE
messages: 59364
nosy: richjtd
severity: normal
status: open
title: IDLE fails to launch
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1743>
__________________________________
From report at bugs.python.org Sun Jan 6 16:14:07 2008
From: report at bugs.python.org (loic jeannin)
Date: Sun, 06 Jan 2008 15:14:07 -0000
Subject: [New-bugs-announce] [issue1744] readline module - set/get quote
delimiters
Message-ID: <1199632447.57.0.76416797802.issue1744@psf.upfronthosting.co.za>
New submission from loic jeannin:
here is a patch against Modules/readline.c to add getter/setter for
rl_completer_quote_characters. This is needed for advanced use of
cmd.Cmd with completion.
----------
components: Extension Modules
files: p2.5.1-readline.diff
messages: 59380
nosy: loic
severity: normal
status: open
title: readline module - set/get quote delimiters
type: rfe
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9077/p2.5.1-readline.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744>
__________________________________
From report at bugs.python.org Sun Jan 6 17:04:02 2008
From: report at bugs.python.org (Robin Stocker)
Date: Sun, 06 Jan 2008 16:04:02 -0000
Subject: [New-bugs-announce] [issue1745] Backport of PEP 3102 "keyword-only
arguments" to 2.6
Message-ID: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
New submission from Robin Stocker:
The attached patch ports the implementation of keyword-only arguments
from revision 52491 back to trunk.
This is the first time I've worked on the C internals, so here are some
notes:
- test_collections is the only test which fails, because it tries to
call a function with more than 255 arguments, which results in a
SyntaxError because of the following added code in Python/ast.c. What
should be done about it?
if (nposargs + nkwonlyargs > 255) {
ast_error(n, "more than 255 arguments");
return NULL;
}
- The patch only adds what's in revision 52491. There is at least one
more change involving keyword-only arguments, for example issue1573. Are
there others? Should they be included in this patch or in a separate one?
- There are some changes which were generated, like Python/Python-ast.c
(which needs to be checked in separately).
- Is there documentation which needs to be updated?
----------
components: Interpreter Core
files: backport-keyword-only-arguments.patch
messages: 59391
nosy: robin.stocker
severity: normal
status: open
title: Backport of PEP 3102 "keyword-only arguments" to 2.6
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9078/backport-keyword-only-arguments.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
__________________________________
From report at bugs.python.org Sun Jan 6 23:40:17 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 06 Jan 2008 22:40:17 -0000
Subject: [New-bugs-announce] [issue1746] ZIP files with archive comments
longer than 4k not recognized as valid by zipfile module
Message-ID: <1199659217.24.0.18704559865.issue1746@psf.upfronthosting.co.za>
New submission from Alan McIntyre:
The current behavior of zipfile._EndRecData is to look in the last 4k of
data in a file if it appears it might have an archive comment; this
results in flagging proper ZIP files with comments longer than ~4074
bytes as "not a ZIP file."
I plan on posting a patch for this later, but figured this should be
documented in case I don't get around to it.
----------
components: Library (Lib)
messages: 59411
nosy: alanmcintyre
severity: normal
status: open
title: ZIP files with archive comments longer than 4k not recognized as valid by zipfile module
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746>
__________________________________
From report at bugs.python.org Sun Jan 6 23:46:35 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 06 Jan 2008 22:46:35 -0000
Subject: [New-bugs-announce] [issue1747] isinstance(NotSubclassOfObject,
InstanceOfAbcMeta) fails instead of returning False
Message-ID: <1199659595.05.0.292041718212.issue1747@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin:
Python 2.6a0 (trunk:59791M, Jan 6 2008, 12:22:37)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import abc
[30620 refs]
>>> class A:
... __metaclass__ = abc.ABCMeta
...
[30650 refs]
>>> class B:
... pass
...
[30659 refs]
>>> issubclass(B, A)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jyasskin/src/python/trunk-abc/Lib/abc.py", line 191, in
__subclasscheck__
if cls in subclass.__mro__:
AttributeError: class B has no attribute '__mro__'
[30701 refs]
>>>
This causes Decimal to break in interesting ways when I make it subclass
numbers.Real. test_abc doesn't catch it because it declares
__metaclass__=type at the top level. :-(
This looks relatively easy to fix, so I'll work on a patch.
----------
assignee: jyasskin
components: Library (Lib)
messages: 59412
nosy: gvanrossum, jyasskin
severity: normal
status: open
title: isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1747>
__________________________________
From report at bugs.python.org Sun Jan 6 23:59:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Jan 2008 22:59:06 -0000
Subject: [New-bugs-announce] [issue1748] contextlib.contextmanager does not
use functools.wraps
Message-ID: <1199660346.11.0.927717674711.issue1748@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
The contextmanager function should call functools.wraps instead of
having its own attribute copying code. Just something I noticed while
reading the source.
----------
components: Library (Lib)
messages: 59413
nosy: pitrou
severity: minor
status: open
title: contextlib.contextmanager does not use functools.wraps
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1748>
__________________________________
From report at bugs.python.org Mon Jan 7 00:06:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Jan 2008 23:06:49 -0000
Subject: [New-bugs-announce] [issue1750] Test: This is title
Message-ID: <1199660809.31.0.345671159416.issue1750@psf.upfronthosting.co.za>
New submission from Martin v. L?wis:
This is the change message
----------
messages: 59415
nosy: loewis
severity: normal
status: open
title: Test: This is title
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1750>
__________________________________
From report at bugs.python.org Mon Jan 7 08:20:32 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 07 Jan 2008 07:20:32 -0000
Subject: [New-bugs-announce] [issue1751] Fast BytesIO implementation + misc
changes
Message-ID: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti:
Finally, here is my C implementation of BytesIO. The code is well tested
and include the proper unit tests. The only remaining issues are:
- The behavior of the close() method.
- The failure of test_profile and test_cProfile.
Currently, I have no idea how to fix the tests for the profilers. The
weird thing is both pass when run with:
% ./python Lib/test/regrtest.py -R: test_profile
----------
components: Interpreter Core, Library (Lib), Tests
files: _bytesio.c
keywords: patch
messages: 59436
nosy: alexandre.vassalotti, gvanrossum
priority: normal
severity: normal
status: open
title: Fast BytesIO implementation + misc changes
versions: Python 3.0
Added file: http://bugs.python.org/file9084/_bytesio.c
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________
From report at bugs.python.org Mon Jan 7 08:46:49 2008
From: report at bugs.python.org (Max Ischenko)
Date: Mon, 07 Jan 2008 07:46:49 -0000
Subject: [New-bugs-announce] [issue1752] logging.basicConfig misleading
behaviour
Message-ID: <1199692009.12.0.936075891913.issue1752@psf.upfronthosting.co.za>
New submission from Max Ischenko:
Function logging.basicConfig has a confusing and undocumented behaviour:
it does nothing if there are any handlers already present in root logger.
It could be more explicit, say, by giving a ValueError in such cases.
----------
components: Library (Lib)
messages: 59437
nosy: imax
severity: normal
status: open
title: logging.basicConfig misleading behaviour
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1752>
__________________________________
From report at bugs.python.org Mon Jan 7 09:50:34 2008
From: report at bugs.python.org (Erick Tryzelaar)
Date: Mon, 07 Jan 2008 08:50:34 -0000
Subject: [New-bugs-announce] [issue1753] TextIOWrapper.write writes utf BOM
for every string
Message-ID: <1199695834.32.0.627180179119.issue1753@psf.upfronthosting.co.za>
New submission from Erick Tryzelaar:
I was playing around with python 3's io functions, and I found that when trying to write to
an encoded utf-16 file that TextIOWrapper.write re-writes the utf-16 bom for every string:
>>> f=open('foo', 'w', encoding='utf-16')
>>> print('1234', file=f)
>>> print('5678', file=f)
>>> open('foo', 'rb').read()
b'\xff\xfe1\x002\x003\x004\x00\xff\xfe\n\x00\xff\xfe5\x006\x007\x008\x00\xff\xfe\n\x00'
>>> open('foo', 'r', encoding='utf-16').read()
'1234\ufeff\n\ufeff5678\ufeff\n'
>>>
With the attached patch, it appears to generate the correct file:
>>> f=open('foo', 'w', encoding='utf-16')
>>> print('1234', file=f)
>>> print('5678', file=f)
>>> open('foo', 'rb').read()
b'\xff\xfe1\x002\x003\x004\x00\n\x005\x006\x007\x008\x00\n\x00'
>>> open('foo', 'r', encoding='utf-16').read()
'1234\n5678\n'
>>>
----------
components: Library (Lib)
files: io.py.patch
messages: 59438
nosy: erickt
severity: normal
status: open
title: TextIOWrapper.write writes utf BOM for every string
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9091/io.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1753>
__________________________________
From report at bugs.python.org Mon Jan 7 12:24:32 2008
From: report at bugs.python.org (Romulo A. Ceccon)
Date: Mon, 07 Jan 2008 11:24:32 -0000
Subject: [New-bugs-announce] [issue1754] WindowsError messages are not
properly encoded
Message-ID: <1199705072.7.0.841408898872.issue1754@psf.upfronthosting.co.za>
New submission from Romulo A. Ceccon:
The message for WindowsError is taken from the Windows API's
FormatMessage() function, following the OS language. Currently Python
does no conversion for those messages, so non-ASCII characters end up
improperly encoded in the console. For example:
>>> import os
>>> os.rmdir('E:\\temp')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
WindowsError: [Error 41] A pasta n?o est? vazia: 'E:\\temp'
Should be: "A pasta n?o est? vazia" [Folder is not empty].
Python could check what is the code page of the current output interface
and change the message accordingly.
----------
components: Windows
messages: 59441
nosy: Romulo A. Ceccon
severity: minor
status: open
title: WindowsError messages are not properly encoded
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1754>
__________________________________
From report at bugs.python.org Mon Jan 7 15:08:31 2008
From: report at bugs.python.org (Brad Tilley)
Date: Mon, 07 Jan 2008 14:08:31 -0000
Subject: [New-bugs-announce] [issue1755] Misspelling in future.c in 2.5.1
source (handl should be handle)
Message-ID: <1199714911.67.0.807778924575.issue1755@psf.upfronthosting.co.za>
New submission from Brad Tilley:
/* A subsequent pass will detect future imports that don't
appear at the beginning of the file. There's one case,
however, that is easier to handl here: A series of imports
joined by semi-colons, where the first import is a future
statement but some subsequent import has the future form
but is preceded by a regular import.
*/
----------
components: None
messages: 59445
nosy: brad
severity: minor
status: open
title: Misspelling in future.c in 2.5.1 source (handl should be handle)
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1755>
__________________________________
From report at bugs.python.org Mon Jan 7 19:58:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Jan 2008 18:58:02 -0000
Subject: [New-bugs-announce] [issue1756] -m broken in trunk
Message-ID: <1199732282.41.0.0565875093143.issue1756@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
As of today, the -m option doesn't appear to work any more in the trunk.
I get this error:
$ ./python -m string
Could not import runpy module
$
However it seems to be confused:
$ ./python -c 'import runpy'
$
IOW the module imports just fine.
Crys, I wonder if this has to do with your import-nolock changes?
----------
assignee: tiran
messages: 59478
nosy: gvanrossum, tiran
priority: urgent
severity: normal
status: open
title: -m broken in trunk
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1756>
__________________________________
From report at bugs.python.org Mon Jan 7 22:03:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Jan 2008 21:03:58 -0000
Subject: [New-bugs-announce] [issue1757] Decimal hash depends on current
context
Message-ID: <1199739838.21.0.114210159125.issue1757@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
The value of the Decimal hash() depends on the current context:
>>> from decimal import *
>>> x = Decimal("123456789.1")
>>> hash(x)
1989332493
>>> getcontext().prec = 6
>>> hash(x)
-2034270682
This has nasty consequences; e.g.:
>>> s = set([x])
>>> x in s
True
>>> getcontext().prec = 28
>>> x in s
False
hashing a Decimal can also set flags in the context; again, I think
this is undesirable.
The cause of this bug is clear: __hash__ calls normalize, which rounds
its argument to the current context. I'll post a fix when I get around
to it.
----------
components: Library (Lib)
messages: 59492
nosy: marketdickinson
severity: normal
status: open
title: Decimal hash depends on current context
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757>
__________________________________
From report at bugs.python.org Mon Jan 7 23:20:47 2008
From: report at bugs.python.org (Martin Marcher)
Date: Mon, 07 Jan 2008 22:20:47 -0000
Subject: [New-bugs-announce] [issue1758] Wrong link in documentation
Message-ID: <1199744447.77.0.771714007118.issue1758@psf.upfronthosting.co.za>
New submission from Martin Marcher:
In this site: http://www.python.org/doc/current/inst/about.html under
"Comments and Questions" the link to the python bugtracker is still
pointing to the sourceforge bugtracker.
----------
components: Documentation
messages: 59502
nosy: martin.marcher
severity: normal
status: open
title: Wrong link in documentation
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1758>
__________________________________
From report at bugs.python.org Tue Jan 8 04:44:29 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 08 Jan 2008 03:44:29 -0000
Subject: [New-bugs-announce] [issue1759] Backport of PEP 3129 "class
decorators"
Message-ID: <1199763869.09.0.792337356327.issue1759@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch backports the class decorator syntax to 2.6. All tests except
two are passing. I'm not sure why the inspect test fails and I don't
know how to fix the ast test.
----------
components: Interpreter Core
files: trunk_pep3129_classdec.patch
messages: 59520
nosy: tiran
priority: normal
severity: normal
status: open
title: Backport of PEP 3129 "class decorators"
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9103/trunk_pep3129_classdec.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759>
__________________________________
From report at bugs.python.org Tue Jan 8 09:51:51 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Tue, 08 Jan 2008 08:51:51 -0000
Subject: [New-bugs-announce] [issue1760] PEP 341 is not reflected in the
documentation
Message-ID: <1199782311.05.0.0687645566121.issue1760@psf.upfronthosting.co.za>
New submission from Yinon Ehrlich:
Compare:
http://docs.python.org/whatsnew/pep-341.html
With:
http://docs.python.org/ref/exceptions.html
http://docs.python.org/tut/node10.html#SECTION0010300000000000000000
----------
components: Documentation
messages: 59525
nosy: Yinon
severity: minor
status: open
title: PEP 341 is not reflected in the documentation
type: rfe
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1760>
__________________________________
From report at bugs.python.org Tue Jan 8 10:22:02 2008
From: report at bugs.python.org (Ravon Jean-Michel)
Date: Tue, 08 Jan 2008 09:22:02 -0000
Subject: [New-bugs-announce] [issue1761] Bug in re.sub()
Message-ID: <1199784122.17.0.476084084614.issue1761@psf.upfronthosting.co.za>
New submission from Ravon Jean-Michel:
Here is my source:
def truc ():
line = ' hi \n'
line1 = re.sub('$', 'hello', line)
line2 = re.sub('$', 'you', line1)
print line2
Here is what I get:
>>> trace.truc()
hi hello
helloyou
>>>
----------
components: Regular Expressions
messages: 59526
nosy: jmravon
severity: normal
status: open
title: Bug in re.sub()
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1761>
__________________________________
From report at bugs.python.org Tue Jan 8 17:39:10 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 08 Jan 2008 16:39:10 -0000
Subject: [New-bugs-announce] [issue1762] Inheriting from ABC slows Decimal
down.
Message-ID: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin:
Adding numbers.Real to Decimal's base classes almost doubles the time
its its test suite takes to run. A profile revealed that a large
fraction of that slowdown was in __instancecheck__, but even after
optimizing that, it's still about 25% slower. It looks like the rest of
the slowdown is still in other parts of the isinstance() check. It would
be nice if inheriting from ABCs didn't slow your class down.
----------
components: Library (Lib)
messages: 59543
nosy: jyasskin, nnorwitz
severity: normal
status: open
title: Inheriting from ABC slows Decimal down.
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________
From report at bugs.python.org Tue Jan 8 18:12:58 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 08 Jan 2008 17:12:58 -0000
Subject: [New-bugs-announce] [issue1763] Winpath module - easy access to
Windows directories like My Documents
Message-ID: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The new module "winpath" gives easy access to Windows shell folders like
my documents, my files, application data etc.
----------
components: Library (Lib), Windows
files: trunk_winpath.patch
keywords: patch
messages: 59547
nosy: tiran
priority: normal
severity: normal
status: open
title: Winpath module - easy access to Windows directories like My Documents
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9106/trunk_winpath.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1763>
__________________________________
From report at bugs.python.org Wed Jan 9 01:02:06 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Jan 2008 00:02:06 -0000
Subject: [New-bugs-announce] [issue1771] Remove cmp parameter to list.sort()
and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
We should either change the API so you can pass in a '<' comparator, or
get rid of it completely (since key=... takes care of all use cases I
can think of).
----------
messages: 59575
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Remove cmp parameter to list.sort() and builtin.sorted()
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
__________________________________
From report at bugs.python.org Wed Jan 9 07:22:59 2008
From: report at bugs.python.org (Stephan Hoermann)
Date: Wed, 09 Jan 2008 06:22:59 -0000
Subject: [New-bugs-announce] [issue1772] popen fails when there are two or
more pathnames/parameters with spaces
In-Reply-To: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za>
Message-ID: <1199859779.21.0.234395665559.issue1772@psf.upfronthosting.co.za>
New submission from Stephan Hoermann:
If commands similar to this (including all quotation
marks) '"C:\\Program Files\\test.bat" blah "C:\\Data Files\\test2.txt"'
are executed using popen, then the following is returned from
stderr "'C:\\Program' is not recognized as an internal or external
command,\noperable program or batch file.\n". No use of quotation has
been able to fix this. As soon as there is more than one pair of
quotations inside the command string popen will not handle the command
correctly.
----------
components: Library (Lib), Windows
messages: 59580
nosy: shoermann
severity: major
status: open
title: popen fails when there are two or more pathnames/parameters with spaces
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772>
__________________________________
From report at bugs.python.org Wed Jan 9 11:10:59 2008
From: report at bugs.python.org (albert hofkamp)
Date: Wed, 09 Jan 2008 10:10:59 -0000
Subject: [New-bugs-announce] [issue1773] Reference to Python issue tracker
incorrect
In-Reply-To: <1199873459.46.0.46987451089.issue1773@psf.upfronthosting.co.za>
Message-ID: <1199873459.46.0.46987451089.issue1773@psf.upfronthosting.co.za>
New submission from albert hofkamp:
In the Python reference manual (the online current documentation), in
the "About this document" section, there is a reference to the
Sourceforge bug tracker for reporting errors in the document.
This tracker however has been closed, and has been replaced by the one
at http://bugs.python.org/
----------
components: Documentation
messages: 59587
nosy: aioryi
severity: normal
status: open
title: Reference to Python issue tracker incorrect
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1773>
__________________________________
From report at bugs.python.org Wed Jan 9 11:14:02 2008
From: report at bugs.python.org (albert hofkamp)
Date: Wed, 09 Jan 2008 10:14:02 -0000
Subject: [New-bugs-announce] [issue1774] Reference to New style classes
documentation is incorrect
In-Reply-To: <1199873642.96.0.268775813123.issue1774@psf.upfronthosting.co.za>
Message-ID: <1199873642.96.0.268775813123.issue1774@psf.upfronthosting.co.za>
New submission from albert hofkamp:
In the Python reference manual (the online current documentation), in
Section 3.3 "New-style and classic classes", there is a reference to
external documentation about new style classes.
The reference is however incorrect, it should be
http://www.python.org/doc/newstyle/ rather than the mentioned
http://www.python.org/doc/newstyle.html
----------
components: Documentation
messages: 59588
nosy: aioryi
severity: normal
status: open
title: Reference to New style classes documentation is incorrect
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1774>
__________________________________
From report at bugs.python.org Wed Jan 9 13:52:29 2008
From: report at bugs.python.org (Andre Roberge)
Date: Wed, 09 Jan 2008 12:52:29 -0000
Subject: [New-bugs-announce] [issue1775] filehandle.write() does not return
None (Python 3.0a2)
In-Reply-To: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za>
Message-ID: <1199883149.22.0.23332594805.issue1775@psf.upfronthosting.co.za>
New submission from Andre Roberge:
According to the docs, and consistent with the Python 2.x behavior,
filehandle.write() should return None. However, under 3.0a2 (and
3.0a1), it returns the number of characters written.
Either the documentation
http://docs.python.org/dev/3.0/tutorial/inputoutput.html#reading-and-writing-files
is wrong, or it is a bug. I would *much* prefer if the behavior would
stay the same as before.
Below is a sample session illustrating the behavior. Note that I also
get an error message when exiting the session using exit() - this is an
unrelated problem.
Python 3.0a2 (r30a2:59382, Dec 27 2007, 15:48:14)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> handle = open('test_file.txt.', 'w')
>>> handle.write('spam')
4
>>> r = handle.write('more spam')
>>> print(r)
9
>>> exit()
/usr/local/py3k/lib/python3.0/io.py:1210: RuntimeWarning: Trying to
close unclosable fd!
self.buffer.close()
----------
components: Interpreter Core
messages: 59592
nosy: aroberge
severity: normal
status: open
title: filehandle.write() does not return None (Python 3.0a2)
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1775>
__________________________________
From report at bugs.python.org Wed Jan 9 15:26:40 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 09 Jan 2008 14:26:40 -0000
Subject: [New-bugs-announce] [issue1776] __import__ must not accept filenames
Message-ID: <1199888800.48.0.716255470665.issue1776@psf.upfronthosting.co.za>
New submission from Christian Heimes:
See http://permalink.gmane.org/gmane.comp.python.devel/90960
It's also "broken" in 2.5 but we must not change the behavior in a
maintenance release.
----------
components: Interpreter Core
messages: 59602
nosy: tiran
priority: normal
severity: normal
status: open
title: __import__ must not accept filenames
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1776>
__________________________________
From report at bugs.python.org Wed Jan 9 19:58:08 2008
From: report at bugs.python.org (Grant Monroe)
Date: Wed, 09 Jan 2008 18:58:08 -0000
Subject: [New-bugs-announce] [issue1777] ElementTree/cElementTree findtext
inconsistency
In-Reply-To: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za>
Message-ID: <1199905088.24.0.426478607654.issue1777@psf.upfronthosting.co.za>
New submission from Grant Monroe:
cElementTree findtext seems to return None when it should return a string.
----------
components: Library (Lib)
files: etree_test.py
messages: 59618
nosy: gmonroe
severity: normal
status: open
title: ElementTree/cElementTree findtext inconsistency
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9115/etree_test.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777>
__________________________________
From report at bugs.python.org Thu Jan 10 00:19:46 2008
From: report at bugs.python.org (Achim Gaedke)
Date: Wed, 09 Jan 2008 23:19:46 -0000
Subject: [New-bugs-announce] [issue1778] SyntaxError.offset sometimes wrong
In-Reply-To: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za>
Message-ID: <1199920786.95.0.62807405199.issue1778@psf.upfronthosting.co.za>
New submission from Achim Gaedke:
The value SyntaxError.offset is for most SyntaxErrors an offset from
beginning of line SyntaxError.lineno. In case of an triple-quoted string
which is not at all closed, offset seems to be the offset from beginning
of the buffer.
----------
components: Interpreter Core
files: compile_test.py
messages: 59634
nosy: AchimGaedke
severity: normal
status: open
title: SyntaxError.offset sometimes wrong
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9116/compile_test.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778>
__________________________________
From report at bugs.python.org Thu Jan 10 02:00:03 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Jan 2008 01:00:03 -0000
Subject: [New-bugs-announce] [issue1779] int("- 1") is valud,
but float("- 1") isn't. Which is right?
In-Reply-To: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za>
Message-ID: <1199926803.21.0.243129638352.issue1779@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
I discovered that when converting a string to an int or float, the int
conversion allows whitespace after the sign, while the float conversion
doesn't. I think they should be consistent.
----------
components: Interpreter Core
messages: 59641
nosy: gvanrossum
priority: low
severity: normal
status: open
title: int("- 1") is valud, but float("- 1") isn't. Which is right?
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1779>
__________________________________
From report at bugs.python.org Thu Jan 10 02:01:46 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jan 2008 01:01:46 -0000
Subject: [New-bugs-announce] [issue1780] Decimal constructor accepts newline
terminated strings
In-Reply-To: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za>
Message-ID: <1199926906.81.0.101046326746.issue1780@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
After seeing issue #1761, I realized that there's a bug in the Decimal
constructor: it accepts newline-terminated strings:
>>> from decimal import *
>>> s = "2.3\n"
>>> Decimal(s)
Decimal("2.3")
I think this is, strictly speaking, a bug because:
(1) The IBM decimal specification explicitly disallows additional whitespace
in a numeric string (see http://www2.hursley.ibm.com/decimal/daconvs.html),
(2) the operation to-number is supposed only to accept numeric strings, and
(3) Decimal.__new__ is currently the method that implements to-number.
Is this worth fixing? This buggy behaviour might well be useful (e.g. to
someone parsing a file with one Decimal per line).
I'll fix it if anyone thinks it's worth it. Even if it should be fixed, I
don't think this is worth backporting to Python 2.5, especially since it
might break things.
----------
assignee: facundobatista
components: Library (Lib)
messages: 59642
nosy: facundobatista, marketdickinson
priority: normal
severity: minor
status: open
title: Decimal constructor accepts newline terminated strings
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1780>
__________________________________
From report at bugs.python.org Thu Jan 10 03:42:50 2008
From: report at bugs.python.org (Tim Lesher)
Date: Thu, 10 Jan 2008 02:42:50 -0000
Subject: [New-bugs-announce] [issue1781] ConfigParser:
add_section('DEFAULT') causes duplicate sections.
In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za>
Message-ID: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za>
New submission from Tim Lesher:
ConfigParser doesn't prevent "manually" adding a section named DEFAULT;
however, doing so creates a duplicate, inaccessible [DEFAULT] section in
the config file:
----
>>> import sys, ConfigParser
>>> c = ConfigParser.ConfigParser()
>>> c.add_section('DEFAULT')
>>> c.write(sys.stdout)
[DEFAULT]
>>> c.set('DEFAULT', 'color', 'yellow')
>>> c.write(sys.stdout)
[DEFAULT]
color = yellow
[DEFAULT]
----
It seems that the correct thing to do would be to disallow
add_section('DEFAULT').
----------
components: Library (Lib)
messages: 59652
nosy: tlesher
severity: normal
status: open
title: ConfigParser: add_section('DEFAULT') causes duplicate sections.
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1781>
__________________________________
From report at bugs.python.org Thu Jan 10 15:47:52 2008
From: report at bugs.python.org (=?utf-8?q?Hrvoje_Nik=C5=A1i=C4=87?=)
Date: Thu, 10 Jan 2008 14:47:52 -0000
Subject: [New-bugs-announce] [issue1782] PyModule_AddIntConstant and
PyModule_AddStringConstant can leak
In-Reply-To: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za>
Message-ID: <1199976472.88.0.939409341911.issue1782@psf.upfronthosting.co.za>
New submission from Hrvoje Nik?i?:
PyModule_AddObject has somewhat strange reference-counting behavior in
that it *conditionally* steals a reference. In case of error it doesn't
change the reference to the passed object, but in case of success it
steals it. This means that, as written, PyModule_AddIntConstant and
PyModuleAddStringConstant can leak created objects if PyModule_AddObject
fails.
As far as I can tell, the correct way to write those functions would be
(using PyModule_AddIntConstant as the example):
int
PyModule_AddIntConstant(PyObject *m, const char *name, long value)
{
PyObject *o = PyInt_FromLong(value);
if (PyModule_AddObject(m, name, o) == 0)
return 0;
Py_XDECREF(o);
return -1;
}
PyModule_AddObject was obviously intended to enable writing the "simple"
code (it even gracefully handles being passed NULL object to add) like
the one in PyModule_AddIntConstant, but I don't see a way to enable such
usage and avoid both leaks and an interface change. Changing the
reference-counting behavior of PyModule_AddObject would be
backward-incompatible, but it might be a good idea to consider it for
Python 3.
If there is agreement that my analysis and the proposed fixes are
correct, I will produce a proper patch.
----------
components: Interpreter Core
messages: 59662
nosy: hniksic
severity: normal
status: open
title: PyModule_AddIntConstant and PyModule_AddStringConstant can leak
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1782>
__________________________________
From report at bugs.python.org Thu Jan 10 16:54:22 2008
From: report at bugs.python.org (Jukka Laurila)
Date: Thu, 10 Jan 2008 15:54:22 -0000
Subject: [New-bugs-announce] [issue1783] nonexistent data items declared as
exports in sysmodule.h
In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za>
Message-ID: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za>
New submission from Jukka Laurila:
sysmodule.h contains the following declarations for data to be exported
from the Python DLL, but these variables don't seem to exist anywhere:
PyAPI_DATA(PyObject *) _PySys_TraceFunc, *_PySys_ProfileFunc;
PyAPI_DATA(int) _PySys_CheckInterval;
Either the declarations should be removed or the variables should be
defined somewhere. I'm proposing the former.
----------
components: Interpreter Core
messages: 59663
nosy: jlaurila
severity: normal
status: open
title: nonexistent data items declared as exports in sysmodule.h
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1783>
__________________________________
From report at bugs.python.org Thu Jan 10 18:09:52 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 10 Jan 2008 17:09:52 -0000
Subject: [New-bugs-announce] [issue1784] Error with OptionParser.parse_args()
In-Reply-To: <1199984992.34.0.280732186134.issue1784@psf.upfronthosting.co.za>
Message-ID: <1199984992.34.0.280732186134.issue1784@psf.upfronthosting.co.za>
New submission from Raghuram Devarakonda:
Sorry for the generic title but I couldn't think of a better one. My
attempt to do "svn up && make" failed with the following exception from
setup.py:
----------------------
File "./setup.py", line 314, in detect_modules
if options.dirs:
AttributeError: Values instance has no attribute 'dirs'
----------------------
I isolated the problem to a small script.
----------------------
import optparse
parser = optparse.OptionParser()
parser.add_option("-I", dest="dirs", action="append")
options = parser.parse_args(['-I.', '-IInclude', '-I./Include'])[0]
if options.dirs:
print "opt = ", options.dirs
----------------------
When run with 2.5.1, the script prints "opt = ['.', 'Include',
'./Include']" but python from trunk gives the error:
Traceback (most recent call last):
File "../opttest.py", line 6, in <module>
if options.dirs:
AttributeError: Values instance has no attribute 'dirs'
----------
components: Library (Lib)
messages: 59672
nosy: draghuram
severity: normal
status: open
title: Error with OptionParser.parse_args()
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1784>
__________________________________
From report at bugs.python.org Thu Jan 10 18:39:32 2008
From: report at bugs.python.org (Dieter Maurer)
Date: Thu, 10 Jan 2008 17:39:32 -0000
Subject: [New-bugs-announce] [issue1785] "inspect" gets broken by some
descriptors
In-Reply-To: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
Message-ID: <1199986772.67.0.313630472197.issue1785@psf.upfronthosting.co.za>
New submission from Dieter Maurer:
The inspect functions "getmembers(cls)" and "classify_class_attrs(cls)"
require that for a class *cls* each name in "dir(cls)" can be retrieved
by "getattr(cls, name)". While this holds for usual class attributes, it
may well fail for descriptors (descriptors set by 'zope.interface' are a
real world example for this). Attached it as small script that
demonstrates the problem.
The bug affects 'pydoc' and the built in 'help' (which is in fact
'pydoc.help'). While 'pydoc' and 'help' do not break completely, they
can not present meaningful information for classes with some descriptors
----------
components: Library (Lib)
files: inspectBug.py
messages: 59675
nosy: dmaurer
severity: normal
status: open
title: "inspect" gets broken by some descriptors
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9117/inspectBug.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1785>
__________________________________
From report at bugs.python.org Fri Jan 11 02:05:06 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Jan 2008 01:05:06 -0000
Subject: [New-bugs-announce] [issue1786] pdb should set stdin+stdout around
exec call
In-Reply-To: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za>
Message-ID: <1200013506.35.0.644025895195.issue1786@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
When you type a command in pdb that happens to print something, the
output goes to sys.stdout, even if self.stdout references another file.
This makes it hard to debug code running inside a web server where
sys.stdout/stdout are connected to a socket (or a WSGI wrapper file);
the output "disappears" and ends up messing up the response.
Attached is a fix that temporarily changes sys.stdin/stdout to the
debugger's input and output. What do people think of this?
----------
components: Library (Lib)
files: pdb.diff
messages: 59686
nosy: gvanrossum
priority: low
severity: normal
status: open
title: pdb should set stdin+stdout around exec call
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9120/pdb.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1786>
__________________________________
From report at bugs.python.org Fri Jan 11 09:46:28 2008
From: report at bugs.python.org (Christian Theune)
Date: Fri, 11 Jan 2008 08:46:28 -0000
Subject: [New-bugs-announce] [issue1787] segfault in obmalloc.c
In-Reply-To: <1200041188.61.0.1232394323.issue1787@psf.upfronthosting.co.za>
Message-ID: <1200041188.61.0.1232394323.issue1787@psf.upfronthosting.co.za>
New submission from Christian Theune:
Python 2.4.4 on Linux crashes with following backtrace. Application is a
Zope server. The other threads seem to be idle at that moment, only the
segfaulting thread gives a reasonable backtrace (see attachment).
----------
components: Interpreter Core
files: backtrace
messages: 59697
nosy: ctheune
severity: critical
status: open
title: segfault in obmalloc.c
type: crash
versions: Python 2.4
Added file: http://bugs.python.org/file9121/backtrace
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1787>
__________________________________
From report at bugs.python.org Fri Jan 11 12:22:46 2008
From: report at bugs.python.org (Christopher Yeleighton)
Date: Fri, 11 Jan 2008 11:22:46 -0000
Subject: [New-bugs-announce] [issue1788] Outdated link in the tutorial
In-Reply-To: <1200050566.48.0.239641058268.issue1788@psf.upfronthosting.co.za>
Message-ID: <1200050566.48.0.239641058268.issue1788@psf.upfronthosting.co.za>
New submission from Christopher Yeleighton:
The page "About Python Tutorial"
<http://docs.python.org/tut/node20.html> incorrectly refers to the
Python Bug Tracker at SourceForge as
<http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=add>.
That page says "This tracker is CLOSED. Please use the new tracker
instead.". The new tracker is? guess where? At <http://bugs.python.org/>.
----------
components: Documentation
messages: 59702
nosy: spe-anatol
severity: minor
status: open
title: Outdated link in the tutorial
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1788>
__________________________________
From report at bugs.python.org Fri Jan 11 12:31:13 2008
From: report at bugs.python.org (Christopher Yeleighton)
Date: Fri, 11 Jan 2008 11:31:13 -0000
Subject: [New-bugs-announce] [issue1789] incorrect assumption about unsigned
long byte size
In-Reply-To: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
Message-ID: <1200051073.62.0.595441392864.issue1789@psf.upfronthosting.co.za>
New submission from Christopher Yeleighton:
Text of section 11.3 "Working with Binary Data Record Layouts" at
<http://docs.python.org/tut/node13.html#SECTION0013300000000000000000>
incorrectly assumes that unsigned long is 4 bytes long (with pack codes
"H" and "L" representing two and four byte unsigned numbers
respectively). It is may be a valid description of the author?s
environment, but it is invalid as a general statement and it creates the
wrong impression that the sample programme is portable and ready-to-go.
----------
components: Documentation
messages: 59704
nosy: spe-anatol
severity: normal
status: open
title: incorrect assumption about unsigned long byte size
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1789>
__________________________________
From report at bugs.python.org Fri Jan 11 14:24:20 2008
From: report at bugs.python.org (Vilya Harvey)
Date: Fri, 11 Jan 2008 13:24:20 -0000
Subject: [New-bugs-announce] [issue1790] xmlrpclib ServerProxy page has
out-of-date content
In-Reply-To: <1200057860.28.0.108205643467.issue1790@psf.upfronthosting.co.za>
Message-ID: <1200057860.28.0.108205643467.issue1790@psf.upfronthosting.co.za>
New submission from Vilya Harvey:
The page at 'http://docs.python.org/lib/serverproxy-objects.html'
contains the following text which should be removed as it's (a) not
especially relevant; and (b) out of date:
"Introspection methods are currently supported by servers written in
PHP, C and Microsoft .NET. Partial introspection support is included in
recent updates to UserLand Frontier. Introspection support for Perl,
Python and Java is available at the XML-RPC Hacks page."
In particular: Python has built in introspection support now; and the
URL for the XML-RPC hacks page returns a 404 error.
----------
components: Documentation
messages: 59706
nosy: vilya
severity: normal
status: open
title: xmlrpclib ServerProxy page has out-of-date content
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1790>
__________________________________
From report at bugs.python.org Fri Jan 11 14:27:34 2008
From: report at bugs.python.org (Vilya Harvey)
Date: Fri, 11 Jan 2008 13:27:34 -0000
Subject: [New-bugs-announce] [issue1791] The Library Reference still refers
to the old bug tracker.
In-Reply-To: <1200058054.48.0.510848038146.issue1791@psf.upfronthosting.co.za>
Message-ID: <1200058054.48.0.510848038146.issue1791@psf.upfronthosting.co.za>
New submission from Vilya Harvey:
The page at http://docs.python.org/lib/about.html refers people to the
old SourceForge bug tracker, rather than bugs.python.org.
----------
messages: 59707
nosy: vilya
severity: normal
status: open
title: The Library Reference still refers to the old bug tracker.
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1791>
__________________________________
From report at bugs.python.org Fri Jan 11 15:21:26 2008
From: report at bugs.python.org (Aaron Watters)
Date: Fri, 11 Jan 2008 14:21:26 -0000
Subject: [New-bugs-announce] [issue1792] o(n*n) marshal.dumps performance
for largish objects with patch
In-Reply-To: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za>
Message-ID: <1200061286.09.0.117532205028.issue1792@psf.upfronthosting.co.za>
New submission from Aaron Watters:
Much to my surprise I found that one of
my applications seemed to be running slow as a result
of marshal.dumps. I think the culprit is the w_more(...)
function, which grows the marshal buffer in 1k units.
This means that a marshal of size 100k will have 100
reallocations and string copies. Other parts of Python
(and java etc) have a proportional reallocation strategy
which reallocates a new size based on the existing size.
This mean a 100k marshal requires just 5 or so
reallocations and string copies (n log n versus n**2
asymptotic performance).
I humbly submit the following patch (based on python 2.6a0
source). I think it is a strict improvement on the existing
code, but I've been wrong before (twice ;)).
-- Aaron Watters
----------
components: Interpreter Core
files: marshal.diff
messages: 59710
nosy: aaron_watters
severity: normal
status: open
title: o(n*n) marshal.dumps performance for largish objects with patch
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9122/marshal.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1792>
__________________________________
From report at bugs.python.org Fri Jan 11 15:59:38 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Jan 2008 14:59:38 -0000
Subject: [New-bugs-announce] [issue1793] ctypes.util.find_msvcrt() function
In-Reply-To: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za>
Message-ID: <1200063578.88.0.774833430715.issue1793@psf.upfronthosting.co.za>
New submission from Thomas Heller:
I'm uploading this patch for discussion, in case someone cares.
This code (for Windows) adds a function ctypes.util.find_msvcrt(). This
function returns the filename of the MSVC runtime library that the
current Python executable uses. If calling functions from the C runtime
library, it is very important to use the SAME dll that Python uses.
Further, this patch changes ctypes.util.find_library(name) so that the
MSVC runtime library name is returned when searching for "c" or "m".
----------
assignee: theller
components: Extension Modules
files: ctypes-util.patch
keywords: patch
messages: 59713
nosy: theller
severity: normal
status: open
title: ctypes.util.find_msvcrt() function
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9123/ctypes-util.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1793>
__________________________________
From report at bugs.python.org Fri Jan 11 17:58:18 2008
From: report at bugs.python.org (Nashev)
Date: Fri, 11 Jan 2008 16:58:18 -0000
Subject: [New-bugs-announce] [issue1794] Hot keys must work in any keyboard
layout
In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za>
Message-ID: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za>
New submission from Nashev:
In most platform-depended applications hot keys are working by the
specified keys on a keyboard, independent of a current keyboard layout.
Not by the specified char.
Some application menus is displaying keyboard shortcut localized to main
layout for current language. But still working in any layout of keyboard
currently selected.
IDLE is not. :(
Can any one do something with it unpleasant situation?
----------
components: IDLE, Tkinter
messages: 59720
nosy: Nashev
severity: normal
status: open
title: Hot keys must work in any keyboard layout
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1794>
__________________________________
From report at bugs.python.org Fri Jan 11 19:27:32 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 11 Jan 2008 18:27:32 -0000
Subject: [New-bugs-announce] [issue1795] PEP 754 update
In-Reply-To: <1200076052.83.0.229945394685.issue1795@psf.upfronthosting.co.za>
Message-ID: <1200076052.83.0.229945394685.issue1795@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Hello Gregory!
I've implemented some of your ideas of PEP 754 for Python 2.6. I like to
update your PEP. Are you fine with the patch?
----------
components: Documentation
files: pep-0754.txt.patch
messages: 59734
nosy: tiran, warnes
priority: normal
severity: normal
status: open
title: PEP 754 update
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9126/pep-0754.txt.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1795>
__________________________________
From report at bugs.python.org Fri Jan 11 20:17:08 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Jan 2008 19:17:08 -0000
Subject: [New-bugs-announce] [issue1796] ctypes should allow a tuple when an
Array is expected
In-Reply-To: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za>
Message-ID: <1200079028.65.0.512467714236.issue1796@psf.upfronthosting.co.za>
New submission from Thomas Heller:
Another ctypes patch for discussion, if someone cares.
This patch allows to pass a tuple of the correct size, a ctypes pointer
to the correct itemtype, or None to foreign functions that expect ctypes
array instances. 'None' is passed as a NULL pointer.
Currently, only array instances are accepted.
----------
assignee: theller
components: Extension Modules
files: ctypes-arrays.patch
keywords: patch
messages: 59738
nosy: theller
severity: normal
status: open
title: ctypes should allow a tuple when an Array is expected
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9127/ctypes-arrays.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1796>
__________________________________
From report at bugs.python.org Fri Jan 11 21:34:58 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Jan 2008 20:34:58 -0000
Subject: [New-bugs-announce] [issue1797] ctypes NULL function pointers
should have a False bool value.
In-Reply-To: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za>
Message-ID: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za>
New submission from Thomas Heller:
ctypes NULL function pointers should have a False bool value.
----------
assignee: theller
components: Extension Modules
files: ctypes-funcptr.patch
keywords: patch
messages: 59744
nosy: theller
severity: normal
status: open
title: ctypes NULL function pointers should have a False bool value.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9129/ctypes-funcptr.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1797>
__________________________________
From report at bugs.python.org Fri Jan 11 21:51:37 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Jan 2008 20:51:37 -0000
Subject: [New-bugs-announce] [issue1798] Add ctypes calling convention that
allows safe access of errno
In-Reply-To: <1200084697.63.0.170138698691.issue1798@psf.upfronthosting.co.za>
Message-ID: <1200084697.63.0.170138698691.issue1798@psf.upfronthosting.co.za>
New submission from Thomas Heller:
This patch adds new calling conventions to ctypes foreign functions by
passing 'errno=True' or 'GetLastError=True' to the CDLL or WinDLL
constructor.
If CDLL(..., errno=True) or WinDLL(..., errno=True) is used, the
function objects available in the CDLL or WinDLL instance will set the C
global errno to zero before the actual call, and attach the C global
errno value after the call as 'errno' attribute to the function object.
This attribute is stored in thread-local storage.
Similarly, if CDLL(..., GetLastError=True) or WinDLL(...,
GetLastError=True) is used, the win32 api function 'SetLastError(0)' is
used to reset the windows last error code before the actual call, and
the value returned by 'GetLastError()' is attached as 'LastError'
attribute to the function object, in thread local storage. Of course
this only occurs on Windows.
The LastError and errno attributes are readonly from Python code,
accessing them before a foreign function call has occurred in the
current thread raises a ValueError.
----------
assignee: theller
components: Extension Modules
files: ctypes-errno.patch
keywords: patch
messages: 59748
nosy: theller
severity: normal
status: open
title: Add ctypes calling convention that allows safe access of errno
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9130/ctypes-errno.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1798>
__________________________________
From report at bugs.python.org Fri Jan 11 22:23:29 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 11 Jan 2008 21:23:29 -0000
Subject: [New-bugs-announce] [issue1799] Per user site-packages and setup.py
install --user patch
In-Reply-To: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za>
Message-ID: <1200086609.43.0.542576295235.issue1799@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch adds a per user site-packages directory and a --user option
for distutils' setup.py install. It also cleans up site.py a bit and
makes addsitepackages() extensible.
I'm going to write a mini PEP soonish.
----------
components: Distutils, Library (Lib)
files: trunk_usersite.patch
keywords: patch
messages: 59754
nosy: tiran
priority: normal
severity: normal
status: open
title: Per user site-packages and setup.py install --user patch
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9131/trunk_usersite.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1799>
__________________________________
From report at bugs.python.org Sat Jan 12 00:14:59 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Fri, 11 Jan 2008 23:14:59 -0000
Subject: [New-bugs-announce] [issue1800] ctypes callback fails when called
in Python with array argument
In-Reply-To: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
Message-ID: <1200093299.88.0.890377527012.issue1800@psf.upfronthosting.co.za>
New submission from Lenard Lindstrom:
When a callback is created with an array argument and then is called
from Python the callback function receives an array full of garbage.
Here is an example:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> A = c_int * 1
>>> A
<class '__main__.c_long_Array_1'>
>>> Foo = CFUNCTYPE(None, A)
>>> def py_foo(a):
... print a
... print a[0]
...
>>> foo = Foo(py_foo)
>>> foo(A(42))
<__main__.c_long_Array_1 object at 0x00B54440>
11879448
It works correctly when the callback is declared with a pointer argument
instead:
>>> A = c_int * 1
>>> Foo = CFUNCTYPE(None, POINTER(c_int))
>>> def py_foo(p):
... print p
... print p[0]
...
>>> foo = Foo(py_foo)
>>> foo(A(42))
<ctypes.LP_c_long object at 0x00B54440>
42
----------
components: Library (Lib), Windows
messages: 59759
nosy: kermode
severity: normal
status: open
title: ctypes callback fails when called in Python with array argument
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1800>
__________________________________
From report at bugs.python.org Sat Jan 12 00:46:33 2008
From: report at bugs.python.org (David Gardner)
Date: Fri, 11 Jan 2008 23:46:33 -0000
Subject: [New-bugs-announce] [issue1809] docs for os.symlink(src,
dst) doesn't mention exceptions
In-Reply-To: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za>
Message-ID: <1200095193.22.0.167933676219.issue1809@psf.upfronthosting.co.za>
New submission from David Gardner:
the docs for os.symlink at: http://docs.python.org/lib/os-file-dir.html
don't mention if the function raises an exception if there was a file
permission failure.
----------
components: Documentation
files: symtest.py
messages: 59762
nosy: dgardner
severity: minor
status: open
title: docs for os.symlink(src, dst) doesn't mention exceptions
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9133/symtest.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1809>
__________________________________
From report at bugs.python.org Sat Jan 12 00:58:42 2008
From: report at bugs.python.org (Thomas Lee)
Date: Fri, 11 Jan 2008 23:58:42 -0000
Subject: [New-bugs-announce] [issue1810] Partial AST compile() patch
In-Reply-To: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za>
Message-ID: <1200095922.65.0.677669960272.issue1810@psf.upfronthosting.co.za>
New submission from Thomas Lee:
This patch against HEAD provides the inverse operations to all the
ast2obj_* functions in Python/Python-ast.c: effectively, this allows
conversion to & from a PyObject representation of a Python AST.
Additionally, it updates the compile() builtin to allow it to compile
Python ASTs to bytecode.
The patch seems to work for most simple cases, but crashes out with a
segfault when trying to compile functions for some reason.
----------
components: Interpreter Core
files: ast-r01.patch
messages: 59764
nosy: thomas.lee
severity: normal
status: open
title: Partial AST compile() patch
versions: Python 2.6
Added file: http://bugs.python.org/file9134/ast-r01.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1810>
__________________________________
From report at bugs.python.org Sat Jan 12 06:20:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 12 Jan 2008 05:20:29 -0000
Subject: [New-bugs-announce] [issue1811] True division of integers could be
more accurate
In-Reply-To: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za>
Message-ID: <1200115229.68.0.232140016038.issue1811@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
Division of two longs can produce results that are needlessly
inaccurate:
>>> from __future__ import division
>>> 10**40/10**39
10.000000000000002
The correct result is, of course, 10.0, which is exactly representable
as a float.
The attached snippet of Python code shows that things don't have to be
this way.
----------
files: int_truediv.py
messages: 59798
nosy: marketdickinson
severity: minor
status: open
title: True division of integers could be more accurate
type: behavior
Added file: http://bugs.python.org/file9137/int_truediv.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1811>
__________________________________
From report at bugs.python.org Sat Jan 12 06:57:35 2008
From: report at bugs.python.org (Peter Donis)
Date: Sat, 12 Jan 2008 05:57:35 -0000
Subject: [New-bugs-announce] [issue1812] doctest _load_testfile function --
newline handling seems incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
New submission from Peter Donis:
When running doctest.testfile on a Linux machine, testing a txt file
saved on a Windows machine, doctest raised a SyntaxError exception for
each Windows newline in the txt file. On examining the code in the
_load_testfile function, it looks to me like there are actually two
issues:
(1) When there is no package keyword argument given, or the package
argument points to a package without a __loader__.get_data method, the
txt file data is retrieved by calling open(filename).read(); this is
the code path that my Windows-saved file triggered. However, since the
default file mode for open is 'r', not 'rU', there is no universal
newline conversion done on the file data. This was the issue I
initially observed.
(2) When there is a package.__loader__.get_data method found, that
method reads the data (using file mode 'rb'), and then newline
conversion is performed by this line:
return file_contents.replace(os.linesep, '\n')
This does not seem to match what universal newline conversion does;
that is supposed to convert both '\r\n' and '\r' to '\n', but running
on Linux, os.linesep is '\n', so the replace operation in the current
code is a no-op, even if the txt file was saved with Windows or Mac
newlines. It seems to me that the correct operation would be:
for linesep in ('\r\n', '\r'):
file_contents = file_contents.replace(linesep, '\n')
I have attached a diff against the current svn trunk showing my
suggested fix for both of the above issues.
Peter Donis
----------
components: Tests
files: doctest-fixes.diff
messages: 59801
nosy: pdonis
severity: normal
status: open
title: doctest _load_testfile function -- newline handling seems incorrect
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9138/doctest-fixes.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1812>
__________________________________
From report at bugs.python.org Sat Jan 12 16:00:13 2008
From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=)
Date: Sat, 12 Jan 2008 15:00:13 -0000
Subject: [New-bugs-announce] [issue1813] Codec lookup failing under turkish
locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
New submission from ?rni M?r J?nsson:
When switching to a turkish locale, the codecs registry fails on a codec
lookup which worked before the locale change.
This happens when the codec name contains an uppercase 'I'. What
happens, is just before doing a cache lookup, the string is normalized,
which includes a call to <ctype.h>'s tolower. tolower is locale
dependant, and the turkish locale handles 'I's different from other
locales. Thus, the lookup fails, since the normalization behaves
differently then it did before.
Replacing the tolower() call with this made the lookup work:
int my_tolower(char c)
{
if ('A' <= c && c <= 'Z')
c += 32;
return c;
}
PS: If the turkish locale is not supported, this here will enable it to
an Ubuntu system
a) sudo cp /usr/share/i18n/SUPPORTED /var/lib/locales/supported.d/local
(or just copy the lines with "tr" in them)
b) sudo dpkg-reconfigure locales
----------
components: Interpreter Core
files: verify_locale.py
messages: 59821
nosy: arnimar
severity: normal
status: open
title: Codec lookup failing under turkish locale
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9140/verify_locale.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________
From report at bugs.python.org Sat Jan 12 18:12:13 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 12 Jan 2008 17:12:13 -0000
Subject: [New-bugs-announce] [issue1814] Victor Stinner's GMP patch for longs
In-Reply-To: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
Message-ID: <1200157933.02.0.312333297821.issue1814@psf.upfronthosting.co.za>
New submission from Christian Heimes:
A while ago Victor Stinner has spend several weeks in porting PyLongs to
GMP:
http://mail.python.org/pipermail/python-3000/2007-September/010718.html
http://mail.python.org/pipermail/python-3000/2007-October/010755.html
Although his patch didn't give the speedup he hoped for, the patch might
be interesting someday in the future. He never submitted it to our bug
tracker. I'm posting it to conserve it for the future.
----------
components: Interpreter Core
files: py3k-long_gmp-v2.patch
messages: 59828
nosy: marketdickinson, tim_one, tiran
priority: normal
severity: normal
status: open
title: Victor Stinner's GMP patch for longs
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file9141/py3k-long_gmp-v2.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1814>
__________________________________
From report at bugs.python.org Sat Jan 12 21:14:28 2008
From: report at bugs.python.org (Daniel Eloff)
Date: Sat, 12 Jan 2008 20:14:28 -0000
Subject: [New-bugs-announce] [issue1815] Distutils add ability to skip build
[Feature Request]
In-Reply-To: <1200168868.22.0.518070014613.issue1815@psf.upfronthosting.co.za>
Message-ID: <1200168868.22.0.518070014613.issue1815@psf.upfronthosting.co.za>
New submission from Daniel Eloff:
There seems to be no way to skip the build step when running "setup.py
install" The behavior in such a case should be to skip build and use the
existing binaries as created in a separate build step or else print an
error. That way you can do "setup.py build" followed by "setup.py
install --skip-build" and you only have one build taking place.
The purpose of this would be to allow build to take place on a separate
computer to install. Currently I do this on Vista because MSVC 2003 is
not recommended or supported, and distutils won't use the installed MSVC
2005. So I do the build on a (virtual) XP machine and then install by
hand for lack of this option. I think Vista is a strong enough use case
to justify adding this feature.
----------
components: Distutils
messages: 59836
nosy: Eloff
severity: normal
status: open
title: Distutils add ability to skip build [Feature Request]
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1815>
__________________________________
From report at bugs.python.org Sat Jan 12 22:35:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 12 Jan 2008 21:35:55 -0000
Subject: [New-bugs-announce] [issue1816] sys.cmd_flags patch
In-Reply-To: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za>
Message-ID: <1200173755.29.0.21919679593.issue1816@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The output should be self explaining:
./python -tt -E -OO -Qnew -c "import sys; print sys.cmd_flags"
('Qnew', 'O', 'OO', 'E', 't', 'tt')
I'll provide doc updates and a mini test if the patch wanted.
----------
components: Interpreter Core
files: trunk_sys_cmd_flags.patch
keywords: patch
messages: 59840
nosy: tiran
priority: normal
severity: normal
status: open
title: sys.cmd_flags patch
versions: Python 2.6
Added file: http://bugs.python.org/file9143/trunk_sys_cmd_flags.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1816>
__________________________________
From report at bugs.python.org Sun Jan 13 02:58:56 2008
From: report at bugs.python.org (Alexandre Fiori)
Date: Sun, 13 Jan 2008 01:58:56 -0000
Subject: [New-bugs-announce] [issue1817] module-cgi: handling GET and POST
together
In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za>
Message-ID: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za>
New submission from Alexandre Fiori:
It looks like module-cgi cannot handle GET and POST together when using
FieldStorage. For instance, a <form action="script.py?key=value"
action="post"> is available through cgi.FormContent but not
cgi.FieldStorage when there are other <input> in the html form.
Very strange.
----------
messages: 59848
nosy: alef13
severity: normal
status: open
title: module-cgi: handling GET and POST together
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1817>
__________________________________
From report at bugs.python.org Sun Jan 13 23:27:16 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Jan 2008 22:27:16 -0000
Subject: [New-bugs-announce] [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
Here's a proof-of-concept patch. If approved, will change from
generator form to match the other readers and will add a test suite.
The idea corresponds to what is currently done by the dict reader but
returns a space and time efficient named tuple instead of a dict. Field
order is preserved and named attribute access is supported.
A writer is not needed because named tuples can be feed into the
existing writer just like regular tuples.
----------
assignee: barry
components: Library (Lib)
files: ntreader.diff
messages: 59866
nosy: barry, rhettinger
severity: normal
status: open
title: Add named tuple reader to CSV module
versions: Python 2.6
Added file: http://bugs.python.org/file9151/ntreader.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1818>
__________________________________
From report at bugs.python.org Mon Jan 14 01:48:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jan 2008 00:48:21 -0000
Subject: [New-bugs-announce] [issue1819] Speed hack for function calls with
named parameters
In-Reply-To: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za>
Message-ID: <1200271701.23.0.131498543337.issue1819@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
This is a patch for SVN trunk which substantially speeds up function
calls with named parameters. It does so by taking into account that
parameter names should be interned, so before doing full compares we do
a first quick loop to compare pointers.
On a microbenchmark the speedup is quite distinctive:
# With patch
$ ./python -m timeit -s "def f(a,b,c,d,e): pass" "f(1,2,3,4,e=5)"
1000000 loops, best of 3: 0.515 usec per loop
$ ./python -m timeit -s "def f(a,b,c,d,e): pass" "f(a=1,b=2,c=3,d=4,e=5)"
1000000 loops, best of 3: 0.652 usec per loop
# Without patch
$ ./python-orig -m timeit -s "def f(a,b,c,d,e): pass" "f(1,2,3,4,e=5)"
1000000 loops, best of 3: 0.664 usec per loop
$ ./python-orig -m timeit -s "def f(a,b,c,d,e): pass"
"f(a=1,b=2,c=3,d=4,e=5)"
1000000 loops, best of 3: 1.07 usec per loop
----------
components: Interpreter Core
files: namedparam.patch
messages: 59878
nosy: pitrou
severity: normal
status: open
title: Speed hack for function calls with named parameters
versions: Python 2.6
Added file: http://bugs.python.org/file9156/namedparam.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1819>
__________________________________
From report at bugs.python.org Mon Jan 14 05:20:28 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 14 Jan 2008 04:20:28 -0000
Subject: [New-bugs-announce] [issue1820] Enhance Object/structseq.c to match
namedtuple and tuple api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Raymond Hettinger wrote:
Here's a couple more if you want to proceed down that path:
1. Have structseq subclass from PyTupleObject so that isinstance(s,
tuple) returns True. This makes the object usable whenever
tuples are needed.
2. Add _fields, _asdict, and _replace to match the API in
collections.namedtuple(). The _fields tuple should only include the
visible positional fields while _asdict() and _replace() should include
all of the fields whether visible or accessible only by
attribute access.
3. Change the constructor to accept keyword args so that eval(repr(s))
== s works.
NOTE:
I've marked the task as easy but it's not a task for a total newbie.
It's a feasible yet challenging task for somebody who likes to get into
CPython core programming. Basic C knowledge is required!
----------
components: Interpreter Core
keywords: easy
messages: 59888
nosy: rhettinger, tiran
priority: low
severity: normal
status: open
title: Enhance Object/structseq.c to match namedtuple and tuple api
type: rfe
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
__________________________________
From report at bugs.python.org Mon Jan 14 10:55:00 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Mon, 14 Jan 2008 09:55:00 -0000
Subject: [New-bugs-announce] [issue1821] configure.ac change for FreeBSD
In-Reply-To: <1200304500.14.0.254653989015.issue1821@psf.upfronthosting.co.za>
Message-ID: <1200304500.14.0.254653989015.issue1821@psf.upfronthosting.co.za>
New submission from Jeroen Ruigrok van der Werven:
FreeBSD has in its ports currently a change for Modules/_ctypes/libffi/
configure.ac that adds amd64-*-freebsd* next to x86_64. I have attached
said patch (but updated to be a diff to trunk) and I hope it can be
changed in trunk to minimize patches in the ports tree.
----------
components: Build
files: patch-Modules-_ctypes-libffi-configure.diff
messages: 59893
nosy: asmodai
severity: minor
status: open
title: configure.ac change for FreeBSD
type: rfe
versions: Python 2.5
Added file: http://bugs.python.org/file9161/patch-Modules-_ctypes-libffi-configure.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1821>
__________________________________
From report at bugs.python.org Mon Jan 14 11:54:57 2008
From: report at bugs.python.org (Jonathan Share)
Date: Mon, 14 Jan 2008 10:54:57 -0000
Subject: [New-bugs-announce] [issue1822]
email.mime.multipart.MIMEMultipart.is_multipart() returns
false before items have been added.
In-Reply-To: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za>
Message-ID: <1200308097.55.0.0363931421733.issue1822@psf.upfronthosting.co.za>
New submission from Jonathan Share:
Steps to reproduce
==================
>>> from email.mime.multipart import MIMEMultipart
>>> foo = MIMEMultipart()
>>> foo.is_multipart()
False
Expected Result
===============
True should be returned from MIMEMultipart.is_multipart()
Notes
=====
Looking at the implementation of is_multipart() in email.Message it
would appear that if self._payload was initialised to an empty list in
the constructor of MIMEMultipart when _subparts is None, this would be
a sufficient fix for this issue.
However, from an outsider looking into this code for the first time,
this doesn't look like the best architecture, shouldn't the issue of
whether a message has multiple parts, and logic specific to this be
handled through inheritance. With the current implementation the
superclass makes assumptions about how a subclass is implemented, this
just feels wrong. Have I missed something, is there a good reason for
things being as they are today?
Feel free to take the discussion to the python-dev list, I have just
subscribed, and I am interested in fixing this issue myself in the next
bug day if someone can answer my questions above.
----------
components: Library (Lib)
messages: 59895
nosy: Sharebear
severity: normal
status: open
title: email.mime.multipart.MIMEMultipart.is_multipart() returns false before items have been added.
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1822>
__________________________________
From report at bugs.python.org Mon Jan 14 12:17:14 2008
From: report at bugs.python.org (Jonathan Share)
Date: Mon, 14 Jan 2008 11:17:14 -0000
Subject: [New-bugs-announce] [issue1823] Possible to set invalid
Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za>
Message-ID: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za>
New submission from Jonathan Share:
Steps to Reproduce
==================
>>> from email.mime.multipart import MIMEMultipart
>>> from email.mime.text import MIMEText
>>> multipart = MIMEMultipart()
>>> multipart.set_charset('UTF-8')
>>> text = MIMEText("sample text")
>>> multipart.attach(text)
>>> print multipart.as_string()
MIME-Version: 1.0
Content-Type: multipart/mixed; charset="utf-8";
boundary="===============0973828728=="
Content-Transfer-Encoding: base64
--===============0973828728==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
sample text
--===============0973828728==--
>>> multipart = MIMEMultipart()
>>> multipart.attach(text)
>>> multipart.set_charset('UTF-8')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/message.py", line 262, in set_charset
self._payload = charset.body_encode(self._payload)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/charset.py", line 384, in body_encode
return email.base64mime.body_encode(s)
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/
email/base64mime.py", line 148, in encode
enc = b2a_base64(s[i:i + max_unencoded])
TypeError: b2a_base64() argument 1 must be string or read-only buffer,
not list
Explanation
===========
The first example above demonstrates that if you call set_charset('UTF-
8') on a MIMEMultipart instance before adding child parts then it is
possible to generate a multipart/* message with an illegal Content-
Transfer-Encoding as specified by RFC 2045[1] "If an entity is
of type "multipart" the Content-Transfer-Encoding is not permitted to
have any value other than "7bit", "8bit" or "binary"."
In the second example, I demonstrate that if you try and call
set_charset after adding child parts, the code exceptions. The user
should at least be provided with a more targeted exception.
Notes
=====
Where should this be fixed? The smallest fix would be to add a check to
set_charset to see if it is dealing with with a multipart message but
as I express in issue1822 I feel the better design would be to move
this subtype specific logic into the appropriate subclass.
Again, this is something I'm willing to work on in next saturday's bug
day if I can get some feedback on my architectural concerns.
[1] http://tools.ietf.org/html/rfc2045#section-6.4
----------
components: Library (Lib)
messages: 59896
nosy: Sharebear
severity: normal
status: open
title: Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1823>
__________________________________
From report at bugs.python.org Mon Jan 14 17:11:02 2008
From: report at bugs.python.org (Jim Wilson)
Date: Mon, 14 Jan 2008 16:11:02 -0000
Subject: [New-bugs-announce] [issue1824] UUIDCreate()->UuidCreate() in
msilib docs.
In-Reply-To: <1200327062.94.0.635681629699.issue1824@psf.upfronthosting.co.za>
Message-ID: <1200327062.94.0.635681629699.issue1824@psf.upfronthosting.co.za>
New submission from Jim Wilson:
At http://docs.python.org/lib/module-msilib.html, UUIDCreate() is
misspelled.
----------
components: Documentation
messages: 59901
nosy: Jimbo
severity: minor
status: open
title: UUIDCreate()->UuidCreate() in msilib docs.
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1824>
__________________________________
From report at bugs.python.org Mon Jan 14 20:12:40 2008
From: report at bugs.python.org (Jim Wilson)
Date: Mon, 14 Jan 2008 19:12:40 -0000
Subject: [New-bugs-announce] [issue1825] msilib.add_data() takes exactly
three parameters
In-Reply-To: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za>
Message-ID: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za>
New submission from Jim Wilson:
At: http://docs.python.org/lib/module-msilib.html, add_data(...) is
documented to take two parameters, but invoking it with two draws a
complaint that three are needed. Examination of bdist_msi.py leads me
to believe the missing (middle) parameter is "table", but I can barely
distinguish a database from a hole in the ground.
----------
components: Documentation
messages: 59909
nosy: Jimbo
severity: minor
status: open
title: msilib.add_data() takes exactly three parameters
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1825>
__________________________________
From report at bugs.python.org Mon Jan 14 20:22:21 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Jan 2008 19:22:21 -0000
Subject: [New-bugs-announce] [issue1826] operator.attrgetter() should accept
dotted attribute paths
In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za>
Message-ID: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za>
New submission from Barry A. Warsaw:
operator.attrgetter() is neutered because it only accepts a single
attribute name, but it would really be much more useful if it accepted,
and followed a dotted attribute path, e.g.:
sorted(seq, key=operator.attrgetter('person.displayname'))
Of course attrgetter() would raise AttributeError if the entire path
could not be traversed.
----------
components: Library (Lib)
keywords: easy
messages: 59911
nosy: barry
severity: normal
status: open
title: operator.attrgetter() should accept dotted attribute paths
type: rfe
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1826>
__________________________________
From report at bugs.python.org Mon Jan 14 22:19:52 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 14 Jan 2008 21:19:52 -0000
Subject: [New-bugs-announce] [issue1827] svnversion_init() doesn't support
svn urls in sandbox/trunk
In-Reply-To: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za>
Message-ID: <1200345592.67.0.60555355752.issue1827@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Python fails to start if headurl points to a svn url under sandbox/.
Python/sysmodule.c:svnversion_init() should support those urls or at
least fail silently.
static const char headurl[] = "$HeadURL:
svn+ssh://pythondev at svn.python.org/sandbox/trunk/pep370/Python/sysmodule.c
$"
----------
components: Build, Interpreter Core
messages: 59920
nosy: tiran
priority: normal
severity: normal
status: open
title: svnversion_init() doesn't support svn urls in sandbox/trunk
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1827>
__________________________________
From report at bugs.python.org Tue Jan 15 02:02:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jan 2008 01:02:30 -0000
Subject: [New-bugs-announce] [issue1828] Renaming platform path modules
In-Reply-To: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za>
Message-ID: <1200358950.65.0.433797418679.issue1828@psf.upfronthosting.co.za>
New submission from Benjamin Peterson:
Currently, all the platform-specific path modules (ntpath, macpath, etc)
have normal module names. Since they are implementation details, they
should have a "_" prepended to their names. I doubt this would break
much code: I've never written witnessed any code outside of the os
module that uses the modules.
----------
components: Library (Lib)
messages: 59942
nosy: gutworth
severity: normal
status: open
title: Renaming platform path modules
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1828>
__________________________________
From report at bugs.python.org Tue Jan 15 02:02:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Jan 2008 01:02:50 -0000
Subject: [New-bugs-announce] [issue1829] Renaming platform path modules
In-Reply-To: <1200358970.58.0.364951248106.issue1829@psf.upfronthosting.co.za>
Message-ID: <1200358970.58.0.364951248106.issue1829@psf.upfronthosting.co.za>
New submission from Benjamin Peterson:
Currently, all the platform-specific path modules (ntpath, macpath, etc)
have normal module names. Since they are implementation details, they
should have a "_" prepended to their names as is the custom for private
objects. I doubt this would break much code: I've never written
witnessed any code outside of the os module that uses the modules.
----------
components: Library (Lib)
messages: 59943
nosy: gutworth
severity: normal
status: open
title: Renaming platform path modules
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1829>
__________________________________
From report at bugs.python.org Tue Jan 15 12:50:29 2008
From: report at bugs.python.org (Peter Harris)
Date: Tue, 15 Jan 2008 11:50:29 -0000
Subject: [New-bugs-announce] [issue1830] pygettext.py syntax error
In-Reply-To: <1200397829.12.0.24320735319.issue1830@psf.upfronthosting.co.za>
Message-ID: <1200397829.12.0.24320735319.issue1830@psf.upfronthosting.co.za>
New submission from Peter Harris:
Tools/i18n/pygettext.py contains a syntax error.
On line 665, there is an old u'' string for testing unicode on pre-3.0
python.
It should be OK to remove it.
----------
components: Demos and Tools
messages: 59961
nosy: scav
severity: normal
status: open
title: pygettext.py syntax error
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1830>
__________________________________
From report at bugs.python.org Tue Jan 15 14:47:10 2008
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 15 Jan 2008 13:47:10 -0000
Subject: [New-bugs-announce] [issue1831] ctypes.Structure constructor
arguments
In-Reply-To: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za>
Message-ID: <1200404830.93.0.0957399164262.issue1831@psf.upfronthosting.co.za>
New submission from Armin Rigo:
The constructor of ctypes structures should probably not silently accept
the bogus arguments shown in the attached example.
----------
components: Extension Modules
files: bogus_args.py
messages: 59964
nosy: arigo, cfbolz, fijal
severity: normal
status: open
title: ctypes.Structure constructor arguments
versions: Python 2.6
Added file: http://bugs.python.org/file9174/bogus_args.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1831>
__________________________________
From report at bugs.python.org Tue Jan 15 18:21:11 2008
From: report at bugs.python.org (Jacques Lemire)
Date: Tue, 15 Jan 2008 17:21:11 -0000
Subject: [New-bugs-announce] [issue1835] Update version number in __init__.py
In-Reply-To: <1200417671.24.0.488273286588.issue1835@psf.upfronthosting.co.za>
Message-ID: <1200417671.24.0.488273286588.issue1835@psf.upfronthosting.co.za>
New submission from Jacques Lemire:
In the distutils directory the file __init__.py is not updated to 3.0.
----------
components: Distutils
messages: 59974
nosy: jlp
severity: minor
status: open
title: Update version number in __init__.py
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1835>
__________________________________
From report at bugs.python.org Tue Jan 15 22:30:09 2008
From: report at bugs.python.org (Kathryn M Kowalski)
Date: Tue, 15 Jan 2008 21:30:09 -0000
Subject: [New-bugs-announce] [issue1836] 'weekly' rotating logging file
rotation incorrect
In-Reply-To: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za>
Message-ID: <1200432609.46.0.111117657939.issue1836@psf.upfronthosting.co.za>
New submission from Kathryn M Kowalski:
Log file did not 'rotate' on day requested.
Fixed code in Lib/logging/handlers.py class TimedRotatingFileHandler
Compare excerpt of my fix below to the original
# Case 2) The day to rollover is further in the interval (i.e., today is
# day 2 (Wednesday) and rollover is on day 6 (Sunday). Days to
# next rollover is simply 6 - 2, or 4.
# Case 3) The day to rollover is behind us in the interval (i.e., today
# is day 5 (Saturday) and rollover is on day 3 (Thursday).
# Days to rollover is 6 - 5 + 3 + 1, or 5. In this case, it's
the
# number of days left in the current week (1) plus the number
# of days in the next week until the rollover day (4).
if when.startswith('W'):
day = t[6] # 0 is Monday
if self.dayOfWeek > day:
daysToWait = (self.dayOfWeek - day)
self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24))
if self.dayOfWeek < day:
daysToWait = (6 - day) + self.dayOfWeek + 1
----------
components: Library (Lib)
messages: 59983
nosy: kmk
severity: normal
status: open
title: 'weekly' rotating logging file rotation incorrect
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1836>
__________________________________
From report at bugs.python.org Wed Jan 16 00:46:10 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Jan 2008 23:46:10 -0000
Subject: [New-bugs-announce] [issue1837] Add Queue.LifoQueue and
Queue.PriorityQueue
In-Reply-To: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za>
Message-ID: <1200440770.17.0.987165250317.issue1837@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
Rather than just documenting that this can be done, it is better to
simply provide working implementations that show exactly how to subclass
the Queue module. This also lets users easily select or switch between
the most appropriate structure. Since API is the same, the learning
curve is near zero.
If accepted, will add a full set of tests.
----------
assignee: gvanrossum
components: Library (Lib)
files: more_queues.diff
keywords: patch
messages: 59984
nosy: gvanrossum, rhettinger
severity: normal
status: open
title: Add Queue.LifoQueue and Queue.PriorityQueue
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9179/more_queues.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1837>
__________________________________
From report at bugs.python.org Wed Jan 16 10:38:45 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 16 Jan 2008 09:38:45 -0000
Subject: [New-bugs-announce] [issue1838] Ctypes C-level infinite recursion
In-Reply-To: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
Message-ID: <1200476325.02.0.310225010268.issue1838@psf.upfronthosting.co.za>
New submission from Maciek Fijalkowski:
Code in example abuses the fact that _as_parameter_ is passed
recursively. Not sure if this is for fixing or not.
----------
components: Extension Modules
files: crash.py
messages: 59993
nosy: arigo, fijal
severity: normal
status: open
title: Ctypes C-level infinite recursion
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9183/crash.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1838>
__________________________________
From report at bugs.python.org Wed Jan 16 11:48:46 2008
From: report at bugs.python.org (Peter Harris)
Date: Wed, 16 Jan 2008 10:48:46 -0000
Subject: [New-bugs-announce] [issue1840] Tools/i18n/msgfmt.py fixes for
Python 3.0
In-Reply-To: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za>
Message-ID: <1200480526.71.0.697758724205.issue1840@psf.upfronthosting.co.za>
New submission from Peter Harris:
Python 3.0: Use bytes instead of str to construct the binary file,
don't try to .sort a dict's keys().
This patch is a tentative fix - in one place I've had to provide an
encoding from str to bytes and I've guessed UTF-8, which may be OK for
most .po files, but possibly not all.
----------
components: Demos and Tools
files: msgfmt.diff
messages: 59994
nosy: scav
severity: normal
status: open
title: Tools/i18n/msgfmt.py fixes for Python 3.0
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file9185/msgfmt.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1840>
__________________________________
From report at bugs.python.org Wed Jan 16 17:45:42 2008
From: report at bugs.python.org (Jim Wilson)
Date: Wed, 16 Jan 2008 16:45:42 -0000
Subject: [New-bugs-announce] [issue1854] Broken link in msilib docs
In-Reply-To: <1200501942.7.0.0578865641851.issue1854@psf.upfronthosting.co.za>
Message-ID: <1200501942.7.0.0578865641851.issue1854@psf.upfronthosting.co.za>
New submission from Jim Wilson:
at http://docs.python.org/lib/database-objects.html, under "See Also:",
the link, MSIOpenView leads nowhere. From earlier reading, I suspect it
should be "MSIDatabaseOpenView" (or perhaps
"MSIDatabaseOpenViewPaddedOutEvenMoreToMakeYourEyesGlazeOver").
----------
components: Documentation
messages: 59998
nosy: Jimbo
severity: minor
status: open
title: Broken link in msilib docs
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1854>
__________________________________
From report at bugs.python.org Wed Jan 16 21:13:21 2008
From: report at bugs.python.org (Jim Wilson)
Date: Wed, 16 Jan 2008 20:13:21 -0000
Subject: [New-bugs-announce] [issue1855] Codepage unset in
msilib.init_database()
In-Reply-To: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za>
Message-ID: <1200514401.27.0.0393918828447.issue1855@psf.upfronthosting.co.za>
New submission from Jim Wilson:
At
http://msdn2.microsoft.com/en-us/library/aa367864(VS.85,printer).aspx,
Satanic Verses sayeth: "The Codepage Summary property must be set
before any string properties are set in the summary information.", but
so far as I can tell, PID_CODEPAGE is never used in msilib.__init__.py,
etal.
Confirming evidence: msilib's GetProperty(msilib.PID_CODEPAGE) raises
"Not Implemented" on Python2.5.1's own .msi file.
----------
components: Distutils
messages: 60006
nosy: Jimbo
severity: normal
status: open
title: Codepage unset in msilib.init_database()
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1855>
__________________________________
From report at bugs.python.org Thu Jan 17 03:01:16 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Jan 2008 02:01:16 -0000
Subject: [New-bugs-announce] [issue1856] shutdown (exit) can hang or
segfault with daemon threads running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
New submission from Gregory P. Smith:
This probably applies to 3.0 as well but i have not tested it there.
Here are some sample failures:
=========== A ==============
Exception in thread Thread-0000000001 (most likely raised during
interpreter shutdown):Exception in thread Thread-0000000003 (most likely
raised during interpreter shutdown):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xe4cf1bb0 (LWP 22281)]
0x080c0824 in PyEval_EvalFrameEx (f=0x820d59c, throwflag=0)
at Python/ceval.c:2633
2633 if (tstate->frame->f_exc_type != NULL)
============================
=========== B ==============
Exception in thread Thread-0000000001 (most likely raised during
interpreter shutdown):
Traceback (most recent call last):
File "/home/gps/oss/python/trunk/Lib/threading.py", line 486, in
__bootstrap_inner
File "thread_exit.py", line 24, in run
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'add'
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xf7fe08e0 (LWP 21703)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x4dac1af0 in sem_wait at GLIBC_2.0 () from
/lib/tls/i686/cmov/libpthread.so.0
#2 0xf7fe08c0 in ?? ()
#3 0x080ec9d5 in PyThread_acquire_lock (lock=0x0, waitflag=1)
at Python/thread_pthread.h:349
#4 0x080be6d5 in PyEval_RestoreThread (tstate=0x8168050) at
Python/ceval.c:314
#5 0x0806caf5 in file_dealloc (f=0xf7f29d58) at Objects/fileobject.c:396
#6 0x0810be36 in frame_dealloc (f=0x8201f04) at Objects/frameobject.c:416
#7 0x080e28d2 in PyThreadState_Clear (tstate=0x8184068)
at Python/pystate.c:217
#8 0x080e2994 in PyInterpreterState_Clear (interp=0x8168008)
at Python/pystate.c:105
#9 0x080e473b in Py_Finalize () at Python/pythonrun.c:444
#10 0x080e428e in handle_system_exit () at Python/pythonrun.c:1641
#11 0x080e447a in PyErr_PrintEx (set_sys_last_vars=1)
at Python/pythonrun.c:1087
#12 0x080e510d in PyRun_SimpleFileExFlags (fp=0x817bd98,
filename=0xffffd73c "thread_exit.py", closeit=1, flags=0xffffd518)
at Python/pythonrun.c:996
#13 0x0805753b in Py_Main (argc=1, argv=0xffffd5b4) at Modules/main.c:574
#14 0x4d95cea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#15 0x080566c1 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) bt
#0 0x080c0824 in PyEval_EvalFrameEx (f=0x820d59c, throwflag=0)
at Python/ceval.c:2633
#1 0x080c451c in PyEval_EvalFrameEx (f=0x820d40c, throwflag=0)
at Python/ceval.c:3690
#2 0x080c451c in PyEval_EvalFrameEx (f=0x820d13c, throwflag=0)
at Python/ceval.c:3690
#3 0x080c5fd4 in PyEval_EvalCodeEx (co=0xf7f22d58, globals=0xf7f962d4,
locals=0x0, args=0xf7f46e18, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2876
#4 0x0810d4d6 in function_call (func=0xf7f41454, arg=0xf7f46e0c, kw=0x0)
at Objects/funcobject.c:524
#5 0x0805b0b4 in PyObject_Call (func=0xf7f41454, arg=0x0, kw=0x0)
at Objects/abstract.c:1872
#6 0x08061008 in instancemethod_call (func=0xf7f41454, arg=0xf7f46e0c,
kw=0x0)
at Objects/classobject.c:2509
#7 0x0805b0b4 in PyObject_Call (func=0xf7f3fdec, arg=0x0, kw=0x0)
at Objects/abstract.c:1872
#8 0x080be8f9 in PyEval_CallObjectWithKeywords (func=0x0, arg=0xf7fa002c,
kw=0x0) at Python/ceval.c:3473
#9 0x080efb4d in t_bootstrap (boot_raw=0x820c910)
at ./Modules/threadmodule.c:422
#10 0x4dabd341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0x4da114ee in clone () from /lib/tls/i686/cmov/libc.so.6
============================
And as with all problems of this sort... sometimes the program exits
normally without any problems.
I ran python trunk:60012 under gdb above. But these problems occur on
older versions such as 2.4.
----------
components: Interpreter Core
files: thread_exit.py
messages: 60014
nosy: gregory.p.smith
severity: normal
status: open
title: shutdown (exit) can hang or segfault with daemon threads running
type: crash
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9188/thread_exit.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
__________________________________
From report at bugs.python.org Thu Jan 17 12:30:58 2008
From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_Stadler?=)
Date: Thu, 17 Jan 2008 11:30:58 -0000
Subject: [New-bugs-announce] [issue1857] subprocess.Popen.poll/__del__ API
breakage
In-Reply-To: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za>
Message-ID: <1200569458.8.0.233156398307.issue1857@psf.upfronthosting.co.za>
New submission from Ren? Stadler:
The commit to r45234 has added an internally used keyword attribute
named _deadstate to subprocess.Popen.poll, which is called by the
__del__ method of this class. If you derived your own class from
subprocess.Popen that overrides .poll() without taking kwargs, the
__del__ method will trigger a TypeError about the unexpected keyword
argument.
Attached is a very simple test program that triggers the problem. It
runs just fine with Python 2.4 however.
----------
components: Library (Lib)
files: subprocessapi.py
messages: 60024
nosy: rene.st
severity: major
status: open
title: subprocess.Popen.poll/__del__ API breakage
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9190/subprocessapi.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1857>
__________________________________
From report at bugs.python.org Thu Jan 17 13:33:53 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 17 Jan 2008 12:33:53 -0000
Subject: [New-bugs-announce] [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
New submission from Tarek Ziad?:
explained here: http://wiki.python.org/moin/EnhancedPyPI
The patch also adds unit tests for command/register.py and
command/upload.py
----------
components: Distutils
files: patch.diff
messages: 60025
nosy: tarek
severity: normal
status: open
title: Make .pypirc handle multiple servers
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9191/patch.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________
From report at bugs.python.org Thu Jan 17 13:40:27 2008
From: report at bugs.python.org (Tom Parker)
Date: Thu, 17 Jan 2008 12:40:27 -0000
Subject: [New-bugs-announce] [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
New submission from Tom Parker:
If a piece of text given to textwrap contains one or more "\n", textwrap
does not break at that point. I would have expected "\n" characters to
cause forced breaks.
----------
components: Library (Lib)
messages: 60026
nosy: palfrey
severity: minor
status: open
title: textwrap doesn't linebreak on "\n"
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
__________________________________
From report at bugs.python.org Thu Jan 17 14:27:57 2008
From: report at bugs.python.org (=?utf-8?q?=CE=A7=CF=81=CE=AE=CF=83=CF=84=CE=BF=CF=82_=CE=93=CE=B5=CF=89=CF=81=CE=B3=CE=AF=CE=BF=CF=85_(Christos_Georgiou)?=)
Date: Thu, 17 Jan 2008 13:27:57 -0000
Subject: [New-bugs-announce] [issue1860] traceback.print_last fails
In-Reply-To: <1200576477.85.0.583100874485.issue1860@psf.upfronthosting.co.za>
Message-ID: <1200576477.85.0.583100874485.issue1860@psf.upfronthosting.co.za>
New submission from ??????? ???????? (Christos Georgiou):
traceback.print_last() depends on the existence of sys.last_type,
sys.last_value, sys.last_traceback, which don't always exist when
called. See attached example file. I will shortly send the patch for
Lib/traceback.py
----------
components: Library (Lib)
files: test_tb_print_last.py
messages: 60028
nosy: tzot
severity: normal
status: open
title: traceback.print_last fails
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9193/test_tb_print_last.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1860>
__________________________________
From report at bugs.python.org Thu Jan 17 17:38:35 2008
From: report at bugs.python.org (Patrick Bureau)
Date: Thu, 17 Jan 2008 16:38:35 -0000
Subject: [New-bugs-announce] [issue1861] sched scheduler.queue class member
is unordered
In-Reply-To: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za>
Message-ID: <1200587915.01.0.288464638328.issue1861@psf.upfronthosting.co.za>
New submission from Patrick Bureau:
In Python 2.4, retrieving sched's scheduler.queue class member would
return a time ordered list of events as expected.
Since Python 2.5, the same operation retrieves a list of unordered
scheduled events. This makes it difficult to know which events are
really next in queue, especially if scheduled at the same time.
----------
components: Library (Lib)
messages: 60033
nosy: pbureau
severity: minor
status: open
title: sched scheduler.queue class member is unordered
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1861>
__________________________________
From report at bugs.python.org Thu Jan 17 17:56:24 2008
From: report at bugs.python.org (Rich)
Date: Thu, 17 Jan 2008 16:56:24 -0000
Subject: [New-bugs-announce] [issue1862] Error on "Save As" in IDLE (Vista
32-bit)
In-Reply-To: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za>
Message-ID: <1200588984.34.0.741777378011.issue1862@psf.upfronthosting.co.za>
New submission from Rich:
Issue 1743 might be related to this.
Using "Save As..." in IDLE does work, but if breakpoints.lst is hidden
(which it is when Python generates it) it also generates this error in
the Shell:
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Program Files\Python25\lib\lib-tk\Tkinter.py", line 1403, in
__call__
return self.func(*args)
File "C:\Program Files\Python25\lib\idlelib\IOBinding.py", line 357,
in save_as
self.editwin.store_file_breaks()
File "C:\Program Files\Python25\lib\idlelib\PyShell.py", line 209, in
store_file_breaks
new_file = open(self.breakpointPath,"w")
IOError: [Errno 13] Permission
denied: 'C:\\Users\\Rich\\.idlerc\\breakpoints.lst'
The error is not generated if I manually unhide the breakpoints file.
The issue is unaffected by the hidden (or not) status of the .idlerc
folder.
----------
components: IDLE
messages: 60034
nosy: Piffen, kbk, loewis, richjtd, tiran
severity: normal
status: open
title: Error on "Save As" in IDLE (Vista 32-bit)
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1862>
__________________________________
From report at bugs.python.org Thu Jan 17 22:03:58 2008
From: report at bugs.python.org (Willard)
Date: Thu, 17 Jan 2008 21:03:58 -0000
Subject: [New-bugs-announce] [issue1863] NameError with genexp in class scope
In-Reply-To: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za>
Message-ID: <1200603837.96.0.69062914341.issue1863@psf.upfronthosting.co.za>
New submission from Willard:
The following code does not work like expected, it triggers a NameError.
class C:
a = 42
list(a for _ in 'x')
>>> NameError: global name 'a' is not defined
This issue was discussed on comp.lang.python in the thread "Is this a
bug, or is it me?".
----------
components: Interpreter Core
messages: 60060
nosy: cptnwillard
severity: minor
status: open
title: NameError with genexp in class scope
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1863>
__________________________________
From report at bugs.python.org Fri Jan 18 12:29:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jan 2008 11:29:38 -0000
Subject: [New-bugs-announce] [issue1864] test_locale doesn't use unittest
In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za>
Message-ID: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
test_locale uses its own result printout and doesn't throw an exception
when a test fails. It should be probably converted to unittest.
----------
components: Library (Lib)
messages: 60085
nosy: pitrou
severity: normal
status: open
title: test_locale doesn't use unittest
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1864>
__________________________________
From report at bugs.python.org Fri Jan 18 17:23:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 18 Jan 2008 16:23:35 -0000
Subject: [New-bugs-announce] [issue1865] Bytes alias for 2.6
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
New submission from Christian Heimes:
As discussed on the ml. It adds a bytes builtin and syntax for b"" and br"".
----------
components: Interpreter Core
files: trunk_bytes.patch
keywords: patch
messages: 60099
nosy: tiran
priority: normal
severity: normal
status: open
title: Bytes alias for 2.6
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9203/trunk_bytes.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1865>
__________________________________
From report at bugs.python.org Fri Jan 18 19:46:10 2008
From: report at bugs.python.org (phil)
Date: Fri, 18 Jan 2008 18:46:10 -0000
Subject: [New-bugs-announce] [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
New submission from phil:
In PyInt_FromString(), please change the type of the first
arg from char * to const char *. That is, of course, if
the function indeed does not write to the string. (I took
a quick look at the code; it doesn't appear to.)
If the function does modify the string, it should be
documented.
I'm getting a compiler error in some C++ code when I
use a std::string::c_str() as the arg. Of course, I could
cast away the const, but paranoid as I am, I'd like
reassurance that I can do so with impunity. :-)
----------
components: Extension Modules
messages: 60108
nosy: philipdumont
severity: minor
status: open
title: const arg for PyInt_FromString
type: rfe
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
__________________________________
From report at bugs.python.org Fri Jan 18 20:44:01 2008
From: report at bugs.python.org (Santiago Gala)
Date: Fri, 18 Jan 2008 19:44:01 -0000
Subject: [New-bugs-announce] [issue1867] patch for pydoc to work in py3k
In-Reply-To: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za>
Message-ID: <1200685441.85.0.862976764101.issue1867@psf.upfronthosting.co.za>
New submission from Santiago Gala:
Basically I'm finding to simple errors:
* an iterable where it expects a list, I solved it using a simple list
comprehension on the original iterable
* it tries to write a string to the socket, I used "UTF-8" both in the
Content-Type header and in the conversion to bytes. It could easyly be
parameterized.
This two changes enabled me to get a basic pydoc running.
----------
components: Documentation
files: pydoc.patch
messages: 60112
nosy: sgala
severity: normal
status: open
title: patch for pydoc to work in py3k
versions: Python 3.0
Added file: http://bugs.python.org/file9204/pydoc.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1867>
__________________________________
From report at bugs.python.org Sat Jan 19 00:55:07 2008
From: report at bugs.python.org (Peter Fein)
Date: Fri, 18 Jan 2008 23:55:07 -0000
Subject: [New-bugs-announce] [issue1868] threading.local doesn't free attrs
when assigning thread exits
In-Reply-To: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
Message-ID: <1200700507.1.0.447960408936.issue1868@psf.upfronthosting.co.za>
New submission from Peter Fein:
threading.local doesn't free attributes assigned to a local() instance
when the assigning thread exits. See attached patch for
_threading_local.py doctests.
Per discussion with Crys and arkanes in #python, this may be an issue
with PyThreadState_Clear / PyThreadState_GetDict
This appears to affect both thread._local and _threading_local.py
----------
components: Library (Lib)
files: _threading_local.py.patch
messages: 60127
nosy: pfein
severity: normal
status: open
title: threading.local doesn't free attrs when assigning thread exits
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9212/_threading_local.py.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1868>
__________________________________
From report at bugs.python.org Sat Jan 19 02:04:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jan 2008 01:04:26 -0000
Subject: [New-bugs-announce] [issue1869] Builtin round function is sometimes
inaccurate for floats
In-Reply-To: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
Message-ID: <1200704666.74.0.121276369369.issue1869@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
The documentation for the builtin round(x, n) says:
"Values are rounded to the closest multiple of 10 to the power minus n."
This isn't always true; for example:
Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> round(562949953421312.5, 1)
562949953421312.62
Here 562949953421312.5 is exactly representable as an IEEE754 double, so the output from the round function should be
exactly the same as the input.
Assigning this to myself to remind me to try to fix it someday.
----------
assignee: marketdickinson
messages: 60129
nosy: marketdickinson
priority: low
severity: minor
status: open
title: Builtin round function is sometimes inaccurate for floats
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1869>
__________________________________
From report at bugs.python.org Sat Jan 19 11:48:50 2008
From: report at bugs.python.org (ThurnerRupert)
Date: Sat, 19 Jan 2008 10:48:50 -0000
Subject: [New-bugs-announce] [issue1870] bug tracker exception,
when searching for "creator"
In-Reply-To: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za>
Message-ID: <1200739730.74.0.0823503686607.issue1870@psf.upfronthosting.co.za>
New submission from ThurnerRupert:
filling out "creator" gives the following traceback:
Traceback (most recent call last):
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/client.py", line 770, in renderContext
result = pt.render(self, None, None, **args)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/templating.py", line 323, in render
getEngine().getContext(c), output, tal=1, strictinsert=0)()
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 192, in __call__
self.interpret(self.program)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret
handlers[opcode](self, args)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 666, in do_useMacro
self.interpret(macro)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret
handlers[opcode](self, args)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 411, in do_optTag_tal
self.do_optTag(stuff)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 396, in do_optTag
return self.no_tag(start, program)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 391, in no_tag
self.interpret(program)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret
handlers[opcode](self, args)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 689, in do_defineSlot
self.interpret(slot)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret
handlers[opcode](self, args)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 411, in do_optTag_tal
self.do_optTag(stuff)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 396, in do_optTag
return self.no_tag(start, program)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 391, in no_tag
self.interpret(program)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 236, in interpret
handlers[opcode](self, args)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/TAL/TALInterpreter.py", line 462, in
do_setLocal_tal
self.engine.setLocal(name, self.engine.evaluateValue(expr))
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/PageTemplates/TALES.py", line 227, in evaluate
return expression(self)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/PageTemplates/Expressions.py", line 194, in
__call__
return self._eval(econtext)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/PageTemplates/Expressions.py", line 189, in _eval
return render(ob, econtext.vars)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/PageTemplates/Expressions.py", line 95, in render
ob = ob()
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/cgi/templating.py", line 2463, in batch
l = [id for id in klass.filter(matches, filterspec, sort, group)
File "/home/roundup/roundup-production//lib/python2.4/site-
packages/roundup/backends/rdbms_common.py", line 2178, in filter
del d[None]
KeyError
----------
components: None
messages: 60142
nosy: ThurnerRupert
severity: minor
status: open
title: bug tracker exception, when searching for "creator"
type: crash
versions: 3rd party
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1870>
__________________________________
From report at bugs.python.org Sat Jan 19 12:04:02 2008
From: report at bugs.python.org (ThurnerRupert)
Date: Sat, 19 Jan 2008 11:04:02 -0000
Subject: [New-bugs-announce] [issue1871] help fix memory usage or leak -
edgewall trac 0.11 blocked ...
In-Reply-To: <1200740642.79.0.946360280482.issue1871@psf.upfronthosting.co.za>
Message-ID: <1200740642.79.0.946360280482.issue1871@psf.upfronthosting.co.za>
New submission from ThurnerRupert:
how could one find a memory problem in python. edgewall trac 0.11
seems blocked for such a problem, where nobody had a really helpful
idea for nearly three weeks.
see http://groups.google.com/group/trac-
dev/browse_thread/thread/116e519da54f16b.
----------
messages: 60147
nosy: ThurnerRupert
severity: normal
status: open
title: help fix memory usage or leak - edgewall trac 0.11 blocked ...
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1871>
__________________________________
From report at bugs.python.org Sat Jan 19 17:15:52 2008
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 19 Jan 2008 16:15:52 -0000
Subject: [New-bugs-announce] [issue1872] change the bool struct format code
from 't' to '?'
In-Reply-To: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za>
Message-ID: <1200759352.1.0.256938962764.issue1872@psf.upfronthosting.co.za>
New submission from Thomas Heller:
Currently the struct module uses the format code 't' for the bool
datatype (this was added in python 2.6, in revision 53508). This
conflicts with the specification in PEP 3118, which proposes the '?'
format character for the bool type, 't' is proposed in the patch for a
bit type.
This patch changes the struct module format code for 'bool' from 't' to '?'.
----------
components: Extension Modules
files: struct-bool.patch
keywords: patch
messages: 60187
nosy: theller
severity: normal
status: open
title: change the bool struct format code from 't' to '?'
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9218/struct-bool.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1872>
__________________________________
From report at bugs.python.org Sat Jan 19 17:35:08 2008
From: report at bugs.python.org (Roy Smith)
Date: Sat, 19 Jan 2008 16:35:08 -0000
Subject: [New-bugs-announce] [issue1873] threading.Thread.join() description
could be more explicit
In-Reply-To: <1200760508.83.0.199534103582.issue1873@psf.upfronthosting.co.za>
Message-ID: <1200760508.83.0.199534103582.issue1873@psf.upfronthosting.co.za>
New submission from Roy Smith:
At http://docs.python.org/lib/thread-objects.html, under join(), it says:
"As join() always returns None, you must call isAlive() to decide whether a timeout
happened."
This would be better if it were more explicit, i.e.
"As join() always returns None, you must call isAlive() after calling join() to
decide whether a timeout happened; a return value of True indicates the join() call
timed out."
----------
components: Documentation
messages: 60190
nosy: roysmith
severity: minor
status: open
title: threading.Thread.join() description could be more explicit
type: rfe
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1873>
__________________________________
From report at bugs.python.org Sat Jan 19 19:37:22 2008
From: report at bugs.python.org (Jonathan Share)
Date: Sat, 19 Jan 2008 18:37:22 -0000
Subject: [New-bugs-announce] [issue1874] email parser does not register a
defect for invalid Content-Transfer-Encoding on multipart messages
In-Reply-To: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za>
Message-ID: <1200767841.97.0.882225337338.issue1874@psf.upfronthosting.co.za>
New submission from Jonathan Share:
Although the documentation of FeedParser states that "It will populate
a message object's defects attribute with a list of any problems it
found in a message." no defect is found in the test case I am about to
upload. The message in the test case is broken because it specifies a
Content-Transfer-Encoding that is not valid for multipart/* messages[1].
I've spent some time today looking at the parser and cannot see where
the parser is doing anything with the Content-Transfer-Encoding of a
multipart message, leading me to believe that there might be another
bug here with regards to not honoring Content-Transfer-Encoding at all
for multipart/* messages but I don't have any more time today to look
at it, I'll have to go away and read the rfc really well.
If someone can guide me on how to get this test to pass then I can
probably get a good test case and fix written for issue1823 as well.
[1] http://tools.ietf.org/html/rfc2045#section-6.4
----------
components: Library (Lib)
messages: 60207
nosy: Sharebear, barry
severity: normal
status: open
title: email parser does not register a defect for invalid Content-Transfer-Encoding on multipart messages
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1874>
__________________________________
From report at bugs.python.org Sat Jan 19 19:55:50 2008
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 19 Jan 2008 18:55:50 -0000
Subject: [New-bugs-announce] [issue1875] "if 0: return" not raising
SyntaxError
In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za>
Message-ID: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za>
New submission from Armin Rigo:
Can you guess why importing the attached x.py does nothing, without
printing "hello" at all?
The real issue shown in that example is that 'return' and 'yield'
outside a function are ignored instead of giving a SyntaxError if they
are optimized away by 'if 0:'.
(Hint about x.py: the yield sets the CO_GENERATOR flag before it gets
optimized away. So clearly, that's a way to comment out a whole module
-- just put "if 0: yield" anywhere at top-level...)
----------
components: Interpreter Core
files: x.py
messages: 60213
nosy: arigo
priority: low
severity: minor
status: open
title: "if 0: return" not raising SyntaxError
versions: Python 2.6
Added file: http://bugs.python.org/file9231/x.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1875>
__________________________________
From report at bugs.python.org Sun Jan 20 15:16:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jan 2008 14:16:32 -0000
Subject: [New-bugs-announce] [issue1876] bogus attrgetter test in
test_operator
In-Reply-To: <1200838592.82.0.0545990493887.issue1876@psf.upfronthosting.co.za>
Message-ID: <1200838592.82.0.0545990493887.issue1876@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
In test_operator we find the following lines:
class C(object):
def __getattr(self, name):
raise SyntaxError
self.failUnlessRaises(AttributeError,
operator.attrgetter('foo'), C())
Obviously "__getattr" has no effect. However, when changing it to
"__getattr__", the test fails. Is there is any motivation for this test
in the first place? If yes, why the typo and why the error when the typo
is corrected?
----------
components: Tests
messages: 61297
nosy: pitrou
severity: normal
status: open
title: bogus attrgetter test in test_operator
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1876>
__________________________________
From report at bugs.python.org Sun Jan 20 15:48:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Jan 2008 14:48:08 -0000
Subject: [New-bugs-announce] [issue1877] unhelpful error when calling
"python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
New submission from Georg Brandl:
gbr at lap ~/devel/python> ./python Lib
Traceback (most recent call last):
File "Lib/runpy.py", line 99, in _run_module_as_main
loader, code, fname = _get_module_details(mod_name)
File "Lib/runpy.py", line 86, in _get_module_details
raise ImportError("No code object available for %s" % mod_name)
ImportError: No code object available for __main__
----------
assignee: ncoghlan
messages: 61303
nosy: georg.brandl, ncoghlan
severity: normal
status: open
title: unhelpful error when calling "python <dirname>"
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________
From report at bugs.python.org Sun Jan 20 18:40:58 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Sun, 20 Jan 2008 17:40:58 -0000
Subject: [New-bugs-announce] [issue1878] class attribute cache failure
(regression)
In-Reply-To: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
Message-ID: <1200850858.46.0.900672455163.issue1878@psf.upfronthosting.co.za>
New submission from Paul Pogonyshev:
I have a regression from Python 2.5 to Python SVN (would-be-2.6). I
believe this because of class attribute caching. The problem shown
below happens because AbstractGCProtector is an extension class. So,
Python interpreter doesn't have a chance to notice set_default() method
below changes a class attribute.
>>> from notify.all import *
>>> original_protector = AbstractGCProtector.default
>>> new_protector = FastGCProtector ()
>>> AbstractGCProtector.default is new_protector
False
>>> AbstractGCProtector.default is original_protector
True
Please note that this a regression. This code works as expected in 2.3
and 2.5.
----------
components: Interpreter Core
messages: 61316
nosy: _doublep
severity: major
status: open
title: class attribute cache failure (regression)
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1878>
__________________________________
From report at bugs.python.org Mon Jan 21 03:51:29 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jan 2008 02:51:29 -0000
Subject: [New-bugs-announce] [issue1879] sqrt(-1) doesn't raise ValueError
on OS X
In-Reply-To: <1200883888.97.0.437374079609.issue1879@psf.upfronthosting.co.za>
Message-ID: <1200883888.97.0.437374079609.issue1879@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
On OS X 10.4, and probably other versions of OS X too, calls to math.log and math.sqrt that
should raise ValueError instead return a NaN:
Python 2.6a0 (trunk:60144, Jan 20 2008, 21:43:56)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import sqrt, log
>>> sqrt(-1)
nan
>>> log(-1)
nan
The problem is that OS X doesn't set errno in these cases. Attached is a quick fix for this.
Note that there's already a test for this (test_exceptions in test_math.py), but this test is
only run in verbose mode.
See also issue #871657.
----------
components: Extension Modules
files: sqrt_minus_one.patch
keywords: patch
messages: 61373
nosy: marketdickinson
priority: normal
severity: normal
status: open
title: sqrt(-1) doesn't raise ValueError on OS X
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9247/sqrt_minus_one.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1879>
__________________________________
From report at bugs.python.org Mon Jan 21 03:58:52 2008
From: report at bugs.python.org (David W. Lambert)
Date: Mon, 21 Jan 2008 02:58:52 -0000
Subject: [New-bugs-announce] [issue1880] Generalize math.hypot function
In-Reply-To: <1200884332.34.0.152014748905.issue1880@psf.upfronthosting.co.za>
Message-ID: <1200884332.34.0.152014748905.issue1880@psf.upfronthosting.co.za>
New submission from David W. Lambert:
Please generalize math.hypot. While I don't have a survey of python
codes, it seems to me unlikely for this change to break existing
programs.
import math
def hypot(*args):
'''
Return the Euclidean vector length.
>>> from math import hypot, sqrt
>>> hypot(5,12) # traditional definition
13.0
>>> hypot()
0.0
>>> hypot(-6.25)
6.25
>>> hypot(1,1,1) == sqrt(3) # diagonal of unit box
True
'''
return math.sqrt(sum(arg*arg for arg in args))
I propose this version as closest to:
>>> print sys.version
2.5.1 (r251:54863, Jan 4 2008, 17:15:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)]
>>> print math.hypot.__doc__
hypot(x,y)
Return the Euclidean distance, sqrt(x*x + y*y).
Thanks,
Dave.
PS. I don't understand why python is so restrictive. Although hypot
is in the math library, it could be written in EAFP style as
def hypot(*args):
return sum(arg*arg for arg in args)**0.5
Rather than review the entire python library for items to generalize,
I'll accept that the resulting errors would confuse "the penguin on my
tele". "hypot" crosses me most often. I've not yet needed a version
in the complex domain, such as my second version.
I typically fill my need for length with scipy.sqrt(scipy.dot(v,v)),
only to realize that for the short vectors I use, standard python
constructs always perform faster than scipy
----------
components: Library (Lib)
messages: 61374
nosy: LambertDW
severity: minor
status: open
title: Generalize math.hypot function
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1880>
__________________________________
From report at bugs.python.org Mon Jan 21 11:10:00 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 21 Jan 2008 10:10:00 -0000
Subject: [New-bugs-announce] [issue1881] increase parser stack limit
In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za>
Message-ID: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za>
New submission from Ralf Schmitt:
The parser can handle nested structures only up to a certain limit.
The limit is currently reached around 33 deeply nested lists, which is a
bit too low.
This patch increases that limit by a factor of 10.
see http://bugs.python.org/issue215555 for further discussion.
----------
messages: 61379
nosy: schmir
severity: normal
status: open
title: increase parser stack limit
type: rfe
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1881>
__________________________________
From report at bugs.python.org Mon Jan 21 11:51:52 2008
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 21 Jan 2008 10:51:52 -0000
Subject: [New-bugs-announce] [issue1882] py_compile does not follow PEP 0263
In-Reply-To: <1200912712.61.0.875613384462.issue1882@psf.upfronthosting.co.za>
Message-ID: <1200912712.61.0.875613384462.issue1882@psf.upfronthosting.co.za>
New submission from Jakub Wilk:
PEP 0263 allows an encoding declaration in the second line, but
py_compile seems not to recognize such ones:
>>> MODULE = "\n# encoding=UTF-8\nU = u'\xc3\xb3'\n"
>>> f = file('tmp.py', 'w')
>>> f.write(MODULE)
>>> f.close()
>>> from py_compile import compile
>>> compile('tmp.py', 'tmp_buggy.pyc', 'tmp_buggy.py', doraise = True)
>>> import tmp
>>> import tmp_buggy
>>> tmp.U
u'\xf3'
>>> tmp_buggy.U
u'\xc3\xb3'
----------
components: Library (Lib)
messages: 61384
nosy: jwilk
severity: major
status: open
title: py_compile does not follow PEP 0263
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1882>
__________________________________
From report at bugs.python.org Mon Jan 21 18:14:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Jan 2008 17:14:08 -0000
Subject: [New-bugs-announce] [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
New submission from Georg Brandl:
so that this doesn't get lost...
----------
assignee: georg.brandl
components: Library (Lib)
messages: 61418
nosy: georg.brandl
severity: normal
status: open
title: Adapt pydoc to new doc system
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________
From report at bugs.python.org Mon Jan 21 20:14:06 2008
From: report at bugs.python.org (Jim Wilson)
Date: Mon, 21 Jan 2008 19:14:06 -0000
Subject: [New-bugs-announce] [issue1884]
msilib.SetProperty(msilib.PID_CODEPAGE,
'1252') raises 0x65d = type mismatch
In-Reply-To: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za>
Message-ID: <1200942846.08.0.229949051028.issue1884@psf.upfronthosting.co.za>
New submission from Jim Wilson:
I believe Codepage (a summary property which must be set *before* any
other string value), is a string. Documentation admits it might also be
an integer, but it doesn't matter. Both foo.SetProperty(PID_CODEPAGE,
'1252') and foo.SetProperty(PID_CODEPAGE, 1252) raise "unknown error 65d".
I believe 0x65d (1629d) to be ERROR_DATATYPE_MISMATCH.
----------
components: Build
messages: 61440
nosy: Jimbo
severity: normal
status: open
title: msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1884>
__________________________________
From report at bugs.python.org Mon Jan 21 21:43:32 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Jan 2008 20:43:32 -0000
Subject: [New-bugs-announce] [issue1885] [distutils] - error when processing
the "--formats=tar" option
In-Reply-To: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za>
Message-ID: <1200948212.05.0.299370220663.issue1885@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
Steps to reproduce the problem:
1: Run "python setup.py sdist --formats=gztar,tar".
2. dist directory now contains "module.gztar" and "module.tar" files
as expected.
3: Run "python setup.py sdist --formats=tar,gztar".
4. dist directory now contains only "module.gztar" file.
Reason:
Since for every argument specified in "--formats" option a new .tar file
is created every time by using the UNIX tar utility, the .tar file is
removed/overwritten when creating subsequent archives.
----------
components: Distutils
messages: 61445
nosy: giampaolo.rodola
severity: normal
status: open
title: [distutils] - error when processing the "--formats=tar" option
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1885>
__________________________________
From report at bugs.python.org Mon Jan 21 22:28:40 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Jan 2008 21:28:40 -0000
Subject: [New-bugs-announce] [issue1886] Permit to easily use distutils
"--formats=tar, gztar, bztar" on all systems
In-Reply-To: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za>
Message-ID: <1200950920.27.0.810221024065.issue1886@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
Currently creating tar, gztar, bztar source distributions using the
"--formats=tar,gztar,bztar" distutils option requires external utilities
(tar and possibly one of gzip, bzip2, or compress) to be installed on
the system since distutils uses them.
This is not a problem on most UNIX systems which provide these utilities
by default. On all other systems (e.g. Windows) it is required to
install such utilities separately and have the executables available in
a directory on your PATH in order to have them work.
I discussed this on distutils mailing list [1] and tried to fix this
hassle.
The patch in attachment permit to use the distutils
"--formats=tar,gztar,bztar" option without need of having tar/gzip/bzip2
utilities installed by using the tarfile module instead of os.spawn().
It also fixes bug #1885 [2].
[1] http://mail.python.org/pipermail/distutils-sig/2008-January/008654.html
[2] http://bugs.python.org/issue1885
----------
components: Distutils
files: file.diff
messages: 61451
nosy: giampaolo.rodola
severity: normal
status: open
title: Permit to easily use distutils "--formats=tar,gztar,bztar" on all systems
versions: Python 2.5
Added file: http://bugs.python.org/file9253/file.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1886>
__________________________________
From report at bugs.python.org Tue Jan 22 01:31:59 2008
From: report at bugs.python.org (Monty Taylor)
Date: Tue, 22 Jan 2008 00:31:59 -0000
Subject: [New-bugs-announce] [issue1887] distutils doesn't support
out-of-source builds
In-Reply-To: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
Message-ID: <1200961919.23.0.699852435444.issue1887@psf.upfronthosting.co.za>
New submission from Monty Taylor:
I've been using distutils as part of a larger automake-managed project.
One of the functions that automake provides is "make distcheck" which it
has been especially hard to get distutils to play along with.
So I added a src-dir option to allow for passing src dir to the build.
----------
components: Distutils
files: distutils.patch
messages: 61471
nosy: sdirector
severity: normal
status: open
title: distutils doesn't support out-of-source builds
versions: Python 2.5
Added file: http://bugs.python.org/file9257/distutils.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1887>
__________________________________
From report at bugs.python.org Tue Jan 22 04:12:43 2008
From: report at bugs.python.org (Lee June)
Date: Tue, 22 Jan 2008 03:12:43 -0000
Subject: [New-bugs-announce] [issue1888] strange 'global'
In-Reply-To: <1200971563.65.0.992284576383.issue1888@psf.upfronthosting.co.za>
Message-ID: <1200971563.65.0.992284576383.issue1888@psf.upfronthosting.co.za>
New submission from Lee June:
hi, all. my friend found a strange behave with 'global', I posted it
in the 'python-list at python.org' as this:
[quote]
why the following 2 prg give different results? a.py is ok, but b.py
is 'undefiend a'
I am using Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC
v.1310 32 bit (Intel)] on win32
#a.py
def run():
if 1==2: # note, it always False
global a
a=1
run()
a
#b.py
def run():
a=1
run()
a
[/quote]
I believe that is bug which breaks the consistency of python syntax and
common english langauge sense- just like we can do '1>None' in
python2.x,
but not in python 3.x.
So please fix this bug.
If you do think that is the feature of python and refuse to fix it,
please
at least mention the craziness in the document. Uhm, maybe I can do the
later,
but I don't think it is good.
btw, there are some replies(you can search them in the archive), I
think the
other users met more questions, for example
From: "Gabriel Genellina" <gagsl-py2 at yahoo.com.ar>
To: python-list at python.org
Date: Mon, 21 Jan 2008 18:36:19 -0200
Subject: Re: problem with 'global'
En Mon, 21 Jan 2008 17:36:29 -0200, Duncan Booth
<duncan.booth at invalid.invalid> escribi?:
> Marc 'BlackJack' Rintsch <bj_666 at gmx.net> wrote:
>
>> On Mon, 21 Jan 2008 17:08:46 -0200, Gabriel Genellina wrote:
>>
>>> The future statement is another example, even worse:
>>>
>>> if 0:
>>> from __future__ import with_statement
>>>
>>> with open("xxx") as f:
>>> print f
>>
>> In Python >=2.5 it's a compile time error if that import is not the
very
>> first statement in a source file.
>>
> That doesn't appear to be the case. With Python 2.5.1 the example
> Gabriel quoted will compile and run.
Yes, but now I've noticed that the 0 has some magic. The code above
works
with 0, 0.0, 0j and ''. Using None, False, () or [] as the condition,
will
trigger the (expected) syntax error.
Mmm, it may be the peephole optimizer, eliminating the dead branch. This
function has an empty body:
def f():
if 0: print "0"
if 0.0: print "0.0"
if 0j: print "0j"
if '': print "empty"
py> dis.dis(f)
5 0 LOAD_CONST 0 (None)
3 RETURN_VALUE
The other false values tested (False, None, () and []) aren't optimized
out.
--
Gabriel Genellina
----------
components: Interpreter Core
messages: 61482
nosy: oyster
severity: major
status: open
title: strange 'global'
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1888>
__________________________________
From report at bugs.python.org Tue Jan 22 04:28:41 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 22 Jan 2008 03:28:41 -0000
Subject: [New-bugs-announce] [issue1889] string literal documentation
differs from implementation
In-Reply-To: <1200972521.05.0.240928400296.issue1889@psf.upfronthosting.co.za>
Message-ID: <1200972521.05.0.240928400296.issue1889@psf.upfronthosting.co.za>
New submission from Andrew Dalke:
The reference manual documentation for raw string literals says
"""Note also that a single backslash followed by a newline is
interpreted as those two characters as part of the string, *not* as a line
continuation."""
This is not the observed behavior.
>>> s = """ABC\
... 123"""
>>> s
'ABC123'
>>>
Line continuations are ignored by triple quoted strings.
In addition, the reference manual documentation for "\x" escapes says
| ``\xhh`` | Character with hex value *hh* | (4,5) |
where footnote (4) stays
Unlike in Standard C, at most two hex digits are accepted.
However, the implementation requires exactly two hex digits:
>>> "\x41"
'A'
>>> "\x4."
ValueError: invalid \x escape
>>> "\x4"
ValueError: invalid \x escape
>>>
----------
components: Documentation
messages: 61484
nosy: dalke
severity: minor
status: open
title: string literal documentation differs from implementation
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1889>
__________________________________
From report at bugs.python.org Tue Jan 22 11:47:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 22 Jan 2008 10:47:00 -0000
Subject: [New-bugs-announce] [issue1902] Test
In-Reply-To: <1200998820.47.0.13912653563.issue1902@psf.upfronthosting.co.za>
Message-ID: <1200998820.47.0.13912653563.issue1902@psf.upfronthosting.co.za>
New submission from Christian Heimes:
ggpolo has reported an issue with the bug tracker
----------
messages: 61494
nosy: tiran
severity: normal
status: open
title: Test
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1902>
__________________________________
From report at bugs.python.org Tue Jan 22 11:54:03 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 22 Jan 2008 10:54:03 -0000
Subject: [New-bugs-announce] [issue1904] Add key argument to heapq functions
In-Reply-To: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za>
Message-ID: <1200999243.33.0.342848472968.issue1904@psf.upfronthosting.co.za>
New submission from Guilherme Polo:
Wouldn't it be useful to add a "key" argument to some heapq functions ?
So you could construct a heap from dict items list based on the second
item of each tuple, for example.
----------
components: Library (Lib)
messages: 61496
nosy: gpolo
severity: normal
status: open
title: Add key argument to heapq functions
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1904>
__________________________________
From report at bugs.python.org Tue Jan 22 15:35:01 2008
From: report at bugs.python.org (Kevin Walzer)
Date: Tue, 22 Jan 2008 14:35:01 -0000
Subject: [New-bugs-announce] [issue1905] PythonLauncher not working
correctly on OS X 10.5/Leopad
In-Reply-To: <1201012501.41.0.744457037048.issue1905@psf.upfronthosting.co.za>
Message-ID: <1201012501.41.0.744457037048.issue1905@psf.upfronthosting.co.za>
New submission from Kevin Walzer:
On Mac OS X 10.5 (Leopard), using Python 2.5.1, double-clicking on a
Python script in the Finder does not produce the expected behavior, i.e.
launch a terminal session and then execute the script. These errors are
logged in the console:
1/22/08 9:28:56 AM Python Launcher[53692] doscript: Could not activate
Terminal
1/22/08 9:28:56 AM Python Launcher[53692] doscript: AESend(activate):
error -600
1/22/08 9:28:56 AM Python Launcher[53692] Exit status: -600
1/22/08 9:28:56 AM com.apple.launchd[118] ([0x0-
0x434434].org.python.PythonLauncher[53692]) Stray process with PGID
equal to this dead job: PID 53694 PPID 1 Terminal
I did not observe these behaviors on OS X 10.4.
----------
components: Macintosh
messages: 61506
nosy: wordtech
severity: major
status: open
title: PythonLauncher not working correctly on OS X 10.5/Leopad
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1905>
__________________________________
From report at bugs.python.org Tue Jan 22 16:19:30 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 22 Jan 2008 15:19:30 -0000
Subject: [New-bugs-announce] [issue1906] Distinguish between cfunction,
cvar and cmacro
In-Reply-To: <1201015170.0.0.526066716057.issue1906@psf.upfronthosting.co.za>
Message-ID: <1201015170.0.0.526066716057.issue1906@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The new doc system has cmacro but the html output for cmacro is not
distinguishable from cfunction.
I also noticed that the docs use cfunction instead of cmacro on several
occasions.
----------
assignee: georg.brandl
components: Documentation
messages: 61511
nosy: georg.brandl, tiran
priority: normal
severity: normal
status: open
title: Distinguish between cfunction, cvar and cmacro
type: rfe
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1906>
__________________________________
From report at bugs.python.org Tue Jan 22 16:57:57 2008
From: report at bugs.python.org (Guillaume Nourry-Marquis)
Date: Tue, 22 Jan 2008 15:57:57 -0000
Subject: [New-bugs-announce] [issue1907] Httplib.py not supporting timeout -
Propose Fix attached
In-Reply-To: <1201017477.23.0.0342238589364.issue1907@psf.upfronthosting.co.za>
Message-ID: <1201017477.23.0.0342238589364.issue1907@psf.upfronthosting.co.za>
New submission from Guillaume Nourry-Marquis:
The httplib file wasn'T supporting a timeout feature which was essential
for my load testing application I built. In order to do that, I had to
append a parameter to the connect function, which takes a socket timeout
value integer in seconds.
def connect(self,timeout=None):
"""Connect to the host and port specified in __init__."""
msg = "getaddrinfo returns an empty list"
for res in socket.getaddrinfo(self.host, self.port, 0,
socket.SOCK_STREAM):
af, socktype, proto, canonname, sa = res
try:
self.sock = socket.socket(af, socktype, proto)
#Guillaume's timeout
self.sock.settimeout(timeout)
if self.debuglevel > 0:
print "connect: (%s, %s)" % (self.host, self.port)
self.sock.connect(sa)
except socket.error, msg:
if self.debuglevel > 0:
print 'connect fail:', (self.host, self.port)
if self.sock:
self.sock.close()
self.sock = None
continue
break
if not self.sock:
raise socket.error, msg
Simple patch, but it was essential for my work.
----------
components: Library (Lib)
files: httplib.py
messages: 61512
nosy: xlash
severity: minor
status: open
title: Httplib.py not supporting timeout - Propose Fix attached
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9263/httplib.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1907>
__________________________________
From report at bugs.python.org Tue Jan 22 19:47:10 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 22 Jan 2008 18:47:10 -0000
Subject: [New-bugs-announce] [issue1908] make html fails - patchlevel is
missing
In-Reply-To: <1201027630.32.0.368466766809.issue1908@psf.upfronthosting.co.za>
Message-ID: <1201027630.32.0.368466766809.issue1908@psf.upfronthosting.co.za>
New submission from Christian Heimes:
This happens after
$ cd Docs
$ rm -rf tools
$ svn up
$ make update
$ make html
mkdir -p build/html build/doctrees
python tools/sphinx-build.py -b html -d build/doctrees -D
latex_paper_size= . build/html
Traceback (most recent call last):
File "tools/sphinx-build.py", line 23, in <module>
from sphinx import main
File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/__init__.py",
line 19, in <module>
from sphinx.builder import builders
File "/home/heimes/dev/python/trunk/Doc/tools/sphinx/builder.py", line
34, in <module>
from sphinx.patchlevel import get_version_info, get_sys_version_info
ImportError: No module named patchlevel
make: *** [build] Fehler 1
patchlevel is no longer in spinx but I found one in sphinxext.
----------
assignee: georg.brandl
components: Documentation
messages: 61519
nosy: georg.brandl, tiran
priority: urgent
severity: normal
status: open
title: make html fails - patchlevel is missing
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1908>
__________________________________
From report at bugs.python.org Tue Jan 22 21:04:33 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Jan 2008 20:04:33 -0000
Subject: [New-bugs-announce] [issue1909] Backport: Mixing default keyword
arguments with *args
In-Reply-To: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
Message-ID: <1201032273.11.0.991902181918.issue1909@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
Need to backport Py3.0's functionality so that the following is valid
syntax:
def f(a, *args, v=None):
. . .
----------
assignee: tiran
components: Interpreter Core
messages: 61530
nosy: rhettinger, tiran
severity: normal
status: open
title: Backport: Mixing default keyword arguments with *args
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1909>
__________________________________
From report at bugs.python.org Wed Jan 23 00:58:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Jan 2008 23:58:44 -0000
Subject: [New-bugs-announce] [issue1910] _threading_local should use with
In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za>
Message-ID: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za>
New submission from Benjamin Peterson:
I was reading _threading_local and noticed it didn't use the with
statment, yet. So, I cooked up this trivial patch. I hope this isn't to
small. Thanks for your time.
----------
components: Library (Lib)
files: _threading_local-with-stmt.diff
messages: 61551
nosy: gutworth
severity: normal
status: open
title: _threading_local should use with
versions: Python 2.6
Added file: http://bugs.python.org/file9269/_threading_local-with-stmt.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1910>
__________________________________
From report at bugs.python.org Wed Jan 23 02:29:31 2008
From: report at bugs.python.org (Jon Wilson)
Date: Wed, 23 Jan 2008 01:29:31 -0000
Subject: [New-bugs-announce] [issue1911] webbrowser.open firefox 3 issues
In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za>
Message-ID: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za>
New submission from Jon Wilson:
webbrowser.open('http://example.com')
opens something like:
file:///path/to/home/directory/"http://example.com"
in firefox 3 beta 2. this behavior of firefox will most like not change
in the stable release.
----------
components: Extension Modules
messages: 61552
nosy: elessar
severity: normal
status: open
title: webbrowser.open firefox 3 issues
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1911>
__________________________________
From report at bugs.python.org Wed Jan 23 07:06:48 2008
From: report at bugs.python.org (Matti Punkeri)
Date: Wed, 23 Jan 2008 06:06:48 -0000
Subject: [New-bugs-announce] [issue1912] Segmentation fault
In-Reply-To: <1201068408.15.0.769067205132.issue1912@psf.upfronthosting.co.za>
Message-ID: <1201068408.15.0.769067205132.issue1912@psf.upfronthosting.co.za>
New submission from Matti Punkeri:
Python seg faults after 20-30 hours. The running Python application is
a Qt based user interface which handles several SSH threads. Backtrace
is attached.
----------
files: backtrace.txt
messages: 61558
nosy: mpunkeri
severity: major
status: open
title: Segmentation fault
type: crash
versions: Python 2.4
Added file: http://bugs.python.org/file9270/backtrace.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1912>
__________________________________
From report at bugs.python.org Wed Jan 23 09:25:28 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 23 Jan 2008 08:25:28 -0000
Subject: [New-bugs-announce] [issue1913] test_pep263 fails
In-Reply-To: <1201076728.2.0.475967660638.issue1913@psf.upfronthosting.co.za>
Message-ID: <1201076728.2.0.475967660638.issue1913@psf.upfronthosting.co.za>
New submission from Christian Heimes:
$ ./python Lib/test/regrtest.py -v test_pep263
test_pep263
test_compilestring (test.test_pep263.PEP263Test) ... FAIL
test_pep263 (test.test_pep263.PEP263Test) ... ok
======================================================================
FAIL: test_compilestring (test.test_pep263.PEP263Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/heimes/dev/python/py3k/Lib/test/test_pep263.py", line 25,
in test_compilestring
AssertionError: '\xc3\xb3' != '\xf3'
----------------------------------------------------------------------
Ran 2 tests in 0.035s
FAILED (failures=1)
test test_pep263 failed -- Traceback (most recent call last):
File "/home/heimes/dev/python/py3k/Lib/test/test_pep263.py", line 25,
in test_compilestring
AssertionError: '\xc3\xb3' != '\xf3'
1 test failed:
test_pep263
----------
components: Interpreter Core, Tests
messages: 61567
nosy: tiran
priority: high
severity: normal
status: open
title: test_pep263 fails
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1913>
__________________________________
From report at bugs.python.org Wed Jan 23 10:23:45 2008
From: report at bugs.python.org (Song Ma)
Date: Wed, 23 Jan 2008 09:23:45 -0000
Subject: [New-bugs-announce] [issue1915] Python 2.5.1 compile failed with
configure option "--enable-unicode=no"
In-Reply-To: <1201080225.38.0.120364938513.issue1915@psf.upfronthosting.co.za>
Message-ID: <1201080225.38.0.120364938513.issue1915@psf.upfronthosting.co.za>
New submission from Song Ma:
In my platform I have to disable Unicode support in Python 2.5.1. The
"configure" file provided a option "--enable-unicode=no" to allow me to
do so. However, If I ran the configure with that option and then make,
the following error showed:
Python/ast.c:3168: undefined reference to `PyUnicode_DecodeRawUnicodeEscape'
Python/ast.c:3170: undefined reference to `PyUnicode_DecodeUnicodeEscape'
collect2: ld returned 1 exit status
make: *** [python] Error 1
Python 2.4.4 can be compiled with this option and works well. Since
"ast.c" was newly introduced in 2.5.1. Maybe we need put MACRO
"Py_USING_UNICODE" in ast.c for function "decode_unicode()". Otherwise
it needs to modify the "configure" file to forbid "--enable-unicode=no".
However in ast.c "decode_utf8()" is using "Py_USING_UNICODE" to make it
"pluggable" for not supporting utf8. Why not do the same thing for
"decode_unicode()"?
----------
components: Build, Unicode
messages: 61573
nosy: songma
severity: urgent
status: open
title: Python 2.5.1 compile failed with configure option "--enable-unicode=no"
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1915>
__________________________________
From report at bugs.python.org Wed Jan 23 11:41:39 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 23 Jan 2008 10:41:39 -0000
Subject: [New-bugs-announce] [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The inspect module has no function isgenerator.
----------
components: Documentation, Library (Lib)
keywords: easy
messages: 61577
nosy: tiran
priority: low
severity: normal
status: open
title: Add inspect.isgenerator
type: rfe
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________
From report at bugs.python.org Wed Jan 23 18:01:39 2008
From: report at bugs.python.org (Graeme Smecher)
Date: Wed, 23 Jan 2008 17:01:39 -0000
Subject: [New-bugs-announce] [issue1917] init_types() in Parser/asdl_c.py
conflicts with init_types() in Modules/_typesmodule.c
In-Reply-To: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za>
Message-ID: <1201107699.6.0.65670529647.issue1917@psf.upfronthosting.co.za>
New submission from Graeme Smecher:
On a BFLT (microblaze-uclinux) build of vanilla Python 2.5.1, "startup
-v" produces the following:
# python -v
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/local/lib/python2.5/site.pyc has bad mtime
import site # from /usr/local/lib/python2.5/site.py
# can't create /usr/local/lib/python2.5/site.pyc
# /usr/local/lib/python2.5/os.pyc has bad mtime
import os # from /usr/local/lib/python2.5/os.py
# can't create /usr/local/lib/python2.5/os.pyc
import posix # builtin
# /usr/local/lib/python2.5/posixpath.pyc has bad mtime
import posixpath # from /usr/local/lib/python2.5/posixpath.py
# can't create /usr/local/lib/python2.5/posixpath.pyc
# /usr/local/lib/python2.5/stat.pyc has bad mtime
import stat # from /usr/local/lib/python2.5/stat.py
# can't create /usr/local/lib/python2.5/stat.pyc
# /usr/local/lib/python2.5/UserDict.pyc has bad mtime
import UserDict # from /usr/local/lib/python2.5/UserDict.py
# can't create /usr/local/lib/python2.5/UserDict.pyc
# /usr/local/lib/python2.5/copy_reg.pyc has bad mtime
import copy_reg # from /usr/local/lib/python2.5/copy_reg.py
# can't create /usr/local/lib/python2.5/copy_reg.pyc
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
'import site' failed; traceback:
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site.py", line 62, in <module>
import os
File "/usr/local/lib/python2.5/os.py", line 696, in <module>
import copy_reg as _copy_reg
File "/usr/local/lib/python2.5/copy_reg.py", line 7, in <module>
from types import ClassType as _ClassType
File "/usr/local/lib/python2.5/types.py", line 93, in <module>
import _types
SystemError: _PyImport_FixupExtension: module _types not loaded
# /usr/local/lib/python2.5/warnings.pyc has bad mtime
import warnings # from /usr/local/lib/python2.5/warnings.py
# can't create /usr/local/lib/python2.5/warnings.pyc
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
import encodings # directory /usr/local/lib/python2.5/encodings
# /usr/local/lib/python2.5/encodings/__init__.pyc has bad mtime
import encodings # from /usr/local/lib/python2.5/encodings/__init__.py
# can't create /usr/local/lib/python2.5/encodings/__init__.pyc
# /usr/local/lib/python2.5/codecs.pyc has bad mtime
import codecs # from /usr/local/lib/python2.5/codecs.py
# can't create /usr/local/lib/python2.5/codecs.pyc
import _codecs # builtin
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
Python 2.5.1 (r251:54863, Jan 23 2008, 09:07:29)
[GCC 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
This is happening because the autogenerated _PyImport_Inittab in
"Modules/config.c" (sensibly) contains the following startup definition:
/* This lives in Python/_types.c */
{"_types", init_types},
The problem is that two distinct init_types() exist, and the
microblaze-uclinux-gcc toolchain is picking up the wrong one.
On x86 GCC producing ELF binaries, the linker picks up the correct
init_types() defined in "Modules/_typesmodule.c". The above behaviour
does not occur, and the interpreter starts up successfully.
On Microblaze GCC producing BFLT binaries, the linker instead picks up
init_types() defined in "Python/Python-ast.c", which is autogenerated
from "Parser/asdl_c.py".
The obvious fix is to change one of the init_types() to something else.
I suspect this bug is related to Issue 1568243, which has been closed
(apparently a different fix was in order for PCs.) The doubly-defined
init_types() appears to still be present in the Subversion repository.
For reference, my cross-compiler is configured as follows:
$ microblaze-uclinux-gcc -v
Reading specs from
/lhome/gsmecher/petalinux-public/tools/linux-i386/microblaze-uclinux-tools/bin/../lib/gcc/microblaze-uclinux/3.4.1/specs
Configured with:
/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/srcs/gcc/configure
--target=microblaze-uclinux
--prefix=/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/microblaze-uclinux-tools
--enable-languages=c,c++ --enable-multilib --enable-target-optspace
--with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99
--disable-clocale --disable-c-mbchar --disable-long-long
--enable-threads=posix --enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE
Thread model: posix
gcc version 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )
----------
components: Build
messages: 61589
nosy: gsmecher
severity: minor
status: open
title: init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1917>
__________________________________
From report at bugs.python.org Wed Jan 23 19:34:16 2008
From: report at bugs.python.org (Jeff Foran)
Date: Wed, 23 Jan 2008 18:34:16 -0000
Subject: [New-bugs-announce] [issue1918] weak references are removed before
__del__ is called.
In-Reply-To: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za>
Message-ID: <1201113256.5.0.101842324307.issue1918@psf.upfronthosting.co.za>
New submission from Jeff Foran:
Not sure where to put example code, but here it goes:
import weakref
class MyObj(object):
def __init__(self):
self.ref = weakref.ref(self)
def __del__(self):
print "HERE123", self.ref()
o = MyObj()
o = None
----------
components: Interpreter Core
messages: 61597
nosy: jforan
severity: normal
status: open
title: weak references are removed before __del__ is called.
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1918>
__________________________________
From report at bugs.python.org Thu Jan 24 12:41:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 24 Jan 2008 11:41:41 -0000
Subject: [New-bugs-announce] [issue1919] Backport of io.py
In-Reply-To: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za>
Message-ID: <1201174901.71.0.122218114057.issue1919@psf.upfronthosting.co.za>
New submission from Christian Heimes:
I've started on a back port of Python 3.0's io.py to Python 2.6. First
results are promising.
cd trunk
svn cp ../py3k/Include/bytes_methods.h Include/
svn cp ../py3k/Objects/bytes_methods.c Objects/
svn cp ../py3k/Lib/io.py Lib/
svn cp ../py3k/Lib/test/test_io.py Lib/test/
svn cp ../py3k/Modules/_fileio.c Modules/
patch -p0 < trunk_io.patch
I'm not sure how to proceed with the missing bytearray type:
* backport bytearray and the new buffer interface from 3.0
* write a replacement for 2.6
* replace the bytearray code with new code
----------
components: Interpreter Core, Library (Lib)
files: trunk_io.patch
messages: 61626
nosy: tiran
priority: normal
severity: normal
status: open
title: Backport of io.py
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9277/trunk_io.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1919>
__________________________________
From report at bugs.python.org Thu Jan 24 14:22:49 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 24 Jan 2008 13:22:49 -0000
Subject: [New-bugs-announce] [issue1920] while else loop seems to behave
incorrectly
In-Reply-To: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za>
Message-ID: <1201180969.36.0.961933968615.issue1920@psf.upfronthosting.co.za>
New submission from Mark Summerfield:
I am using:
Python 3.0a2 (r30a2:59382, Dec 17 2007, 08:47:22)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2
IDLE 3.0a1
This seems wrong:
>>> while False:
print("no")
else:
print("yes")
>>>
I expected it to print "yes" because the docs say that the else suite is
executed if present and if the loop terminated normally (no break), and
this is the case here.
This works though:
>>> x = False
>>> while x:
print("no")
else:
print("yes")
yes
>>>
So it seems that "while False" and "while variable" are giving different
behaviour.
----------
components: Interpreter Core
messages: 61629
nosy: mark
severity: normal
status: open
title: while else loop seems to behave incorrectly
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1920>
__________________________________
From report at bugs.python.org Thu Jan 24 14:35:47 2008
From: report at bugs.python.org (Antti Rasinen)
Date: Thu, 24 Jan 2008 13:35:47 -0000
Subject: [New-bugs-announce] [issue1921] Confusing Descrintro example
In-Reply-To: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za>
Message-ID: <1201181747.66.0.31684496906.issue1921@psf.upfronthosting.co.za>
New submission from Antti Rasinen:
Guido's document "Unifying types and classes in Python 2.2" (descrintro)
contains a confusing example for metaclass newbies.
<http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_examples>
The example in question is autoprop, which uses the variable "name" in
three different contexts. First, it is the name of the class being
created. Second, it is used in a for loop to denote the keys of the
class dict. And thirdly, it is used to denote substrings of a subset of
those keys.
Upon my first encounter with the example, I found myself staring at the
getattr and setattr lines in disbelief. I associated "name" as the
parameter given to the __init__ function.
I'd propose changing the first for-loop name to "member" or similar
and the second to "propname" or "prop".
Furthermore, a modern version of the same example could use sets and set
comprehensions instead of dict.keys():
props = {member[5:] for member in dict if member.startswith...}
----------
components: Documentation
messages: 61631
nosy: arsatiki
severity: minor
status: open
title: Confusing Descrintro example
type: rfe
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1921>
__________________________________
From report at bugs.python.org Thu Jan 24 16:44:01 2008
From: report at bugs.python.org (Stephen Emslie)
Date: Thu, 24 Jan 2008 15:44:01 -0000
Subject: [New-bugs-announce] [issue1923] meaningful whitespace can be lost
in rfc822_escape
In-Reply-To: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
Message-ID: <1201189441.64.0.266619284042.issue1923@psf.upfronthosting.co.za>
New submission from Stephen Emslie:
distutils.util.rfc822_escape strips each line of its whitespace before
indenting, but this can mean losing meaningful whitespace, such as in
reStructuredText.
distutils uses rfc822_escape to escape fields in metadata, such as
PKG-INFO. This unfortunately means that you cant use reStructuredText
formatting in your long description (suggested in PEP345), or are
limited to a set that doesn't require indentation (no block quotes, etc.).
for example:
>>> rest = """
... a literal python block::
... >>> import this
... """
>>> print distutils.util.rfc822_escape(rest)
a literal python block::
>>> import this
I would be expecting this to look something like:
a literal python block::
>>> import this
It looks like this behavior was intentionally added in rev 20099, but
that was about 7 years ago - before reStructuredText and eggs. I
wonder if it makes sense to re-think that implementation with this
sort of metadata in mind, assuming this behavior isn't required to be
rfc822 compliant. I think it would certainly be a shame to miss out on
a good thing like proper (renderable) reST in our metadata.
Is distutils being over-cautious in flattening out all whitespace? A
w3c discussion on multiple lines in rfc822 [1] seems to suggest that
whitespace can be 'unfolded' safely, so it seems a shame to be
throwing it away when it can have important meaning.
http://www.w3.org/Protocols/rfc822/3_Lexical.html
----------
components: Library (Lib)
messages: 61633
nosy: stephenemslie
severity: normal
status: open
title: meaningful whitespace can be lost in rfc822_escape
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1923>
__________________________________
From report at bugs.python.org Thu Jan 24 17:14:50 2008
From: report at bugs.python.org (David Goodger)
Date: Thu, 24 Jan 2008 16:14:50 -0000
Subject: [New-bugs-announce] [issue1924] %i string format breaks for large
floats (incomplete int conversion)
In-Reply-To: <1201191290.86.0.944658382949.issue1924@psf.upfronthosting.co.za>
Message-ID: <1201191290.86.0.944658382949.issue1924@psf.upfronthosting.co.za>
New submission from David Goodger:
I ran across this bug in some legacy production code when numbers got high:
>>> '%i' % 2e9
'2000000000'
>>> '%i' % 3e9
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: int argument required
It looks like the float is being automatically converted to an int, but
floats > sys.maxint cause an error. However,
>>> int(3e9)
3000000000L
So the implicit float-to-int conversion is imperfect; large floats are
not being converted to long ints.
Same error in Python 2.3 through 2.6a0 (as of 2007-12-28).
In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to
convert". The same error is triggered by int(3e9) though.
While it's arguably not-quite-sane to have code that triggers this
error, the inconsistency is what concerns me.
----------
components: Interpreter Core
messages: 61635
nosy: goodger
severity: normal
status: open
title: %i string format breaks for large floats (incomplete int conversion)
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1924>
__________________________________
From report at bugs.python.org Thu Jan 24 18:34:18 2008
From: report at bugs.python.org (Egon Frerich)
Date: Thu, 24 Jan 2008 17:34:18 -0000
Subject: [New-bugs-announce] [issue1925] TypeError in deepcopy
In-Reply-To: <1201196058.93.0.571748952585.issue1925@psf.upfronthosting.co.za>
Message-ID: <1201196058.93.0.571748952585.issue1925@psf.upfronthosting.co.za>
New submission from Egon Frerich:
Traceback (most recent call last):
File "/home/egon/Entwicklung/notes/gui/uicommand.py", line 645, in
doCommand
self.controller.copyItemID()
File "/home/egon/Entwicklung/notes/gui/navicontroller.py", line 306,
in copyItemID
id_copy = self.Sammlung.kopiereEintrag(id)
File "/home/egon/Entwicklung/notes/domain/note.py", line 185, in
kopiereEintrag
EintragKopie = copy.deepcopy(Eintrag)
File "/usr/lib/python2.5/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct
state = deepcopy(state, memo)
File "/usr/lib/python2.5/copy.py", line 162, in deepcopy
y = copier(x, memo)
File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/lib/python2.5/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct
state = deepcopy(state, memo)
File "/usr/lib/python2.5/copy.py", line 162, in deepcopy
y = copier(x, memo)
File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/lib/python2.5/copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/lib/python2.5/copy.py", line 322, in _reconstruct
y = callable(*args)
File "/usr/lib/python2.5/copy_reg.py", line 92, in __newobj__
return cls.__new__(cls, *args)
TypeError: object.__new__(PySwigObject) is not safe, use
PySwigObject.__new__()
----------
components: Library (Lib)
messages: 61641
nosy: efrerich
severity: normal
status: open
title: TypeError in deepcopy
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1925>
__________________________________
From report at bugs.python.org Thu Jan 24 19:41:35 2008
From: report at bugs.python.org (Ray Chason)
Date: Thu, 24 Jan 2008 18:41:35 -0000
Subject: [New-bugs-announce] [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
New submission from Ray Chason:
This patch adds SSL support to nntplib. It is a followup to issue
#1535659 and addresses the objections raised in the comments to that
issue; it also changes the default port to 563 (nntps) rather than 119
if SSL is requested.
----------
components: Library (Lib)
files: python-nntps-patch-1.txt
messages: 61648
nosy: chasonr
severity: normal
status: open
title: NNTPS support in nntplib
type: rfe
versions: Python 2.5
Added file: http://bugs.python.org/file9280/python-nntps-patch-1.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
__________________________________
From report at bugs.python.org Thu Jan 24 21:21:18 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 24 Jan 2008 20:21:18 -0000
Subject: [New-bugs-announce] [issue1927] raw_input behavior incorrect if
readline not enabled
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
New submission from Skip Montanaro:
>From a thread on python-dev...
http://mail.python.org/pipermail/python-dev/2008-January/076446.html
Mike Kent mike.kent at sage.com
Thu Jan 24 16:33:47 CET 2008
Recently I was trying to debug an old python program who's maintenance I
inherited. I was using the quick-and-dirty method of putting some 'print
>>sys.stderr' statements in the code, and then running the command with
'2>filename' appended to the end of the command line. Imagine my surprise
to see that all of the prompt text from the program's raw_input calls were
also disappearing from the screen output, and appearing in the stderr
output routed to the file.
The latest documentation for raw_input states "If the prompt argument is
present, it is written to standard output without a trailing newline."
I posted a question regarding the observed behavior to comp.lang.python
and Gabriel Genellina (thanks Gabriel!) pointed out that despite the
documentation, raw_input was hard-coded to always output its prompt text
to stderr.
This raises two questions:
1. Shouldn't the current documentation be corrected to state that raw_input
writes its prompt to standard error?
2. Is this really the hard-coded behavior we want? I don't think my
use-case is that odd; in fact, what I find very odd is that the prompt
output is send to stderr. I mean, I'm printing the prompt for a question,
not some error message. Can there not at least be an optional parameter to
indicate that you want the output sent to stdout rather than stderr?
... after a few responses ...
Guido van Rossum guido at python.org
Thu Jan 24 21:09:12 CET 2008
On Jan 24, 2008 11:41 AM, Mike Kent <mike.kent at sage.com> wrote:
...
> Interesting point about whether GNU readline is installed. My setup
is RedHat
> Linux, with Python 2.5 that I built and installed myself. GNU
readline is not,
> in fact, installed. If you look at Python2.5/Parser/myreadline.c,
function
> PyOS_StdioReadline, line 125, you will see that prompt output is being
sent to
> stderr. As best as my Python-fu can determine, this is the code used
to output
> a raw_input prompt (thanks again to Gabriel Genellina for pointing me
in the
> right direction.)
>
> It's entirely likely that the difference in what I am seeing and what
you guys
> are seeing is caused by my not having GNU readline installed.
Nevertheless,
> the behavior without it seems wrong, and is certainly different from the
> documentation.
Agreed.
----------
components: Interpreter Core
messages: 61652
nosy: skip.montanaro
severity: normal
status: open
title: raw_input behavior incorrect if readline not enabled
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1927>
__________________________________
From report at bugs.python.org Fri Jan 25 00:46:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Jan 2008 23:46:16 -0000
Subject: [New-bugs-announce] [issue1928] test_urllib fails
In-Reply-To: <1201218376.09.0.323845254483.issue1928@psf.upfronthosting.co.za>
Message-ID: <1201218376.09.0.323845254483.issue1928@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
FAIL: test_read (__main__.urlopen_HttpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_urllib.py", line 130, in test_read
self.assertEqual(fp.getcode(), 200)
AssertionError: None != 200
It works in the trunk though.
Georg, didn't you touch this last, adding the code-getting API in the
trunk? Perhaps it's a merge glitch?
----------
components: Library (Lib)
messages: 61657
nosy: gvanrossum
severity: normal
status: open
title: test_urllib fails
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1928>
__________________________________
From report at bugs.python.org Fri Jan 25 01:03:28 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Fri, 25 Jan 2008 00:03:28 -0000
Subject: [New-bugs-announce] [issue1929] httplib _read_chunked TypeError |||
i = line.find("; ")
In-Reply-To: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za>
Message-ID: <1201219408.32.0.189148181518.issue1929@psf.upfronthosting.co.za>
New submission from Georgij Kondratjev:
(With current python3-svn)
While trying to response.read() got this:
---
File "/usr/lib/python3.0/httplib.py", line 533, in read
return self._read_chunked(amt)
File "/usr/lib/python3.0/httplib.py", line 573, in _read_chunked
i = line.find(";")
TypeError: expected an object with the buffer interface
---
To debug I did this:
---
line = self.fp.readline()
+print(' ***', line)
i = line.find(b";")
---
and got "*** b'2e6d\r\n'" followed by those TypeError exception.
I did this:
---
def _read_chunked(self, amt):
assert self.chunked != _UNKNOWN
chunk_left = self.chunk_left
- value = ""
+ value = b""
if chunk_left is None:
line = self.fp.readline()
- i = line.find(";")
+ i = line.find(b";")
---
And it seems to work.
----------
components: Library (Lib)
messages: 61659
nosy: orivej
severity: normal
status: open
title: httplib _read_chunked TypeError ||| i = line.find(";")
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1929>
__________________________________
From report at bugs.python.org Fri Jan 25 01:10:07 2008
From: report at bugs.python.org (Robert Clark)
Date: Fri, 25 Jan 2008 00:10:07 -0000
Subject: [New-bugs-announce] [issue1930] sys.maxint not found in Python 3.0a2
In-Reply-To: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za>
Message-ID: <1201219807.95.0.419145218607.issue1930@psf.upfronthosting.co.za>
New submission from Robert Clark:
File
"/home/rclark/lib/src/python/pyparsing/pyparsing-1.3.1/pyparsing.py",
line 971, in __init__
self.maxLen = sys.maxint
AttributeError: 'module' object has no attribute 'maxint'
----------
messages: 61661
nosy: rclark
severity: normal
status: open
title: sys.maxint not found in Python 3.0a2
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1930>
__________________________________
From report at bugs.python.org Fri Jan 25 01:11:40 2008
From: report at bugs.python.org (Robert Clark)
Date: Fri, 25 Jan 2008 00:11:40 -0000
Subject: [New-bugs-announce] [issue1931] NameError: global name 'basestring'
is not defined
In-Reply-To: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za>
Message-ID: <1201219900.17.0.974915003457.issue1931@psf.upfronthosting.co.za>
New submission from Robert Clark:
File
"/home/rclark/lib/src/python/pyparsing/pyparsing-1.3.1/pyparsing.py",
line 1511, in __init__
if isinstance( expr, basestring ):
NameError: global name 'basestring' is not defined
----------
messages: 61662
nosy: rclark
severity: normal
status: open
title: NameError: global name 'basestring' is not defined
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1931>
__________________________________
From report at bugs.python.org Fri Jan 25 04:15:14 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 25 Jan 2008 03:15:14 -0000
Subject: [New-bugs-announce] [issue1932] Cosmetic patch to supress compiler
warning
In-Reply-To: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za>
Message-ID: <1201230914.81.0.163994833625.issue1932@psf.upfronthosting.co.za>
New submission from Hirokazu Yamamoto:
This is not compile error, but I cannot find more proper tag than this.
----------
components: Build
files: const.patch
messages: 61669
nosy: ocean-city
severity: minor
status: open
title: Cosmetic patch to supress compiler warning
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file9282/const.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1932>
__________________________________
From report at bugs.python.org Fri Jan 25 22:54:11 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Jan 2008 21:54:11 -0000
Subject: [New-bugs-announce] [issue1933] os.path.isabs documentation error
In-Reply-To: <1201298051.95.0.975455145636.issue1933@psf.upfronthosting.co.za>
Message-ID: <1201298051.95.0.975455145636.issue1933@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
The current os.path.isabs documentation says:
> isabs(path)
> Return True if path is an absolute pathname (begins with a slash).
The "begins with a slash" part is incorrect since certain systems use a
different pathname notation.
For example, on Macintosh (where os.sep == ":") this is an absolute
pathname:
hardDriveName:folderName1:folderName2:fileName.ext
...and this is a relative one:
:folderName1:fileName.ext
Moreover, on Windows os.path.isabs('\\') returns True since '\\' is an
alias for the current drive letter (e.g. C:\\) hence, independently from
what said before, the documentation should include also the "backslash"
term.
I think it would be better removing the "(begins with a slash)" part at all.
----------
components: Documentation
messages: 61691
nosy: giampaolo.rodola
severity: normal
status: open
title: os.path.isabs documentation error
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1933>
__________________________________
From report at bugs.python.org Fri Jan 25 22:55:53 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Jan 2008 21:55:53 -0000
Subject: [New-bugs-announce] [issue1934] os.path.isabs documentation error
In-Reply-To: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za>
Message-ID: <1201298153.58.0.265967010684.issue1934@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
The current os.path.isabs documentation says:
> isabs(path)
> Return True if path is an absolute pathname (begins with a slash).
The "begins with a slash" part is incorrect since certain systems use a
different pathname notation.
For example, on Macintosh (where os.sep == ":") this is an absolute
pathname:
hardDriveName:folderName1:folderName2:fileName.ext
...and this is a relative one:
:folderName1:fileName.ext
Moreover, on Windows os.path.isabs('\\') returns True since '\\' is an
alias for the current drive letter (e.g. C:\\) hence, independently from
what said before, the documentation should include also the "backslash"
term.
I think it would be better removing the "(begins with a slash)" part at all.
----------
components: Documentation
messages: 61692
nosy: giampaolo.rodola
severity: normal
status: open
title: os.path.isabs documentation error
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1934>
__________________________________
From report at bugs.python.org Sat Jan 26 00:28:16 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Jan 2008 23:28:16 -0000
Subject: [New-bugs-announce] [issue1935] test_descr.py converted to unittest
In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za>
Message-ID: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
This is test_descr.py converted to unittest. The diff is so large that
svn diff failed!
"svn: Can't write to stream: Not enough space to process this command."
Anyway, I started from trunk, rev 60301.
The file is very large, and some functions have more than 400 lines. I
tried to group them into classes, most of the time respecting the
initial sequential order, but not always.
The class and function names may seem arbitrary sometimes. At least, I
hope that no test was lost in the process. Feel free to reorganize stuff
if you find a logic in all these tests.
I removed all print statements, and converted some statements to
unittest idioms, but not all: lots of "raise TestFailed" remain.
svn merge into py3k will be difficult; I propose to upload a py3k
version of this file, which I will make by merging differences between
trunk and py3k into this new file.
----------
components: Tests
files: test_descr.py
keywords: patch
messages: 61696
nosy: amaury.forgeotdarc
severity: normal
status: open
title: test_descr.py converted to unittest
versions: Python 2.6
Added file: http://bugs.python.org/file9289/test_descr.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1935>
__________________________________
From report at bugs.python.org Sat Jan 26 03:18:58 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Jan 2008 02:18:58 -0000
Subject: [New-bugs-announce] [issue1938] test_zipfile failure
In-Reply-To: <1201313938.37.0.0332747788012.issue1938@psf.upfronthosting.co.za>
Message-ID: <1201313938.37.0.0332747788012.issue1938@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
Python 2.6.13903.msi, windows XP sp2:
======================================================================
ERROR: testExtract (__main__.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Python26\Lib\test\test_zipfile.py", line 357, in tearDown
os.remove(TESTFN2)
WindowsError: [Error 32] The file used by another process: '@test2'
======================================================================
FAIL: testExtract (__main__.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Python26\Lib\test\test_zipfile.py", line 320, in testExtract
self.assertEqual(writtenfile, correctfile)
AssertionError: 'C:\\Python26\\Lib\\test\\ziptest2dir\\_ziptest2' !=
'C:\\Python
26\\Lib\\test\\ziptest2dir/_ziptest2'
----------------------------------------------------------------------
----------
files: test_zipfile.diff
messages: 61698
nosy: giampaolo.rodola
severity: normal
status: open
title: test_zipfile failure
versions: Python 2.6
Added file: http://bugs.python.org/file9292/test_zipfile.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1938>
__________________________________
From report at bugs.python.org Sat Jan 26 07:12:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Jan 2008 06:12:22 -0000
Subject: [New-bugs-announce] [issue1939] code object docstring obsolete
In-Reply-To: <1201327942.59.0.0823871003306.issue1939@psf.upfronthosting.co.za>
Message-ID: <1201327942.59.0.0823871003306.issue1939@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
The docstring for the code object mentions an obsolete signature which
misses the `kwonlyargcount` parameter. Here is a patch.
----------
components: Interpreter Core
files: codedoc.patch
messages: 61699
nosy: pitrou
severity: minor
status: open
title: code object docstring obsolete
versions: Python 3.0
Added file: http://bugs.python.org/file9293/codedoc.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1939>
__________________________________
From report at bugs.python.org Sat Jan 26 13:57:46 2008
From: report at bugs.python.org (Robin Bryce)
Date: Sat, 26 Jan 2008 12:57:46 -0000
Subject: [New-bugs-announce] [issue1940] curses.filter can not be used as
described in its documentation
In-Reply-To: <1201352266.5.0.670433987116.issue1940@psf.upfronthosting.co.za>
Message-ID: <1201352266.5.0.670433987116.issue1940@psf.upfronthosting.co.za>
New submission from Robin Bryce:
curses.filter forces the top most window to 1 line tall and preserves
existing tty content. It must be called *before* curses.initscr in order
to acheive this.
The python documentation states that curses.filter must be called before
initscr but the implementation prevents this. It uses the
NoArgNoReturnVoidFunction macro defined in Include/py_curses.h. This
macro in turn invokes the PyCursesInitialised macro which forces an
error if initscr has not been called.
curses.filter needs an explicit definition to avoid this:
Replacing "NoArgNoReturnVoidFunction(filter)" in Modules/_cursesmodule.c
with
static PyObject *PyCurses_filter (PyObject *self)
{
/* MUST NOT BE PyCursesInitialised */
filter(); \
Py_INCREF(Py_None);
return Py_None;
}
Would allow curses.filter to be called as documented. But really should
get a check for "!PyCursesInitialised".
----------
components: Documentation, Library (Lib)
messages: 61708
nosy: robinbryce
severity: normal
status: open
title: curses.filter can not be used as described in its documentation
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1940>
__________________________________
From report at bugs.python.org Sat Jan 26 20:21:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Jan 2008 19:21:29 -0000
Subject: [New-bugs-announce] [issue1941] 2.6 stdlib using with statement
In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za>
Message-ID: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za>
New submission from Benjamin Peterson:
This patch modernizes many modules in the stdlib by making them using
the with statement. They affected modules are modulefinder, ftplib,
cookielib, shutil, pydoc, platform, _LWPCookieJar, mailbox,
_MozillaCookieJar, and zipfile.
----------
components: Library (Lib)
files: stdlib-with-stmt.diff
messages: 61713
nosy: gutworth
severity: normal
status: open
title: 2.6 stdlib using with statement
versions: Python 2.6
Added file: http://bugs.python.org/file9294/stdlib-with-stmt.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1941>
__________________________________
From report at bugs.python.org Sat Jan 26 22:57:44 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Jan 2008 21:57:44 -0000
Subject: [New-bugs-announce] [issue1942] test_plistlib started failing
In-Reply-To: <1201384664.2.0.634554837169.issue1942@psf.upfronthosting.co.za>
Message-ID: <1201384664.2.0.634554837169.issue1942@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Probably a merge glitch.
----------
components: Macintosh
messages: 61724
nosy: gvanrossum
priority: urgent
severity: normal
status: open
title: test_plistlib started failing
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1942>
__________________________________
From report at bugs.python.org Sat Jan 26 23:44:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Jan 2008 22:44:35 -0000
Subject: [New-bugs-announce] [issue1943] improved allocation of PyUnicode
objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
This is an attempt at improving allocation of str (PyUnicode) objects.
For that it does two things:
1. make str objects PyVarObjects, so that the object is allocated in one
pass rather than two
2. maintain an array of freelists, each for a given str length, so that
many str allocations can bypass actual memory allocation calls
There is a ~10% speedup in stringbench, and a slight improvement in
pybench (as invoked with "./python Tools/pybench/pybench.py -t String").
Also, memory consumption is a bit lower when running those benchmarks.
----------
components: Interpreter Core
files: unialloc.patch
messages: 61728
nosy: pitrou
severity: normal
status: open
title: improved allocation of PyUnicode objects
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file9296/unialloc.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
__________________________________
From report at bugs.python.org Sun Jan 27 07:26:43 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Jan 2008 06:26:43 -0000
Subject: [New-bugs-announce] [issue1944] Documentation for
PyUnicode_AsString (et al.) missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti:
I was wandering whether the pointer returned by PyUnicode_AsString needs
to be freed after usage (It turned it doesn't since the result is
cached). However, I found out that there isn't any documentation on
docs.python.org about the PyUnicode_AsString and
PyUnicode_AsStringAndSize functions. Although, both are documented in
the public unicodeobject.h header.
I notice that the documentation for several other unicode functions is
missing. Quickly, I see:
PyUnicode_Resize
PyUnicode_InternImmortal
PyUnicode_GetDefaultEncoding
PyUnicode_SetDefaultEncoding
PyUnicode_BuildEncodingMap
PyUnicode_FromFormatV
PyUnicode_*UTF7*
PyUnicode_AsEncodedObject
PyUnicode_FromOrdinal
PyUnicode_DecodeFSDefault
PyUnicode_DecodeFSDefaultAndSize
It would probably be a good idea to polish up the documentation for
PyUnicode as much as possible for Python 3000, since extension
developers will certainly need to refer to it a lot during the
transition from 2.x.
----------
components: Documentation
keywords: easy
messages: 61734
nosy: alexandre.vassalotti
severity: normal
status: open
title: Documentation for PyUnicode_AsString (et al.) missing.
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1944>
__________________________________
From report at bugs.python.org Sun Jan 27 15:57:38 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 27 Jan 2008 14:57:38 -0000
Subject: [New-bugs-announce] [issue1945] Document back ported C functions
In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za>
Message-ID: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Document the C functions which were back ported from py3k in r60283.
----------
components: Documentation
keywords: easy
messages: 61736
nosy: tiran
priority: normal
severity: normal
status: open
title: Document back ported C functions
type: rfe
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1945>
__________________________________
From report at bugs.python.org Sun Jan 27 16:59:04 2008
From: report at bugs.python.org (Israel Tsadok)
Date: Sun, 27 Jan 2008 15:59:04 -0000
Subject: [New-bugs-announce] [issue1946] re.search hangs on this
In-Reply-To: <1201449544.57.0.177227713029.issue1946@psf.upfronthosting.co.za>
Message-ID: <1201449544.57.0.177227713029.issue1946@psf.upfronthosting.co.za>
New submission from Israel Tsadok:
import re
re.search(r'a(b[^b]*b|[^c])*cxxx',
'abbcacabbbbcabbbbbbcabbbbbbbbbbbbbbcacabbbbbbbbbbbbbbcabbbbcac')
perl seems to handle this just fine.
(The original problem was trying to translate some html to text:
re.sub(r'<p(?:"[^"]*"|[^>])*>(.*?)</p>', r'\1\n')
This hanged on several files. Changing [^>] to [^">] resolved my
problem, but the general case remains.)
This might be a dupe of http://bugs.python.org/issue1297193
----------
components: Regular Expressions
messages: 61739
nosy: itsadok
severity: normal
status: open
title: re.search hangs on this
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1946>
__________________________________
From report at bugs.python.org Sun Jan 27 18:37:15 2008
From: report at bugs.python.org (shore.cloud)
Date: Sun, 27 Jan 2008 17:37:15 -0000
Subject: [New-bugs-announce] [issue1947] Exception exceptions.AttributeError
'_shutdown' in <module 'threading'
In-Reply-To: <1201455435.45.0.790953321864.issue1947@psf.upfronthosting.co.za>
Message-ID: <1201455435.45.0.790953321864.issue1947@psf.upfronthosting.co.za>
New submission from shore.cloud:
Exception exceptions.AttributeError: '_shutdown' in
<module 'threading' from 'F:
\Python25\lib\threading.pyc'> ignored
----------
files: thread1.py
messages: 61742
nosy: Mr Shore
severity: normal
status: open
title: Exception exceptions.AttributeError '_shutdown' in <module 'threading'
Added file: http://bugs.python.org/file9299/thread1.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1947>
__________________________________
From report at bugs.python.org Sun Jan 27 20:38:59 2008
From: report at bugs.python.org (safe alattar)
Date: Sun, 27 Jan 2008 19:38:59 -0000
Subject: [New-bugs-announce] [issue1948] Cant open python gui using VISTA
In-Reply-To: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za>
Message-ID: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za>
New submission from safe alattar:
I need help opening the python gui (IDLE). On XP I had no issues. On
Vista nothing occurs when I try to open IDLE. If there is a solution to
this, please let me know in a user friendly manner (Im new to this!) Thanks.
----------
messages: 61749
nosy: needhelpasap
severity: normal
status: open
title: Cant open python gui using VISTA
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1948>
__________________________________
From report at bugs.python.org Sun Jan 27 23:19:46 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 27 Jan 2008 22:19:46 -0000
Subject: [New-bugs-announce] [issue1949] test_ntpath.py rewriting
In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za>
Message-ID: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
Since I noticed that test_ntpath.py (unlike test_genericpath.py,
test_macpath.py and test_posixpath.py) does NOT use unittest for doing
tests I tried to rewrite it.
The patch in attachment does that leaving the original tests unchanged.
Tested successfully by having used python 2.6 (current trunk) on Windows
XP and Linux Ubuntu.
----------
components: Tests
files: test_ntpath.diff
messages: 61750
nosy: giampaolo.rodola
severity: normal
status: open
title: test_ntpath.py rewriting
versions: Python 2.6
Added file: http://bugs.python.org/file9301/test_ntpath.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1949>
__________________________________
From report at bugs.python.org Sun Jan 27 23:44:55 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Jan 2008 22:44:55 -0000
Subject: [New-bugs-announce] [issue1950] Potential Overflow due to incorrect
usage of PyUnicode_AsString.
In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
Message-ID: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
New submission from Alexandre Vassalotti:
I have found a few instances of the following pattern in Py3k:
char buf[MAX];
len = PyUnicode_GET_SIZE(str);
if (len >= MAX)
/* return error */
strcpy(buf, PyUnicode_AsString(str));
which could overflow if str contains non-ASCII characters. These were
probably introduced during the PyString -> PyUnicode transition. Anyway,
I got a patch that fixes (hopefully) most of these bugs.
----------
assignee: alexandre.vassalotti
components: Interpreter Core
files: unicode_string_overflow.patch
keywords: patch
messages: 61753
nosy: alexandre.vassalotti
priority: normal
severity: normal
status: open
title: Potential Overflow due to incorrect usage of PyUnicode_AsString.
type: security
versions: Python 3.0
Added file: http://bugs.python.org/file9303/unicode_string_overflow.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1950>
__________________________________
From report at bugs.python.org Mon Jan 28 01:03:39 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Jan 2008 00:03:39 -0000
Subject: [New-bugs-announce] [issue1951] test_wave.py converted to unittest
In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za>
Message-ID: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
In attachment.
----------
components: Tests
files: test_wave.diff
messages: 61754
nosy: giampaolo.rodola
severity: minor
status: open
title: test_wave.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9304/test_wave.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1951>
__________________________________
From report at bugs.python.org Mon Jan 28 02:21:20 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Jan 2008 01:21:20 -0000
Subject: [New-bugs-announce] [issue1952] test_select.py converted to unittest
In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za>
Message-ID: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
In attachment.
----------
components: Tests
files: test_select.diff
messages: 61756
nosy: giampaolo.rodola
severity: minor
status: open
title: test_select.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9305/test_select.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1952>
__________________________________
From report at bugs.python.org Mon Jan 28 04:34:29 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 28 Jan 2008 03:34:29 -0000
Subject: [New-bugs-announce] [issue1953] gc.compact_freelists
In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
Message-ID: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch implements gc.compact_freelists() which calls PyInt and
PyFloat_CompactFreeList(). I've moved the code from the _Fini methods to
the _CompactFreeList() methods.
The patch also moves the clear type cache function to gc.clear_type_cache().
----------
assignee: nnorwitz
components: Extension Modules, Interpreter Core
files: trunk_compact_freelist.patch
keywords: patch
messages: 61771
nosy: nnorwitz, tiran
priority: normal
severity: normal
status: open
title: gc.compact_freelists
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9308/trunk_compact_freelist.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1953>
__________________________________
From report at bugs.python.org Mon Jan 28 06:51:19 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 28 Jan 2008 05:51:19 -0000
Subject: [New-bugs-announce] [issue1954] SocketServer.ForkingMixIn creates a
zombie
In-Reply-To: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za>
Message-ID: <1201499479.46.0.649764617185.issue1954@psf.upfronthosting.co.za>
New submission from Ralf Schmitt:
collect_children is only called in process_request, so at least the last
process forked is not collected. This could be handled by calling
collect_children every X seconds or by handling SIGCHLD.
----------
messages: 61773
nosy: schmir
severity: normal
status: open
title: SocketServer.ForkingMixIn creates a zombie
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1954>
__________________________________
From report at bugs.python.org Mon Jan 28 15:39:39 2008
From: report at bugs.python.org (Adam Goucher)
Date: Mon, 28 Jan 2008 14:39:39 -0000
Subject: [New-bugs-announce] [issue1955] fix using unittest as a superclass
In-Reply-To: <1201531179.73.0.502077509605.issue1955@psf.upfronthosting.co.za>
Message-ID: <1201531179.73.0.502077509605.issue1955@psf.upfronthosting.co.za>
New submission from Adam Goucher:
There are a couple places in unittest where 'issubclass(something,
TestCase)' is used. This prevents you from organizing your test code via
class hierarchies. To solve this problem, issubclass should be looking
whether the object is a subclass of unittest.TestCase to walk the
inheritance tree all the way up and not just a single level.
Currently, this will not work.
module A..
class A(unittest.TestCase):
pass
module B...
import A
class B(A.A)
def testFoo(self):
print "blah blah blah
I have attached a patch which will address all locations where this
could happen.
----------
components: Library (Lib)
files: cpython-unittest-subclass.diff
messages: 61776
nosy: agoucher
severity: normal
status: open
title: fix using unittest as a superclass
versions: Python 2.5
Added file: http://bugs.python.org/file9311/cpython-unittest-subclass.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1955>
__________________________________
From report at bugs.python.org Mon Jan 28 15:40:58 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Mon, 28 Jan 2008 14:40:58 -0000
Subject: [New-bugs-announce] [issue1956] Lib/bsddb/test/test_thread.py uses
old 'except' syntax
In-Reply-To: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za>
Message-ID: <1201531258.39.0.0196498727995.issue1956@psf.upfronthosting.co.za>
New submission from Georgij Kondratjev:
"except OSError, e:"
(appears twice) should be changed to
"except OSError as e:"
----------
components: Library (Lib)
messages: 61777
nosy: orivej
severity: normal
status: open
title: Lib/bsddb/test/test_thread.py uses old 'except' syntax
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1956>
__________________________________
From report at bugs.python.org Mon Jan 28 16:31:54 2008
From: report at bugs.python.org (Dennis Jensen)
Date: Mon, 28 Jan 2008 15:31:54 -0000
Subject: [New-bugs-announce] [issue1957] [patch] syslogmodule: Release GIL
when calling syslog(3)
In-Reply-To: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za>
Message-ID: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za>
New submission from Dennis Jensen:
The glibc syslog(3) call will block in some cases; the attached patch
releases the GIL around the syslog call.
----------
components: Extension Modules, Interpreter Core
files: syslogmodule-patch.txt
messages: 61781
nosy: rd2
severity: minor
status: open
title: [patch] syslogmodule: Release GIL when calling syslog(3)
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9312/syslogmodule-patch.txt
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1957>
__________________________________
From report at bugs.python.org Mon Jan 28 22:51:15 2008
From: report at bugs.python.org (Douglas Mayle)
Date: Mon, 28 Jan 2008 21:51:15 -0000
Subject: [New-bugs-announce] [issue1958] IPv6 compiled getaddrinfo returns
IPv6 address even if the system does not support IPv6
In-Reply-To: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za>
Message-ID: <1201557075.89.0.233826065538.issue1958@psf.upfronthosting.co.za>
New submission from Douglas Mayle:
The following code calls getadddrinfo and returns invalid addresses
(IPv6 addresses) when Python has been compiled with IPv6 support and the
system kernel does not support IPv6.
import socket
for res in socket.getaddrinfo("localhost", "80", 0, socket.SOCK_STREAM):
print "%r" % (res,)
(2, 1, 6, '', ('127.0.0.1', 80))
(10, 1, 6, '', ('::1', 80, 0, 0))
----------
components: Library (Lib)
messages: 61799
nosy: douglas
severity: normal
status: open
title: IPv6 compiled getaddrinfo returns IPv6 address even if the system does not support IPv6
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1958>
__________________________________
From report at bugs.python.org Mon Jan 28 23:02:34 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Jan 2008 22:02:34 -0000
Subject: [New-bugs-announce] [issue1959] test_contains.py converted to
unittest
In-Reply-To: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za>
Message-ID: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
In attachment. All existent tests are unchanged.
----------
components: Tests
files: test_contains.diff
messages: 61803
nosy: giampaolo.rodola
severity: normal
status: open
title: test_contains.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9313/test_contains.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1959>
__________________________________
From report at bugs.python.org Tue Jan 29 00:31:01 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Jan 2008 23:31:01 -0000
Subject: [New-bugs-announce] [issue1960] test_gdbm.py converted to unittest
In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za>
Message-ID: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za>
New submission from Giampaolo Rodola':
In attachment. All existent tests are unchanged.
----------
components: Tests
files: test_gdbm.diff
messages: 61806
nosy: giampaolo.rodola
severity: normal
status: open
title: test_gdbm.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9315/test_gdbm.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1960>
__________________________________
From report at bugs.python.org Tue Jan 29 04:06:45 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Jan 2008 03:06:45 -0000
Subject: [New-bugs-announce] [issue1961] possible error with json format for
sphinx
In-Reply-To: <1201576005.17.0.220280417702.issue1961@psf.upfronthosting.co.za>
Message-ID: <1201576005.17.0.220280417702.issue1961@psf.upfronthosting.co.za>
New submission from Brett Cannon:
I currently can't build the docs (r60374):
...
File
"/Users/brett/Dev/python/2.x/pristine/Doc/tools/sphinx/search.py", line
70, in load
for (k, v) in frozen[2].iteritems())
AttributeError: 'list' object has no attribute 'iteritems'
make: *** [build] Error 1
Seems to be related to the json stuff based on the full traceback.
----------
components: Documentation tools (Sphinx)
messages: 61812
nosy: brett.cannon
priority: high
severity: normal
status: open
title: possible error with json format for sphinx
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1961>
__________________________________
From report at bugs.python.org Tue Jan 29 09:59:42 2008
From: report at bugs.python.org (mattbaas)
Date: Tue, 29 Jan 2008 08:59:42 -0000
Subject: [New-bugs-announce] [issue1962] ctypes feature request: Automatic
type conversion of input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
New submission from mattbaas:
This is rather a feature request instead of a bug report.
Below is the mail I posted to the ctypes-users mailing list. In short:
When ctypes checks input argument types using the "argtypes" attribute,
it would be useful if it would try to convert the input value
automatically if it isn't already an appropriate ctypes type (but a
"compatible" Python type).
Here is the full mail with some examples:
I'm wrapping a couple of C functions from a DLL and I'm using the
argtypes attribute to declare the types of the input arguments. I can
call the functions just fine, but I was wondering why I have to provide
the exact ctypes type as input when using more complex types such as
arrays or callbacks (whereas Python floats are automatically converted).
Here is an example code snippet (I was using Python 2.5 on WinXP). The
library ri.dll contains the functions RiColor() which takes an array of
3 floats as input and a function RiErrorHandler() which takes a pointer
to a function as input:
# Create the required types...
RtColor = 3*c_float
RtErrorHandler = CFUNCTYPE(None, c_int, c_int, c_char_p)
# Load the library and declare the input arguments...
ri = cdll.LoadLibrary("ri.dll")
ri.RiColor.argtypes = [RtColor]
ri.RiErrorHandler.argtypes = [RtErrorHandler]
Now I can call the color function like this:
ri.RiColor(RtColor(1,0,0))
But sometimes it would be more convenient to work with other types like
tuples, lists or, in this case, a special vector type (that may come
from another module but that behaves like a list of 3 floats).
But when I try to pass in just a Python tuple or list I get the
following errors:
ri.RiColor((1,0,0))
--> ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>:
Don't know how to convert parameter 1
ri.RiColor([1,0,0])
--> ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>:
expected c_float_Array_3 instance instead of list
Similarly with the error handler function. I have to wrap a Python
function with the RtErrorHandler type, otherwise ctypes won't accept it:
def errHandler(code, severity, message):
pass
ri.RiErrorHandler(RtErrorHandler(errHandler)) # works
ri.RiErrorHandler(errHandler) # produces a TypeError
So whenever an input type doesn't match what was specified in argtypes,
couldn't ctypes try to convert the value before issuing an error? (it
works with floats, so why not with other types as well?)
The conversion could just be done by passing the value to the
constructor of the required type. In the color example this also means
that array types should also accept sequences as input (i.e. anything
that supports iteration and has the right number of elements).
I think this modification to ctypes would make the wrapped functions
more flexible without having to write additional wrapper functions in
Python.
----------
components: Extension Modules
messages: 61815
nosy: mattbaas
severity: normal
status: open
title: ctypes feature request: Automatic type conversion of input arguments to C functions
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
__________________________________
From report at bugs.python.org Tue Jan 29 13:14:47 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 29 Jan 2008 12:14:47 -0000
Subject: [New-bugs-announce] [issue1963] marshal module is leaking references
In-Reply-To: <1201608887.67.0.254774790303.issue1963@psf.upfronthosting.co.za>
Message-ID: <1201608887.67.0.254774790303.issue1963@psf.upfronthosting.co.za>
New submission from Christian Heimes:
Hello Raymond!
Your changes have introduced a ref leak:
test_marshal leaked [32, 32, 32, 32] references, sum=128
----------
assignee: rhettinger
messages: 61818
nosy: rhettinger, tiran
priority: high
severity: normal
status: open
title: marshal module is leaking references
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1963>
__________________________________
From report at bugs.python.org Tue Jan 29 17:15:53 2008
From: report at bugs.python.org (Tim Golden)
Date: Tue, 29 Jan 2008 16:15:53 -0000
Subject: [New-bugs-announce] [issue1964] Slight adjustment to sphinx
print-media stylesheet
In-Reply-To: <1201623353.06.0.378481748773.issue1964@psf.upfronthosting.co.za>
Message-ID: <1201623353.06.0.378481748773.issue1964@psf.upfronthosting.co.za>
New submission from Tim Golden:
My previous patch to the print stylesheet used by Sphinx was a little
overenthusiastic and resulted in the right edge of the text truncating
on some printers. This version reverts a part of that and gives a useful
result on the printers I've tried.
Patch attached against r60407 of Sphinx
----------
components: Documentation tools (Sphinx)
files: sphinx-r60407.patch
messages: 61821
nosy: tim.golden
severity: minor
status: open
title: Slight adjustment to sphinx print-media stylesheet
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9317/sphinx-r60407.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1964>
__________________________________
From report at bugs.python.org Tue Jan 29 19:26:47 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Jan 2008 18:26:47 -0000
Subject: [New-bugs-announce] [issue1965] Move trunc() to math module
In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
Message-ID: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
http://mail.python.org/pipermail/python-dev/2008-January/076626.html
Also, the docstring doesn't seem correct or clear.
----------
assignee: jyasskin
components: Extension Modules
messages: 61823
nosy: jyasskin, rhettinger
severity: normal
status: open
title: Move trunc() to math module
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1965>
__________________________________
From report at bugs.python.org Tue Jan 29 20:14:09 2008
From: report at bugs.python.org (Mike Klaas)
Date: Tue, 29 Jan 2008 19:14:09 -0000
Subject: [New-bugs-announce] [issue1966] infinite loop in httplib
In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za>
Message-ID: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za>
New submission from Mike Klaas:
There are a small number of sites that do not send the trailing \r\n when
using chunked transfer encoding (say 1 in 500,000). This unfortunately,
causes httplib to go into an infinite loop.
Fixed by checking for EOF (3 line patch)
----------
components: Library (Lib)
files: httplib_chunked.patch
messages: 61824
nosy: klaas
severity: major
status: open
title: infinite loop in httplib
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9318/httplib_chunked.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1966>
__________________________________
From report at bugs.python.org Tue Jan 29 23:39:05 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 29 Jan 2008 22:39:05 -0000
Subject: [New-bugs-announce] [issue1967] Backport dictviews to 2.6
In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
Message-ID: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za>
New submission from Thomas Wouters:
Patch to backport dictviews to trunk. Consists of some trickery:
- new 'viewkeys', 'viewvalues' and 'viewitems' methods of dicts,
returning exactly what 'keys', 'values' and 'items' return in 3.0: three
new types defined in dictobject.c
- a future import (dictviews) that changes which opcodes are generated
for (some) attribute access
- special opcodes for getting and setting 'keys', 'values' and 'items'
attributes from an object. These opcodes do nothing special unless a
future import is in effect in the calling code block *and* the type they
are called on is a dict subclass, in which case they translate 'keys',
'values' and 'items' to 'viewkeys', 'viewvalues' and 'viewitems'.
- similar specialcasing in getattr() and setattr()
----------
components: Interpreter Core
files: dictviews_backport.diff
keywords: patch
messages: 61834
nosy: twouters
severity: normal
status: open
title: Backport dictviews to 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file9320/dictviews_backport.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1967>
__________________________________
From report at bugs.python.org Tue Jan 29 23:55:50 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Jan 2008 22:55:50 -0000
Subject: [New-bugs-announce] [issue1968] Unused number magic methods leaked
into Py2.6
In-Reply-To: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za>
Message-ID: <1201647350.7.0.0255165658093.issue1968@psf.upfronthosting.co.za>
New submission from Raymond Hettinger:
The Py2.6 code has __round__, __ceil__, and __floor__ methods still in
several objects (int, longs, float, Rational) but they are not invoked
by anything. For example, round(Rational(22,7)) does not use the
Rational.__round__ code and round(22) does not use the code for
int.__round__; the code is just ignored. Since the code is not used, it
probably shouldn't be in Py2.6.
I think these backports happened before Guido decided, "I think the
pre-3.0 rule should be: round(), math.floor(), math.ceil()
*always* return a float." Probably, rev 59731 may have intended to
revert these changes but just missed them. IIRC, the decision was that
only __trunc__ would be backported and the other three magic methods
would wait for Py3.0 where their invocation functions would get their
new signature and start calling the magic methods.
----------
assignee: jyasskin
messages: 61835
nosy: jyasskin, rhettinger
severity: normal
status: open
title: Unused number magic methods leaked into Py2.6
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1968>
__________________________________
From report at bugs.python.org Wed Jan 30 00:53:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jan 2008 23:53:35 -0000
Subject: [New-bugs-announce] [issue1969] split and rsplit in bytearray are
inconsistent
In-Reply-To: <1201650815.76.0.106888653852.issue1969@psf.upfronthosting.co.za>
Message-ID: <1201650815.76.0.106888653852.issue1969@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
In the bytearray type, the split and rsplit methods use a different
definition of what is a whitespace character. split_whitespace calls
ISSPACE(), while rsplit_whitespace calls Py_UNICODE_ISSPACE(). The
latter is probably an error since it is also inconsistent with behaviour
of the bytes type:
>>> s = b"\x09\x0A\x0B\x0C\x0D\x1C\x1D\x1E\x1F"
>>> s.split()
[b'\x1c\x1d\x1e\x1f']
>>> s.rsplit()
[b'\x1c\x1d\x1e\x1f']
>>> b = bytearray(s)
>>> b.split()
[bytearray(b'\x1c\x1d\x1e\x1f')]
>>> b.rsplit()
[]
----------
components: Interpreter Core
messages: 61836
nosy: pitrou
severity: normal
status: open
title: split and rsplit in bytearray are inconsistent
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1969>
__________________________________
From report at bugs.python.org Wed Jan 30 01:44:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jan 2008 00:44:35 -0000
Subject: [New-bugs-announce] [issue1970] Speedup unicode whitespace and
linebreak detection
In-Reply-To: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za>
Message-ID: <1201653875.04.0.391438542079.issue1970@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
Currently the PyUnicode type uses a function call and several lookups
per character to detect whitespace and linebreaks. This slows down
considerably the split(), rsplit() and splitlines() methods. Since the
overwhelming majority of whitespace and linebreaks are ASCII characters,
it makes sense to have a fast lookup table for the common case. Patch
attached (also with another tiny change which helps compiler
optimization of split/rsplit here).
(this may also help other methods like strip() a bit, but in that case
the impact of whitespace detection is probably negligible)
Some numbers:
# With patch
$ ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.splitlines()"
10000 loops, best of 3: 127 usec per loop
$ ./python -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()"
1000 loops, best of 3: 457 usec per loop
# Without patch
$ ./python-orig -m timeit -s "s=open('LICENSE', 'r').read()"
"s.splitlines()"
10000 loops, best of 3: 175 usec per loop
$ ./python-orig -m timeit -s "s=open('LICENSE', 'r').read()" "s.split()"
1000 loops, best of 3: 571 usec per loop
----------
components: Interpreter Core
files: unispace.patch
messages: 61837
nosy: pitrou
severity: normal
status: open
title: Speedup unicode whitespace and linebreak detection
versions: Python 3.0
Added file: http://bugs.python.org/file9321/unispace.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1970>
__________________________________
From report at bugs.python.org Wed Jan 30 09:15:53 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 30 Jan 2008 08:15:53 -0000
Subject: [New-bugs-announce] [issue1971] ctypes exposing the pep 3118 buffer
interface
In-Reply-To: <1201680953.7.0.68287385548.issue1971@psf.upfronthosting.co.za>
Message-ID: <1201680953.7.0.68287385548.issue1971@psf.upfronthosting.co.za>
New submission from Thomas Heller:
The attached patch against py3k makes ctypes expose the pep 3118 buffer
interface.
The code is also available in the py3k-ctypes-pep3118 branch.
----------
components: Extension Modules
files: ctypes-pep3118.patch
keywords: patch
messages: 61844
nosy: theller
priority: urgent
severity: normal
status: open
title: ctypes exposing the pep 3118 buffer interface
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file9324/ctypes-pep3118.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1971>
__________________________________
From report at bugs.python.org Wed Jan 30 11:58:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jan 2008 10:58:04 -0000
Subject: [New-bugs-announce] [issue1972] improve bytes and bytearray tests
In-Reply-To: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za>
Message-ID: <1201690684.03.0.553815304341.issue1972@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
Currently some tests in test_bytes.py only test bytearray, others only
test bytes. Here is a patch to try to make test coverage more extensive.
You'll notice there is a small hack in test_fromhex, that's because
bytes.fromhex is buggy, I'll open a separate bug entry for that.
----------
components: Tests
files: bytestest.patch
messages: 61854
nosy: pitrou
severity: normal
status: open
title: improve bytes and bytearray tests
versions: Python 3.0
Added file: http://bugs.python.org/file9328/bytestest.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1972>
__________________________________
From report at bugs.python.org Wed Jan 30 11:59:43 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jan 2008 10:59:43 -0000
Subject: [New-bugs-announce] [issue1973] bytes.fromhex('') raises SystemError
In-Reply-To: <1201690783.64.0.509716401018.issue1973@psf.upfronthosting.co.za>
Message-ID: <1201690783.64.0.509716401018.issue1973@psf.upfronthosting.co.za>
New submission from Antoine Pitrou:
>>> bytearray.fromhex('')
bytearray(b'')
>>> bytes.fromhex('')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: Objects/stringobject.c:3131: bad argument to internal function
----------
components: Interpreter Core
messages: 61855
nosy: pitrou
severity: normal
status: open
title: bytes.fromhex('') raises SystemError
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1973>
__________________________________
From report at bugs.python.org Wed Jan 30 15:48:05 2008
From: report at bugs.python.org (Chris Withers)
Date: Wed, 30 Jan 2008 14:48:05 -0000
Subject: [New-bugs-announce] [issue1974] email.MIMEText.MIMEText.as_string
incorrectly folding long subject header
In-Reply-To: <1201704485.29.0.575687789495.issue1974@psf.upfronthosting.co.za>
Message-ID: <1201704485.29.0.575687789495.issue1974@psf.upfronthosting.co.za>
New submission from Chris Withers:
Somewhere in email.MIMEText.MIMEText.as_string (I'm not sure where) long
subject headers are folded using a newline followed by a tab:
>>> from email.MIMEText import MIMEText
>>> m = MIMEText('foo')
>>> m['Subject']='AA '*40
>>> m.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version:
1.0\nContent-Transfer-Encoding: 7bit\nSubject: AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA\n\tAA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA \n\nfoo'
While RFC 822 section 3.1.1 doesn't forbid this type of folding, the
current behaviour mis-renders in both Thunderbird and Outlook.
Messages generated by Thunderbird and Outlook represent the above
subject as follows:
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version:
1.0\nContent-Transfer-Encoding: 7bit\nSubject: AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA\n AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA \n\nfoo'
Could the email library be adjusted to do the same? Years of wondering
why mails re-sent by mailman, mails from any number of python web
systems and recent complaints from customers of mine of mis-rendered
emails could be solved by doing so.
----------
components: Library (Lib)
messages: 61866
nosy: cjw296
severity: normal
status: open
title: email.MIMEText.MIMEText.as_string incorrectly folding long subject header
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1974>
__________________________________
From report at bugs.python.org Wed Jan 30 17:38:05 2008
From: report at bugs.python.org (Andriy Pylypenko)
Date: Wed, 30 Jan 2008 16:38:05 -0000
Subject: [New-bugs-announce] [issue1975] signals in thread problem
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
New submission from Andriy Pylypenko:
Hello,
This issue is actually a follow up of issue 960406. The patch applied
there brought in a problem at least under FreeBSD. The problem is
extremely annoying so I made an effort to uncover the source of it.
Here is an example code that shows the problem:
some_time = 6000000 # seconds
class MyThread(Thread):
def run(self):
while (True):
time.sleep(some_time)
t = MyThread()
t.start()
while(True):
select.select(None, None, None, some_time)
Start this script, then try to interrupt it by hitting Control-C. If you
run this code under Linux you won't see any problem. But under FreeBSD
the script won't stop until the timeout in main thread occurs or some
activity takes place on descriptors passed to the select().
My investigation showed that the source of the problem is in that how
signals are processed. FreeBSD processes signals in opposite order than
Linux. For example suppose we have a program that starts one user thread
and allows both main and user threads to receive signals. Under Linux
the signal handler always fires up in context of the main thread, but
under FreeBSD the signal handler runs in context of the user thread.
POSIX doesn't state which behavior is correct so both behaviors should
be assumed to be correct and Python should be aware of them both. Before
the patch from 960406 the Python made effort to deny signal handling in
user threads but the patch dropped this code and all threads are allowed
to handle signals.
Let's return to the script. When running the script under Linux the
select() call is the one that gets interrupted by the signal and this
allows the script to shutdown quickly. But under FreeBSD the sleep()
call is interrupted by the signal leaving the main thread to wait on
select() until timeout.
The description of issue 960406 states:
"This is a patch which will correct the issues some people have with
python's handling of signal handling in threads. It allows any thread to
initially catch the signal mark it as triggered, allowing the main
thread to later process it."
And yes it behaves exactly as described but this behavior is
inconsistent between different OSes.
To make things predictable I've restored the code that ensures that
signal handler will run in context of main thread only:
long
PyThread_start_new_thread(void (*func)(void *), void *arg)
{
...
+ sigset_t set, oset;
...
+ sigfillset(&set);
+ SET_THREAD_SIGMASK(SIG_BLOCK, &set, &oset);
pthread_create(...)
+ SET_THREAD_SIGMASK(SIG_SETMASK, &oset, NULL);
...
and this works perfectly for me under FreeBSD and Linux at least for my
needs. It doesn't bring any visible changes to readline behavior either.
I'm using the 2.5.1 version of Python. In attach you can find this patch
against the trunk.
I'm not Python guru but let me try to display my vision of the situation.
As I understand, my change does nothing for applications written in pure
Python and running under Linux (without user modules written in C and
using special thread and signal handling). Signals under Linux have
absolutely no chance to be caught from within user threads as Python
doesn't provide any way to alter the signal mask and with the default
signal mask the signals always arrive to the main thread. So explicit
prohibition to handle signals from within user thread doesn't change
anything. On the other hand this change ensures that under FreeBSD
things go exactly like under Linux.
Of course this change can possibly break some C-written module that
relies on signal handling in context of user thread (as the signal mask
of the user thread must be modified explicitly now). But anyway this is
how things are meant to work in order to be portable. So I'm considering
this possibility as highly unlikely.
I suppose the Mac OS X is affected also as it's based on FreeBSD.
----------
components: Interpreter Core
files: pthread_sig.diff
messages: 61870
nosy: bamby
severity: normal
status: open
title: signals in thread problem
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9333/pthread_sig.diff
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
__________________________________
From report at bugs.python.org Wed Jan 30 17:48:27 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Wed, 30 Jan 2008 16:48:27 -0000
Subject: [New-bugs-announce] [issue1976] pybsddb leak in using cursors
In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za>
Message-ID: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za>
New submission from Jes?s Cea Avi?n:
Iterating a cursor over a database seems to leak memory. See
http://sourceforge.net/mailarchive/forum.php?thread_name=4797B7D0.8060701%40gmail.com&forum_name=pybsddb-users
----------
components: Extension Modules
messages: 61871
nosy: jcea
severity: normal
status: open
title: pybsddb leak in using cursors
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1976>
__________________________________
From report at bugs.python.org Wed Jan 30 20:10:44 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 30 Jan 2008 19:10:44 -0000
Subject: [New-bugs-announce] [issue1977] Python reinitialization test
In-Reply-To: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za>
Message-ID: <1201720244.02.0.0976736262476.issue1977@psf.upfronthosting.co.za>
New submission from Christian Heimes:
The patch adds a new test and a new executable. The executable calls
Py_Initialze() and Py_Finalize() multiple times in a row. The test also
shows that Python looses about 35 references in each round.
$ ./test_reinit
round 1
[7751 refs]
round 2
[7797 refs]
round 3
[7834 refs]
round 4
[7871 refs]
round 5
[7908 refs]
round 6
[7945 refs]
round 7
[7982 refs]
round 8
[8019 refs]
round 9
[8056 refs]
round 10
[8093 refs]
----------
components: Build, Interpreter Core
files: test_reinit.patch
keywords: patch
messages: 61873
nosy: tiran
priority: normal
severity: normal
status: open
title: Python reinitialization test
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9334/test_reinit.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1977>
__________________________________
From report at bugs.python.org Wed Jan 30 23:58:34 2008
From: report at bugs.python.org (dugang@188.com)
Date: Wed, 30 Jan 2008 22:58:34 -0000
Subject: [New-bugs-announce] [issue1978] Python(2.5.1) will be crashed when
i use _ssl module in multi-threads environment in linux.
In-Reply-To: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za>
Message-ID: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za>
New submission from dugang at 188.com:
Python-2.5.1 will be crashed when i use _ssl module in multi-threads
environment in linux. the sample code looks as below(A https server is
running on host which ip is "192.168.5.151" and many certificates and
keys in PEM format are in the directory "./cert". These certificates
and keys are ok because i can use them in a web browser like IE/
Firefox.):
------------------------------------------------------------------------
------
#! /home/duxg/Download/soft/Python-2.5.1/python
#
# filename: test.py
#
'''This script simulates the behaviors of a https client.'''
import threading
import httplib
class HTTPSClient(threading.Thread):
def __init__(self, server_ip, url, cert_file, key_file):
threading.Thread.__init__(self)
# get run parameters
self.server_ip = server_ip
self.url = url
self.cert_file = cert_file
self.key_file = key_file
def get(self):
# make headers
headers = {'User-Agent': 'https_test/dugang at 188.com',
'Connection': 'close'
}
# use httplib
conn = httplib.HTTPSConnection('%s' % self.server_ip, \
key_file = self.key_file, \
cert_file = self.cert_file)
# http get
conn.request('GET', self.url, headers = headers)
resp = conn.getresponse()
# check response
if resp.status != 200:
print 'get(%s) failed/status=%d.' % (self.url, resp.status)
return False
return True
def run(self):
while True:
self.get()
def main():
worker_number = 100
threading.stack_size(512 * 1024)
worker = []
for i in range(worker_number):
# create worker thread
worker.append(HTTPSClient('192.168.5.151', '/test.html', \
'./cert/testu%d.cert' % i, \
'./cert/testu%d.key' % i))
for w in worker:
# go
w.start()
for w in worker:
# wait
w.join()
main()
------------------------------------------------------------------------
------
This code will be produced a lot of exceptions and finally it will
cause Python crashed.
------------------------------------------------------------------------
------
Exception in thread Thread-19:
Traceback (most recent call last):
File "/home/duxg/Download/soft/Python-2.5.1/Lib/threading.py", line
460, in __bootstrap
self.run()
File "./test.py", line 39, in run
self.get()
File "./test.py", line 29, in get
conn.request('GET', self.url, headers = headers)
File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line
862, in request
self._send_request(method, url, body, headers)
File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line
885, in _send_request
self.endheaders()
File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line
856, in endheaders
self._send_output()
File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line
728, in _send_output
self.send(msg)
File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line
695, in send
self.connect()
File "/home/duxg/Download/soft/Python-2.5.1/Lib/httplib.py", line
1131, in connect
ssl = socket.ssl(sock, self.key_file, self.cert_file)
File "/home/duxg/Download/soft/Python-2.5.1/Lib/socket.py", line 74,
in ssl
return _realssl(sock, keyfile, certfile)
sslerror: SSL_CTX_use_certificate_chain_file error
...
*** glibc detected *** /home/duxg/Download/soft/Python-2.5.1/python:
double free or corruption (!prev): 0x0a2b71a0 ***
======= Backtrace: =========
/lib/libc.so.6[0x887f41]
/lib/libc.so.6(cfree+0x90)[0x88b580]
/lib/libcrypto.so.6(CRYPTO_free+0x3a)[0x14f46a]
/lib/libcrypto.so.6(ERR_clear_error+0x73)[0x1a4d13]
/lib/libssl.so.6(SSL_CTX_use_certificate_chain_file+0x227)[0x358e47]
/home/duxg/Download/soft/Python-2.5.1/build/lib.linux-i686-2.5/
_ssl.so[0xb9eb9e]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x5d2c)[0x80c539c]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalCodeEx+0x775)[0x80c65d5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x5419)[0x80c4a89]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalCodeEx+0x775)[0x80c65d5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x5419)[0x80c4a89]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalFrameEx+0x6155)[0x80c57c5]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_EvalCodeEx+0x775)[0x80c65d5]
/home/duxg/Download/soft/Python-2.5.1/python[0x810d6f1]
/home/duxg/Download/soft/Python-2.5.1/
python(PyObject_Call+0x27)[0x805a277]
/home/duxg/Download/soft/Python-2.5.1/python[0x80603a7]
/home/duxg/Download/soft/Python-2.5.1/
python(PyObject_Call+0x27)[0x805a277]
/home/duxg/Download/soft/Python-2.5.1/
python(PyEval_CallObjectWithKeywords+0x6c)[0x80be7cc]
/home/duxg/Download/soft/Python-2.5.1/python[0x80f01e8]
/lib/libpthread.so.0[0xc292fb]
/lib/libc.so.6(clone+0x5e)[0x8f093e]
======= Memory map: ========
00110000-00113000 r-xp 00000000 08:05 2417874 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/time.so
00113000-00115000 rwxp 00002000 08:05 2417874 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/time.so
00115000-00119000 r-xp 00000000 08:05 2417882 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/collections.so
00119000-0011a000 rwxp 00004000 08:05 2417882 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/collections.so
0011a000-0011c000 r-xp 00000000 08:05 2417878 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/_random.so
0011c000-0011d000 rwxp 00002000 08:05 2417878 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/_random.so
0011d000-00239000 r-xp 00000000 08:03 491746 /lib/
libcrypto.so.0.9.8b
00239000-0024b000 rwxp 0011c000 08:03 491746 /lib/
libcrypto.so.0.9.8b
0024b000-0024f000 rwxp 0024b000 00:00 0
0024f000-0027b000 r-xp 00000000 08:09 623501 /usr/lib/
libgssapi_krb5.so.2.2
0027b000-0027c000 rwxp 0002c000 08:09 623501 /usr/lib/
libgssapi_krb5.so.2.2
0027c000-0027e000 r-xp 00000000 08:03 491630 /lib/libkeyutils-1.2.so
0027e000-0027f000 rwxp 00001000 08:03 491630 /lib/libkeyutils-1.2.so
00287000-00288000 r-xp 00287000 00:00 0 [vdso]
00288000-00317000 r-xp 00000000 08:09 623515 /usr/lib/libkrb5.so.3.3
00317000-00319000 rwxp 0008f000 08:09 623515 /usr/lib/libkrb5.so.3.3
00319000-00324000 r-xp 00000000 08:03 491522 /lib/libgcc_s-4.1.2-
20070503.so.1
00324000-00325000 rwxp 0000a000 08:03 491522 /lib/libgcc_s-4.1.2-
20070503.so.1
00328000-00369000 r-xp 00000000 08:03 491748 /lib/libssl.so.0.9.8b
00369000-0036d000 rwxp 00040000 08:03 491748 /lib/libssl.so.0.9.8b
003c8000-003ca000 r-xp 00000000 08:03 491577 /lib/libutil-2.6.so
003ca000-003cb000 r-xp 00001000 08:03 491577 /lib/libutil-2.6.so
003cb000-003cc000 rwxp 00002000 08:03 491577 /lib/libutil-2.6.so
00433000-00436000 r-xp 00000000 08:03 491551 /lib/libdl-2.6.so
00436000-00437000 r-xp 00002000 08:03 491551 /lib/libdl-2.6.so
00437000-00438000 rwxp 00003000 08:03 491551 /lib/libdl-2.6.so
00478000-0049f000 r-xp 00000000 08:03 491553 /lib/libm-2.6.so
0049f000-004a0000 r-xp 00026000 08:03 491553 /lib/libm-2.6.so
004a0000-004a1000 rwxp 00027000 08:03 491553 /lib/libm-2.6.so
004f4000-00506000 r-xp 00000000 08:03 491595 /lib/libz.so.1.2.3
00506000-00507000 rwxp 00011000 08:03 491595 /lib/libz.so.1.2.3
00581000-00591000 r-xp 00000000 08:03 491571 /lib/libresolv-2.6.so
00591000-00592000 r-xp 0000f000 08:03 491571 /lib/libresolv-2.6.so
00592000-00593000 rwxp 00010000 08:03 491571 /lib/libresolv-2.6.so
00593000-00595000 rwxp 00593000 00:00 0
005d7000-005d9000 r-xp 00000000 08:05 2417903 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/fcntl.so
005d9000-005da000 rwxp 00002000 08:05 2417903 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/fcntl.so
00651000-00654000 r-xp 00000000 08:05 2417915 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/cStringIO.so
00654000-00655000 rwxp 00003000 08:05 2417915 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/cStringIO.so
00734000-0073d000 r-xp 00000000 08:05 2417935 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/_socket.so
0073d000-00740000 rwxp 00009000 08:05 2417935 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/_socket.so
00820000-0096e000 r-xp 00000000 08:03 491545 /lib/libc-2.6.so
0096e000-00970000 r-xp 0014e000 08:03 491545 /lib/libc-2.6.so
00970000-00971000 rwxp 00150000 08:03 491545 /lib/libc-2.6.so
00971000-00974000 rwxp 00971000 00:00 0
009a7000-009a9000 r-xp 00000000 08:05 2417870 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/math.so
009a9000-009aa000 rwxp 00002000 08:05 2417870 /home/duxg/Download/
soft/Python-2.5.1/build/lib.linux-i686-2.5/math.so
00b11000-0Aborted (core dumped)
------------------------------------------------------------------------
------
I think the problem is in that the _ssl module does not correctly
initialize the OpenSSL Library, so i make a patch to fix it. now it
seems worked well.
----------
components: None
files: _ssl.c.patch
messages: 61880
nosy: dugang at 188.com
severity: normal
status: open
title: Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux.
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9335/_ssl.c.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1978>
__________________________________
From report at bugs.python.org Thu Jan 31 05:46:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Jan 2008 04:46:22 -0000
Subject: [New-bugs-announce] [issue1979] Make Decimal comparisons with NaN
less arbitrary
In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za>
Message-ID: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za>
New submission from Mark Dickinson:
For Python 3.0 the decimal module got rich comparisons. Those comparisons have somewhat unconventional
behavior with respect to NaNs, as seen below: <, <= and == comparisons involving NaNs always return False,
while >, >= and != comparisons always return True.
The Decimal specification has nothing helpful to say about comparisons involving NaNs. But reading IEEE-
754r (on which the Decimal specification is closely based), there are two possible options:
(1) have comparisons involving NaNs (except for !=) raise InvalidOperation in the context, and hence give a
Python exception (assuming that InvalidOperation isn't trapped.)
(2) have comparisons involving NaNs always return False (except for !=, which always returns True).
I think either of these is better than the current behavior. (2) seems like the better option, for a couple
of reasons: first, it's the way that Python floats currently work, and second, there might be issues with
list membership testing if equality comparisons involving NaNs raised an exception or returned a NaN.
Since Mike Cowlishaw is intimately involved with both the Decimal specification and the IEEE-754r process, I
thought it might be useful to have his opinion on this; his main recommendation was to have the Decimal
type do the same as the float type.
The attached patch makes <, <=, >, >= and == comparisons involving NaNs always return False, and !=
comparisons always return True. It also renames __cmp__ to _cmp and adds a few tests for the new behavior.
Here's how NaN comparisons currently work:
Python 3.0a2+ (py3k:60470M, Jan 30 2008, 23:11:40)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> n = Decimal("nan")
>>> i = Decimal("inf")
>>> n < n
False
>>> n > n
True
>>> i < n
False
>>> i > n
True
See also issue #1514428.
----------
assignee: facundobatista
components: Library (Lib)
files: richcmp.patch
keywords: patch
messages: 61884
nosy: facundobatista, marketdickinson
severity: minor
status: open
title: Make Decimal comparisons with NaN less arbitrary
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9337/richcmp.patch
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1979>
__________________________________
From report at bugs.python.org Thu Jan 31 12:19:38 2008
From: report at bugs.python.org (Erno Kuusela)
Date: Thu, 31 Jan 2008 11:19:38 -0000
Subject: [New-bugs-announce] [issue1980] pdb losing __file__
In-Reply-To: <1201778377.96.0.548753633413.issue1980@psf.upfronthosting.co.za>
Message-ID: <1201778377.96.0.548753633413.issue1980@psf.upfronthosting.co.za>
New submission from Erno Kuusela:
under pdb, __file__ is not defined when executing a source code file
directly.
for example, if myprogram.py contains "print __file__", a NameError will
be raised when run with python -m pdb myprogram.py.
----------
components: Library (Lib)
messages: 61896
nosy: erno
severity: normal
status: open
title: pdb losing __file__
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1980>
__________________________________
From report at bugs.python.org Thu Jan 31 17:17:02 2008
From: report at bugs.python.org (Alexander Shigin)
Date: Thu, 31 Jan 2008 16:17:02 -0000
Subject: [New-bugs-announce] [issue1981] operator "is"
In-Reply-To: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za>
Message-ID: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za>
New submission from Alexander Shigin:
Hello,
The operator "is" works strange with methods, i.e.:
>>> a = 1
>>> a.__abs__ is a.__abs__
False
If this is the preferred behavior by some reasons, I think
documentation should explain it.
It was tested on python 2.4.4, 2.5.1 and trunk r60477.
----------
messages: 61905
nosy: shigin
severity: normal
status: open
title: operator "is"
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1981>
__________________________________
From report at bugs.python.org Thu Jan 31 19:59:16 2008
From: report at bugs.python.org (Andreas Balogh)
Date: Thu, 31 Jan 2008 18:59:16 -0000
Subject: [New-bugs-announce] [issue1982] Feature: extend strftime to accept
milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
New submission from Andreas Balogh:
Currently serializing datetime objects into isoformat string is well
possible. The reverse process - parsing an isoformat string into a
datetime object - doesn't work due to the missing %-tag for the strftime
format string.
Proposal:
Add new tag to strftime like format strings allowing to print and parse
milliseconds.
----------
components: Extension Modules
messages: 61924
nosy: asbalogh
severity: normal
status: open
title: Feature: extend strftime to accept milliseconds
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1982>
__________________________________
From report at bugs.python.org Thu Jan 31 21:07:28 2008
From: report at bugs.python.org (Ryan Stutsman)
Date: Thu, 31 Jan 2008 20:07:28 -0000
Subject: [New-bugs-announce] [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
New submission from Ryan Stutsman:
In current trunk (60097). Return from fork is not int but pid_t.
Treating this as an int causes total breakage on systems with 64-bit pids.
----------
components: Library (Lib)
messages: 61926
nosy: stutsman
severity: normal
status: open
title: Return from fork() is pid_t, not int
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________
From report at bugs.python.org Thu Jan 31 23:26:08 2008
From: report at bugs.python.org (Neil Roques)
Date: Thu, 31 Jan 2008 22:26:08 -0000
Subject: [New-bugs-announce] [issue1984] The raw string r'\' fails
In-Reply-To: <1201818368.03.0.299164822165.issue1984@psf.upfronthosting.co.za>
Message-ID: <1201818368.03.0.299164822165.issue1984@psf.upfronthosting.co.za>
New submission from Neil Roques:
Python's raw strings are supposed to prevent characters being
interpreted as special. However entering the raw string r'\' into an
interactive session will result in:
Traceback ( File "<interactive input>", line 1
r'\'
^
SyntaxError: EOL while scanning single-quoted string
Python seems to have escaped the close of the string, even though raw
strings are not supposed to ever escape characters.
----------
components: Interpreter Core
messages: 61936
nosy: passage
severity: minor
status: open
title: The raw string r'\' fails
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1984>
__________________________________
From report at bugs.python.org Thu Jan 31 23:41:54 2008
From: report at bugs.python.org (Toni Brkic)
Date: Thu, 31 Jan 2008 22:41:54 -0000
Subject: [New-bugs-announce] [issue1985] Bug/Patch: Problem with
xml/__init__.py when using freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
New submission from Toni Brkic:
Hi,
I tried to do freeze.py for my script that uses ElementTree.
But got the this error:
File "/usr/lib/python2.5/xml/__init__.py", line 45, in <module>
_xmlplus.__path__.extend(__path__)
AttributeError: 'str' object has no attribute 'extend'
The reason seems that _xmlplus.__path__ is a string
after freeze.py.
I fixed it by changing the import to:
try:
_xmlplus.__path__.extend(__path__)
sys.modules[__name__] = _xmlplus
except AttributeError:
pass
This might not be the correct solution but it works for me. I do not
really now
how the __path__ variable works in a freezed environment.
Best regards
----------
messages: 61937
nosy: glomde
severity: normal
status: open
title: Bug/Patch: Problem with xml/__init__.py when using freeze.py
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
__________________________________