From report at bugs.python.org Sat Sep 1 03:22:45 2007
From: report at bugs.python.org (jinok)
Date: Sat, 01 Sep 2007 01:22:45 -0000
Subject: [New-bugs-announce] [issue1078] cachersrc.py using tuple unpacking
args
Message-ID: <1188609765.52.0.267937101138.issue1078@psf.upfronthosting.co.za>
New submission from jinok:
Mac/scripts/cachersrc.py contains tuple unpacking in handler function
args definition, causing "make frameworkinstall" to complain and exit
early.
----------
components: Macintosh
messages: 55546
nosy: jinok
severity: normal
status: open
title: cachersrc.py using tuple unpacking args
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1078>
__________________________________
From report at bugs.python.org Sat Sep 1 10:56:59 2007
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Gu=C3=A9rin?=)
Date: Sat, 01 Sep 2007 08:56:59 -0000
Subject: [New-bugs-announce] [issue1079] decode_header does not follow RFC
2047
Message-ID: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za>
New submission from Micka?l Gu?rin:
email.header.decode_header expect a space or end of line after the end
of an encoded word ("?="). There is nothing about that thing in RFC 2047.
Python 2.5.1 ChangeLog seems to indicate that this bug has been solved.
Unfortunately, the function still don't work.
A visible effet of the bad regex used has the consequence found in Issue
1467619
it seems there are 2 different regex with the same purpose in two
different files (ecre in header.py & ecre in utils.py). the one in
utils.py seems to give better results.
----------
components: Library (Lib)
messages: 55555
nosy: kael
severity: normal
status: open
title: decode_header does not follow RFC 2047
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1079>
__________________________________
From report at bugs.python.org Sat Sep 1 14:23:58 2007
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 01 Sep 2007 12:23:58 -0000
Subject: [New-bugs-announce] [issue1080] Search broken
Message-ID: <1188649438.83.0.0963732407749.issue1080@psf.upfronthosting.co.za>
New submission from Nir Soffer:
http://docs.python.org/dev/search.html
In Safari:
- does not find anything. e.g. search for print.
- The sections selection do not remember the user selection. e.g. select
Language Reference, search, the page comes out with Language Reference
deselected.
- The search term is not remembered - the search box is always empty
- There are not search results
In Firefox:
- Search interface remember the search term and the sections selection,
but the search results are always empty
----------
components: Documentation
messages: 55557
nosy: nirs
severity: normal
status: open
title: Search broken
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1080>
__________________________________
From report at bugs.python.org Sat Sep 1 15:34:52 2007
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Sep 2007 13:34:52 -0000
Subject: [New-bugs-announce] [issue1081] file.seek allows float arguments
Message-ID: <1188653692.21.0.272026502521.issue1081@psf.upfronthosting.co.za>
New submission from Georg Brandl:
Although documented as deprecated, file.seek accepts float arguments in 3.0.
----------
keywords: py3k
messages: 55558
nosy: georg.brandl
severity: normal
status: open
title: file.seek allows float arguments
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1081>
__________________________________
From report at bugs.python.org Sat Sep 1 17:34:23 2007
From: report at bugs.python.org (Pat LaVarre)
Date: Sat, 01 Sep 2007 15:34:23 -0000
Subject: [New-bugs-announce] [issue1082] platform system may be Windows or
Microsoft since Vista
Message-ID: <1188660863.15.0.271391863647.issue1082@psf.upfronthosting.co.za>
New submission from Pat LaVarre:
SUMMARY:
'Microsoft' is the platform.system() of Vista Windows, whereas 'Windows'
was the platform.system() of XP Windows, whoops.
STEPS TO REPRODUCE & ACTUAL RESULTS:
Run 2.5.1 Python in a Vista and see:
>>> import platform
>>> platform.system()
>>>
'Microsoft'
>>>
EXPECTED RESULTS:
>>> import platform
>>> platform.system()
'Windows'
>>>
WORKAROUND:
Write new Python source code like:
if platform.system() in ('Windows', 'Microsoft'):
if not (platform.system() in ('Windows', 'Microsoft')):
in place of obsolete Python source code like:
if platform.system() == 'Windows': # Microsoft
if platform.system() != 'Windows': # Microsoft
REGRESSION/ ISOLATION:
Seen by me in an Enterprise Vista. Indexed by Google as reported by
Martin v. L?wis (loewis) circa 2007-05-29 07:11 as:
http://mail.python.org/pipermail/patches/2007-June/022947.html
...
Patches item #1726668, was opened at 2007-05-28 03:23
On Microsoft Vista platform.system() returns 'Microsoft' and
platform.release() returns 'Windows'
Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and
platform.release() returns 'XP'.
This is problem was caused by a change in the output of the "ver"
command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP
[Version 5.1.2600]' In Microsoft Vista "ver" outputted 'Microsoft
Windows [Version 6.0.6000]'. The lack of the 3rd word before version
causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system
instead of 'Microsoft Windows'. This causes uname() to return the
incorrect values. Both system() and release() call uname().
NOTES:
There is no fixing all of this?
Cross-platform scripts actually will misbehave across the large
population that is 2.5 Python in Vista unless those scripts change to
implement something like the suggested workaround, that's now an
accomplished fact.
Question: Is it better to leave this feature as is, so that everyone
eventually learns to workaround it, or is it better to fix it late now
in 2007-09, so that many people never have to learn to workaround it?
Question: Why are we screen-scraping the Ver command, instead of calling
Win kernel32.getVersionEx? And how can any code for screen-scraping the
Ver command be in doubt about whether the platform.system underneath is
'Windows'?
----------
components: Windows
messages: 55561
nosy: p.lavarre at ieee.org
severity: major
status: open
title: platform system may be Windows or Microsoft since Vista
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1082>
__________________________________
From report at bugs.python.org Sat Sep 1 21:19:34 2007
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 01 Sep 2007 19:19:34 -0000
Subject: [New-bugs-announce] [issue1083] Confusing error message when
dividing timedelta using /
Message-ID: <1188674374.08.0.925919990107.issue1083@psf.upfronthosting.co.za>
New submission from Skip Montanaro:
I discovered the hard way today that this won't work:
>>> import datetime
>>> d = datetime.timedelta(1)
>>> d / 2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int'
The error message is misleading, because in fact timedelta
objects *do* support division by ints, just not with the
/ operator:
>>> d // 2
datetime.timedelta(0, 43200)
Is there some way the error message can be improved,
perhaps by identifying the denominator as effectively
a float?
----------
components: Interpreter Core
messages: 55566
nosy: skip.montanaro
severity: normal
status: open
title: Confusing error message when dividing timedelta using /
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083>
__________________________________
From report at bugs.python.org Sun Sep 2 14:14:29 2007
From: report at bugs.python.org (xyb)
Date: Sun, 02 Sep 2007 12:14:29 -0000
Subject: [New-bugs-announce] [issue1086] test_email failed
Message-ID: <1188735269.69.0.0628982068821.issue1086@psf.upfronthosting.co.za>
New submission from xyb:
test test_email failed -- Traceback (most recent call last):
File "/home/xyb/Python-3.0a1/Lib/email/test/test_email.py", line 1445,
in test_same_boundary_inner_outer
msg = self._msgobj('msg_15.txt')
File "/home/xyb/Python-3.0a1/Lib/email/test/test_email.py", line 67,
in _msgobj
return email.message_from_file(fp)
File "/home/xyb/Python-3.0a1/Lib/email/__init__.py", line 46, in
message_from_file
return Parser(*args, **kws).parse(fp)
File "/home/xyb/Python-3.0a1/Lib/email/parser.py", line 68, in parse
data = fp.read(8192)
File "/home/xyb/Python-3.0a1/Lib/io.py", line 1231, in read
readahead, pending = self._read_chunk()
File "/home/xyb/Python-3.0a1/Lib/io.py", line 1127, in _read_chunk
pending = self._decoder.decode(readahead, not readahead)
File "/home/xyb/Python-3.0a1/Lib/codecs.py", line 291, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xbe in position 86:
unexpected code byte
----------
messages: 55583
nosy: xyb
severity: normal
status: open
title: test_email failed
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1086>
__________________________________
From report at bugs.python.org Sun Sep 2 23:00:13 2007
From: report at bugs.python.org (Graham Horler)
Date: Sun, 02 Sep 2007 21:00:13 -0000
Subject: [New-bugs-announce] [issue1088] News page broken link to 3.0a1
Message-ID: <1188766813.17.0.0415268003113.issue1088@psf.upfronthosting.co.za>
New submission from Graham Horler:
The news page:
http://www.python.org/news/
...has a relative link:
<a class="reference" href="download/releases/3.0">first alpha release</a>
...which resolves to:
http://www.python.org/news/download/releases/3.0
...which does not exist. It should be absolute:
http://www.python.org/download/releases/3.0/
----------
messages: 55593
nosy: grahamh
severity: normal
status: open
title: News page broken link to 3.0a1
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1088>
__________________________________
From report at bugs.python.org Mon Sep 3 04:02:01 2007
From: report at bugs.python.org (Waldemar Osuch)
Date: Mon, 03 Sep 2007 02:02:01 -0000
Subject: [New-bugs-announce] [issue1090] doctools/sphinx/web/application.py
does not start on windows
Message-ID: <1188784920.26.0.259040643961.issue1090@psf.upfronthosting.co.za>
New submission from Waldemar Osuch:
Loading pickles on windows without specifying 'rb' does not work in
http://svn.python.org/projects/doctools/trunk/sphinx/web/application.py
A simple patch attached
----------
components: Documentation tools (Sphinx)
files: sphinx_web_application.patch
messages: 55595
nosy: osuchw
severity: normal
status: open
title: doctools/sphinx/web/application.py does not start on windows
type: crash
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1090>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sphinx_web_application.patch
Type: application/octet-stream
Size: 1059 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070903/ac884085/attachment.obj
From report at bugs.python.org Mon Sep 3 04:12:56 2007
From: report at bugs.python.org (Humberto Diogenes)
Date: Mon, 03 Sep 2007 02:12:56 -0000
Subject: [New-bugs-announce] [issue1091] [patch] py3k Mac installation errors
Message-ID: <1188785576.14.0.654103723066.issue1091@psf.upfronthosting.co.za>
New submission from Humberto Diogenes:
This patch addresses 3 simple errors (1 syntax, 1 runtime, 1 import) when
doing a "make altinstall" on Mac OS X, including the error listed in issue
1078.
----------
components: Installation, Macintosh
files: py3k-mac-install-1.patch
messages: 55596
nosy: hdiogenes
severity: normal
status: open
title: [patch] py3k Mac installation errors
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1091>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: py3k-mac-install-1.patch
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070903/28a21476/attachment.txt
From report at bugs.python.org Mon Sep 3 05:36:47 2007
From: report at bugs.python.org (Vizcaynot)
Date: Mon, 03 Sep 2007 03:36:47 -0000
Subject: [New-bugs-announce] [issue1092] Unexpected results in Tutorial
about Unicode
Message-ID: <1188790607.8.0.739401966069.issue1092@psf.upfronthosting.co.za>
New submission from Vizcaynot:
When trying the tutorial example about unicode I have:
>>> "?pfel".encode('utf-8')
File "<stdin>", line 1
SyntaxError: (unicode error) unexpected code byte
I live in a latin american country so I need to do:
>>> "?pfel".decode('latin-1).encode('utf-8')
File "<stdin>", line 1
>>>
but the indentation " >>>" is new for me, so I attempt the next:
>>> a="?pfel".decode('latin-1).encode('utf-8')
File "<stdin>", line 1
>>> a
b'\xc3\x84pfel'
>>> print (a)
?pfel
>>>
Is this necessary to do correction to the tutorial? is this normal the
presence of " >>>" that appears indented once I assign the value to
variable a?
Thanks!!
----------
components: Unicode
messages: 55598
nosy: Viscaynot
severity: normal
status: open
title: Unexpected results in Tutorial about Unicode
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092>
__________________________________
From report at bugs.python.org Mon Sep 3 06:27:02 2007
From: report at bugs.python.org (Ryan Freckleton)
Date: Mon, 03 Sep 2007 04:27:02 -0000
Subject: [New-bugs-announce] [issue1093] product function patch
Message-ID: <1188793621.44.0.829352690198.issue1093@psf.upfronthosting.co.za>
New submission from Ryan Freckleton:
This is a patch to implement a product() builtin function. It works
behaves similarly to reduce(operator.mul,...) but is implemented in C.
Tests and documentation are included in this patch.
----------
components: Documentation, Library (Lib), Tests
files: product_function.diff
messages: 55599
nosy: ryan.freckleton
severity: normal
status: open
title: product function patch
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1093>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: product_function.diff
Type: text/x-patch
Size: 3636 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070903/ad3b4154/attachment.bin
From report at bugs.python.org Mon Sep 3 11:07:07 2007
From: report at bugs.python.org (Serge Julien)
Date: Mon, 03 Sep 2007 09:07:07 -0000
Subject: [New-bugs-announce] [issue1094] TypeError in poplib.py
Message-ID: <1188810427.64.0.302486588482.issue1094@psf.upfronthosting.co.za>
New submission from Serge Julien:
In poplib.py, lines 137-138, bytes and str are compared, leading to a
TypeError:
[...]
137 while line != '.':
138 if line[:2] == '..':
[...]
where type(line) = <type 'bytes'>
----------
components: Library (Lib)
messages: 55617
nosy: serge.julien
severity: normal
status: open
title: TypeError in poplib.py
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1094>
__________________________________
From report at bugs.python.org Mon Sep 3 19:09:15 2007
From: report at bugs.python.org (Aki)
Date: Mon, 03 Sep 2007 17:09:15 -0000
Subject: [New-bugs-announce] [issue1095] make install failed
Message-ID: <1188839355.89.0.39344138919.issue1095@psf.upfronthosting.co.za>
New submission from Aki:
I thought this was already reported but I didn't see it in the list.
If this issue is already addressed, please discard.
The 'make install' failed if I re-run the installation again because
python-config under /usr/local/bin was already there.
Removing /usr/local/lib/python2.5/lib-dynload/Python-2.5.1-py2.5.egg-info
Writing /usr/local/lib/python2.5/lib-dynload/Python-2.5.1-py2.5.egg-info
if test -f /usr/local/bin/python -o -h /usr/local/bin/python; \
then rm -f /usr/local/bin/python; \
else true; \
fi
(cd /usr/local/bin; ln python2.5 python)
(cd /usr/local/bin; ln -sf python2.5-config python-config)
ln: cannot create python-config: File exists
make: *** [bininstall] Error 2
I didn't see such problem under 2.4.
Aki-
----------
components: Installation
messages: 55624
nosy: akineko
severity: normal
status: open
title: make install failed
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1095>
__________________________________
From report at bugs.python.org Tue Sep 4 04:21:42 2007
From: report at bugs.python.org (Sangpil Yoon)
Date: Tue, 04 Sep 2007 02:21:42 -0000
Subject: [New-bugs-announce] [issue1097] input() should respect
sys.stdin.encoding when in interactive mode
Message-ID: <1188872501.42.0.387468131145.issue1097@psf.upfronthosting.co.za>
New submission from Sangpil Yoon:
Currently in interactive mode, when you try to input non-ascii
characters using input() builtin function, you get UnicodeDecodeError.
>>> print(input())
???
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1:
illegal encoding
The error says that input() function is trying to decode the byte string
using the utf8 codec, when sys.stdin.encoding is not 'utf8'.
>>> import sys; print(sys.stdin.encoding)
cp949
In non-interactive mode, input() works just fine.
----------
components: Unicode
messages: 55627
nosy: philyoon
severity: normal
status: open
title: input() should respect sys.stdin.encoding when in interactive mode
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1097>
__________________________________
From report at bugs.python.org Tue Sep 4 07:38:55 2007
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 04 Sep 2007 05:38:55 -0000
Subject: [New-bugs-announce] [issue1098] decode_unicode doesn't nul-terminate
Message-ID: <1188884335.29.0.623763077822.issue1098@psf.upfronthosting.co.za>
New submission from Adam Olsen:
In the large else branch in decode_unicode (if encoding is not NULL or
"iso-8859-1"), the new string it produces is not nul-terminated. This
then hits PyUnicode_DecodeUnicodeEscape's octal escape case, which reads
past the end of the string (but would stop if there was a nul there.)
I found this via valgrind.
----------
messages: 55630
nosy: rhamphoryncus
severity: normal
status: open
title: decode_unicode doesn't nul-terminate
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1098>
__________________________________
From report at bugs.python.org Tue Sep 4 08:17:02 2007
From: report at bugs.python.org (Humberto Diogenes)
Date: Tue, 04 Sep 2007 06:17:02 -0000
Subject: [New-bugs-announce] [issue1099] Mac compile fails with pydebug and
framework enabled
Message-ID: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za>
New submission from Humberto Diogenes:
Running this on Mac OS X:
$ ./configure --with-pydebug --enable-framework
$ make
I get this:
(...)
ar cr libpython3.0.a Modules/config.o Modules/getpath.o Modules/main.o
Modules/gcmodule.o
ar cr libpython3.0.a Modules/threadmodule.o Modules/signalmodule.o
Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o
Modules/_codecsmodule.o Modules/_fileio.o Modules/zipimport.o
Modules/symtablemodule.o Modules/xxsubtype.o
ranlib libpython3.0.a
/usr/bin/install -c -d -m 755 Python.framework/Versions/3.0
if test ""; then \
gcc -o Python.framework/Versions/3.0/Python -arch i386 -arch ppc -dynamiclib
\
-isysroot "" \
-all_load libpython3.0.a -Wl,-single_module \
-install_name
/Library/Frameworks/Python.framework/Versions/3.0/Python \
-compatibility_version 3.0 \
-current_version 3.0; \
else \
/usr/bin/libtool -o Python.framework/Versions/3.0/Python -dynamic
libpython3.0.a \
-lSystem -lSystemStubs -arch_only i386 -install_name
/Library/Frameworks/Python.framework/Versions/3.0/Python -compatibility_version 3.0 -
current_version 3.0 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/3.0/Python] Error 1
If using only --with-pydebug it works fine.
----------
components: Build, Macintosh
messages: 55631
nosy: hdiogenes
severity: normal
status: open
title: Mac compile fails with pydebug and framework enabled
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1099>
__________________________________
From report at bugs.python.org Tue Sep 4 08:50:40 2007
From: report at bugs.python.org (Sangpil Yoon)
Date: Tue, 04 Sep 2007 06:50:40 -0000
Subject: [New-bugs-announce] [issue1100] Can't input non-ascii characters in
interactive mode
Message-ID: <1188888639.72.0.692708341889.issue1100@psf.upfronthosting.co.za>
New submission from Sangpil Yoon:
I'm not sure if this is a bug or a designed behavior, but I think it
would be nice for beginners to be able to enter his/her local characters
from an interactive prompt. As interactive mode lacks source code
encoding declaration, the interpreter seems to assume that its input is
encoded in UTF-8, when the actual characters you enter are not. Fix for
issue #1097 doesn't seem to help. I'm using Microsoft Windows XP Korean.
>>> print('???')
File "<stdin>", line 1
SyntaxError: (unicode error) illegal encoding
----------
components: Unicode
messages: 55632
nosy: philyoon
severity: normal
status: open
title: Can't input non-ascii characters in interactive mode
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100>
__________________________________
From report at bugs.python.org Tue Sep 4 22:57:38 2007
From: report at bugs.python.org (Richard Katz)
Date: Tue, 04 Sep 2007 20:57:38 -0000
Subject: [New-bugs-announce] [issue1101] Is there just no PRINT statement
any more? Or it just doesn't work.
Message-ID: <1188939458.07.0.206178975211.issue1101@psf.upfronthosting.co.za>
New submission from Richard Katz:
Is there supposed to be a way to do
for x in 1,2,3: print x,
If so, it's appears to be not working. Is it just not in this release?
If not, I would think that leaving out the print statement (just
because there is a print function) would represent a major problem for
cross-platform books and training materials. Just a thought.
How would one achieve this capability in Python 3.0? Was it the
intention to remove this capability?
Thank you.
Regards,
Rich
----------
components: Interpreter Core
messages: 55643
nosy: richkatz
severity: major
status: open
title: Is there just no PRINT statement any more? Or it just doesn't work.
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1101>
__________________________________
From report at bugs.python.org Tue Sep 4 23:29:35 2007
From: report at bugs.python.org (Dan Thomasset)
Date: Tue, 04 Sep 2007 21:29:35 -0000
Subject: [New-bugs-announce] [issue1103] Typo in dummy_threading
documentation
Message-ID: <1188941375.76.0.679119193324.issue1103@psf.upfronthosting.co.za>
New submission from Dan Thomasset:
I believe that "thread" be "threading" in the line "...imported when the
thread module is not provided..."?
>From http://docs.python.org/lib/module-dummythreading.html
----------
components: Documentation
messages: 55645
nosy: dthomasset
severity: normal
status: open
title: Typo in dummy_threading documentation
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1103>
__________________________________
From report at bugs.python.org Wed Sep 5 00:03:41 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=)
Date: Tue, 04 Sep 2007 22:03:41 -0000
Subject: [New-bugs-announce] [issue1104] msilib.SummaryInfo.GetProperty()
truncates the string by one character
Message-ID: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
New submission from
Anthony Tuininga
:
Attached is a patch that fixes the truncation of the property values
returned by msilib.SummaryInfo.GetProperty(). Unfortunately Microsoft
has deemed it necessary to return the size of the string without the
null termination character but insists upon the size including it when
passing it in. Arggh!
----------
components: Library (Lib)
files: _msi.patch2.txt
messages: 55649
nosy: atuining
severity: normal
status: open
title: msilib.SummaryInfo.GetProperty() truncates the string by one character
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1104>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: _msi.patch2.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070904/626fde06/attachment.txt
From report at bugs.python.org Wed Sep 5 02:33:41 2007
From: report at bugs.python.org (Ty)
Date: Wed, 05 Sep 2007 00:33:41 -0000
Subject: [New-bugs-announce] [issue1105] patch for readme.txt in PCbuild8
Message-ID: <1188952421.48.0.821192940412.issue1105@psf.upfronthosting.co.za>
New submission from Ty:
This update adds some comments to the readme.txt file for PCbuild8.
When building subprojects VS2005 does not build the dependencies. I
have included some text to alert the reader to this so they don't have
the same trouble building subprojects as I did.
I encountered this problem when building the pythoncore subproject.
VS2005 did not build its dependencies (make_buildinfo, make_versioninfo)
for me.
----------
components: Documentation
files: pcbuild8_readme_txt.patch
messages: 55651
nosy: chipped
severity: normal
status: open
title: patch for readme.txt in PCbuild8
type: compile error
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1105>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcbuild8_readme_txt.patch
Type: application/octet-stream
Size: 854 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070905/d72b729a/attachment.obj
From report at bugs.python.org Wed Sep 5 04:20:44 2007
From: report at bugs.python.org (Vizcaynot)
Date: Wed, 05 Sep 2007 02:20:44 -0000
Subject: [New-bugs-announce] [issue1106] Error in random.shuffle
Message-ID: <1188958843.33.0.414139103758.issue1106@psf.upfronthosting.co.za>
New submission from Vizcaynot:
In python 3.0a1 under Win XP SP2:
Typing next code:
import random
s=range(10)
random.shuffle(s)
I have next error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python30\lib\random.py", line 262, in shuffle
x[i], x[j] = x[j], x[i]
TypeError: 'range' object does not support item assignment
It does not happen in python 2.5
----------
components: Library (Lib)
messages: 55653
nosy: Viscaynot
severity: normal
status: open
title: Error in random.shuffle
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1106>
__________________________________
From report at bugs.python.org Wed Sep 5 07:52:58 2007
From: report at bugs.python.org (Jeong-Min Lee)
Date: Wed, 05 Sep 2007 05:52:58 -0000
Subject: [New-bugs-announce] [issue1107] [patch] 2to3,
lambda with non-tuple argument inside parenthesis
Message-ID: <1188971578.16.0.124603302539.issue1107@psf.upfronthosting.co.za>
New submission from Jeong-Min Lee:
lambda (x): x
should be transformed to
lambda x: x
not
lambda x1: x1[0]
----------
components: Demos and Tools
files: 2to3_lambda_nontuple_param.diff
messages: 55654
nosy: falsetru, gvanrossum
severity: normal
status: open
title: [patch] 2to3, lambda with non-tuple argument inside parenthesis
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1107>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2to3_lambda_nontuple_param.diff
Type: text/x-patch
Size: 1303 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070905/cf48ca68/attachment.bin
From report at bugs.python.org Wed Sep 5 12:53:25 2007
From: report at bugs.python.org (Daniel Larsson)
Date: Wed, 05 Sep 2007 10:53:25 -0000
Subject: [New-bugs-announce] [issue1108] Problem with doctest and decorated
functions
Message-ID: <1188989604.95.0.0786142357028.issue1108@psf.upfronthosting.co.za>
New submission from Daniel Larsson:
Seems like doctest won't recognize functions inside the module under
test are actually in that module, if the function is decorated by a
decorator that wraps the function in an externally defined function,
such as in this silly example:
# decorator.py
import functools
def simplelog(f):
@functools.wraps(f)
def new_f(*args, **kwds):
print "Wrapper calling func"
return f(*args, **kwds)
return new_f
# test.py
from decorator import simplelog
@simplelog
def test():
"""
This test should fail, since the decorator prints output.
Seems I don't get called though
>>> test()
'works!'
"""
return "works!"
if __name__ == '__main__':
import doctest
doctest.testmod()
--
The problem lies in DocTestFinder._from_module, which checks if the
function's func_globals attribute is the same as the module's __dict__
attribute.
I'd propose to do the __module__/inspect.getmodule() checks (aren't they
both checking the same thing btw?) before the inspect.isfunction check.
----------
components: Library (Lib)
messages: 55660
nosy: danilo
severity: normal
status: open
title: Problem with doctest and decorated functions
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1108>
__________________________________
From report at bugs.python.org Wed Sep 5 17:22:18 2007
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 05 Sep 2007 15:22:18 -0000
Subject: [New-bugs-announce] [issue1109] Warning required when calling
register() on an ABCMeta subclass
Message-ID: <1189005738.21.0.407633694929.issue1109@psf.upfronthosting.co.za>
New submission from Mark Summerfield:
GvR asked me to add this to the bug tracker.
If you do this:
class A(ABCMeta): pass
A.register(list)
you get this error message:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded in __instancecheck__
This is not very helpful.
You probably meant to write:
class A(metaclass=ABCMeta): pass
Perhaps a warning message like this would be better:
"register() should not be called on an ABCMeta subclass; maybe you
forgot the metaclass keyword argument when declaring the class?"
----------
components: Interpreter Core
messages: 55663
nosy: mark
severity: normal
status: open
title: Warning required when calling register() on an ABCMeta subclass
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109>
__________________________________
From report at bugs.python.org Wed Sep 5 20:20:07 2007
From: report at bugs.python.org (Vlastimil Brom)
Date: Wed, 05 Sep 2007 18:20:07 -0000
Subject: [New-bugs-announce] [issue1110] Problems with the msi installer -
python-3.0a1.msi
Message-ID: <1189016407.59.0.83312820482.issue1110@psf.upfronthosting.co.za>
New submission from Vlastimil Brom:
I encountered problems installing python 3.0 alpha 1 from the MSI
installer supplied on the python download page (python-3.0a1.msi).
If the advanced option of the installer ("compile .py files to bytecode
after installation") is checked - the following message is shown
"There is a problem with this Windows installer package. A program run
as part of the setup did not finish as expected ..."
If I don't choose the option to compile files, the installation
finishes without any visible errors.
The result is in both cases the same however. After calling python.exe
it shows the version info etc. in the interactive prompt, but it
doesn't "respond" in any way.
e.g.
>>> 1+1
object : RuntimeError('lost sys.stdout',)
type : RuntimeError
refcount: 4
address : 00A65BD0
lost sys.stderr
>>>
Running of any .py file doesn't work either.
My system is Win XPh SP2 Czech (the same on Win XPp SP2 Czech).
Could possibly the Czech windows version/ language setting/ locale/
timezone or whatever be the problem (as there were some problems
reported with the manual compilation on German or Polish Winsows-
systems)?
Or am I missing something trivial?
Thanks,
Vlastimil Brom
----------
components: Windows
messages: 55665
nosy: vbr
severity: normal
status: open
title: Problems with the msi installer - python-3.0a1.msi
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1110>
__________________________________
From report at bugs.python.org Wed Sep 5 23:13:08 2007
From: report at bugs.python.org (Maciej Piechorka)
Date: Wed, 05 Sep 2007 21:13:08 -0000
Subject: [New-bugs-announce] [issue1111] Users' directories information
Message-ID: <1189026788.84.0.0955213468627.issue1111@psf.upfronthosting.co.za>
New submission from Maciej Piechorka:
User directories varies along systems. On unikses all user data is kept
in $HOME directory. Configuration is kept in dot-files. However on
others systems places are different.
Using predefined values would be most convinent.
----------
components: Library (Lib)
messages: 55671
nosy: uzytkownik
severity: minor
status: open
title: Users' directories information
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1111>
__________________________________
From report at bugs.python.org Thu Sep 6 01:00:42 2007
From: report at bugs.python.org (David Bolen)
Date: Wed, 05 Sep 2007 23:00:42 -0000
Subject: [New-bugs-announce] [issue1112] Test debug assertion in bsddb
test_1413192.py
Message-ID: <1189033242.12.0.566103014662.issue1112@psf.upfronthosting.co.za>
New submission from David Bolen:
The change made to Lib/bsddb/test/test_1413192.py to clean up temporary
files causes an abort in the DB library when trying to abort an open
transaction at object destruction type - currently when the Python
interpreter exits, because the transaction log file has been removed.
In the Windows debug version this also causes an assertion pop-up dialog
window. This has been seen on the 2.5 branch (r57311), trunk (r57286)
and py3k branch (57285).
The proposed change controls the object lifetime through a wrapper
object so the transaction object is destroyed before cleaning up the
filesystem. It has the added benefit of permitting the filesystem
cleanup to work under Windows since the files are no longer in use. The
test still generates a warning about a DBTxn aborted in destructor, but
does not abort the interpreter.
I have tried testing this without the original (issue 1413192, r42177)
change to _bsddb that it was testing, but neither my modified version
nor the original seem to crash in my environment, so I can't say
absolutely whether or not the proposed change affects what the test was
originally designed to test. I suspect subsequent changes to _bsddb.c
are perhaps also satisfying the original problem.
----------
components: Tests
files: test_1413192.py.diff
messages: 55672
nosy: db3l
severity: normal
status: open
title: Test debug assertion in bsddb test_1413192.py
type: crash
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1112>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_1413192.py.diff
Type: application/octet-stream
Size: 1133 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070905/4678e970/attachment.obj
From report at bugs.python.org Thu Sep 6 01:27:06 2007
From: report at bugs.python.org (Anand Patil)
Date: Wed, 05 Sep 2007 23:27:06 -0000
Subject: [New-bugs-announce] [issue1113] interrupt_main() fails to interrupt
raw_input()
Message-ID: <1189034825.75.0.817794101989.issue1113@psf.upfronthosting.co.za>
New submission from Anand Patil:
Mac OS 10.4, Python 2.5 from pythonmac.org: The function listen() in the
attached should be interrupted after a second, but it waits until return
is pressed before catching the exception.
----------
components: Macintosh
files: test.py
messages: 55673
nosy: anand
severity: normal
status: open
title: interrupt_main() fails to interrupt raw_input()
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1113>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python-script
Size: 314 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070905/f097ef35/attachment.bin
From report at bugs.python.org Thu Sep 6 05:32:34 2007
From: report at bugs.python.org (Luke Mewburn)
Date: Thu, 06 Sep 2007 03:32:34 -0000
Subject: [New-bugs-announce] [issue1114] _curses issues on 64-bit big-endian
(e.g, AIX)
Message-ID: <1189049554.49.0.320613302462.issue1114@psf.upfronthosting.co.za>
New submission from Luke Mewburn:
Attempting to use curses attributes with python 2.3.5 on AIX (64bit
powerpc) doesn't work, and occasionally results in exceptions being raised.
_cursesmodule.c assumes that attr_t is a `long' and uses the "l"
decoding of PyArg_ParseTuple() to read values from python to C. On
platforms where sizeof(int) == sizeof(long), this isn't a problem.
However, on LP64, especially big-endian LP64, this results in the wrong
value being stored in the target address.
My solution is to use ParseTuple("l") into a variable with an explicit
type of 'long', and then assign that to the attr_t variable that the
underlying curses(3) functions are called with.
(I don't know if there's a different convention for dealing with reading
numbers from python into underlying C types where the C type size isn't
consistently an `int' or a `long', other that reading into an explicit
int/long and then assigning/casting to the final type)
The code in question doesn't appear to have changed much between python
2.3.5 and the svn trunk (as at 20070906), and my patch for the former
applied fairly cleanly to my checkout of the latter. I've attached a
diff from the svn checkout.
----------
components: Extension Modules
files: curses-attr_t-long.diff
messages: 55675
nosy: lukemewburn
severity: normal
status: open
title: _curses issues on 64-bit big-endian (e.g, AIX)
type: behavior
versions: Python 2.3
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1114>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: curses-attr_t-long.diff
Type: text/x-patch
Size: 10141 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070906/ac29ca65/attachment-0001.bin
From report at bugs.python.org Thu Sep 6 08:47:35 2007
From: report at bugs.python.org (Zhang Zengbo)
Date: Thu, 06 Sep 2007 06:47:35 -0000
Subject: [New-bugs-announce] [issue1115] Minor Change For Better cross
compile
Message-ID: <1189061255.17.0.84912008961.issue1115@psf.upfronthosting.co.za>
New submission from Zhang Zengbo:
Some test in configure.in is AC_TRY_RUN, which can be replaced by
AC_TRY_COMPILE, achieve the same goal and give better support for cross
compiling. This patch is for svn reversion 57996.
----------
files: autocheck.patch
messages: 55678
nosy: zengbo
severity: minor
status: open
title: Minor Change For Better cross compile
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1115>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autocheck.patch
Type: text/x-patch
Size: 1596 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070906/fa316bc7/attachment.bin
From report at bugs.python.org Thu Sep 6 11:10:11 2007
From: report at bugs.python.org (Anthon van der Neut)
Date: Thu, 06 Sep 2007 09:10:11 -0000
Subject: [New-bugs-announce] [issue1116] reference in extending doc to
non-existing file
Message-ID: <1189069811.63.0.388251009768.issue1116@psf.upfronthosting.co.za>
New submission from Anthon van der Neut:
The extending Python doc for 2.5 (and 2.6) is still referring to
Python/pythonmain.c to look up how to call the Python parser with a
string. However the code (for the -c commandline option) is now in
Modules/main.c
See attached diff.txt fixes Doc/extending/extending.rst (it is probably
quiker to make the change by hand than to check the diff).
----------
components: Documentation
files: diff.txt
messages: 55682
nosy: anthon
severity: minor
status: open
title: reference in extending doc to non-existing file
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070906/dbe14c34/attachment.txt
From report at bugs.python.org Thu Sep 6 12:51:21 2007
From: report at bugs.python.org (David Ripton)
Date: Thu, 06 Sep 2007 10:51:21 -0000
Subject: [New-bugs-announce] [issue1117] Spurious warning about missing
_sha256 and _sha512 when not needed
Message-ID: <1189075881.9.0.366422086484.issue1117@psf.upfronthosting.co.za>
New submission from David Ripton:
Python 3.0a1, Gentoo Linux x86, with OpenSSL 0.9.8e installed.
$ ./configure; make
Failed to find the necessary bits to build these modules:
_sha256 _sha512
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.
setup.py says:
if (openssl_ver < 0x00908000):
# OpenSSL doesn't do these until 0.9.8 so we'll bring our
own hash
exts.append( Extension('_sha256', ['sha256module.c']) )
exts.append( Extension('_sha512', ['sha512module.c']) )
But I have openssl 0.9.8e. So openssl is new enough that I don't need
the _sha256 and _sha512 modules. And the comment says that "these
aren't strictly missing since they are unneeded", so the error message
is spurious.
----------
components: Build
messages: 55686
nosy: dripton
severity: minor
status: open
title: Spurious warning about missing _sha256 and _sha512 when not needed
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1117>
__________________________________
From report at bugs.python.org Thu Sep 6 12:54:57 2007
From: report at bugs.python.org (David Ripton)
Date: Thu, 06 Sep 2007 10:54:57 -0000
Subject: [New-bugs-announce] [issue1118] hashlib module fails with TypeError
Message-ID: <1189076097.81.0.41385534405.issue1118@psf.upfronthosting.co.za>
New submission from David Ripton:
The hashlib module seems not to work at all:
$ python3.0
Python 3.0a1 (py3k, Sep 5 2007, 08:17:11)
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> m = hashlib.md5()
>>> m.update("Nobody inspects")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object supporting the buffer API required
(Same error with hashlib.sha1(), etc.)
----------
components: Library (Lib)
messages: 55687
nosy: dripton
severity: normal
status: open
title: hashlib module fails with TypeError
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1118>
__________________________________
From report at bugs.python.org Thu Sep 6 15:11:26 2007
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 06 Sep 2007 13:11:26 -0000
Subject: [New-bugs-announce] [issue1119] Search index is messed up after
partial rebuilding
Message-ID: <1189084286.84.0.1451286541.issue1119@psf.upfronthosting.co.za>
New submission from Lars Gust?bel:
When rebuilding parts of the documentation the search index is emptied.
The problem is that the extensions are not stripped from the filenames
that are given to IndexBuilder.prune() method.
Therefore, the Search widget on http://docs.python.org/dev/3.0/ produces
no results.
----------
components: Documentation tools (Sphinx)
files: sphinx-index.diff
keywords: patch
messages: 55689
nosy: lars.gustaebel
severity: normal
status: open
title: Search index is messed up after partial rebuilding
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1119>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sphinx-index.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070906/191d5e0f/attachment.txt
From report at bugs.python.org Fri Sep 7 00:06:50 2007
From: report at bugs.python.org (David Ripton)
Date: Thu, 06 Sep 2007 22:06:50 -0000
Subject: [New-bugs-announce] [issue1120] "make altinstall" installs pydoc,
idle, smtpd.py with broken shebang lines
Message-ID: <1189116410.02.0.82025271699.issue1120@psf.upfronthosting.co.za>
New submission from David Ripton:
Gentoo Linux, x86, Python 3.0a
I did a vanilla "./configure; make; make test; make altinstall" build.
The following files were created in /usr/local/bin:
-rwxr-xr-x 1 root root 18036 Sep 6 17:49 smtpd.py
-rwxr-xr-x 1 root root 81 Sep 6 17:49 pydoc
-rwxr-xr-x 1 root root 96 Sep 6 17:49 idle
-rwxr-xr-x 1 root root 3644316 Sep 6 17:58 python3.0
-rwxr-xr-x 1 root root 1401 Sep 6 17:59 python3.0-config
As intended, altinstall does not create /usr/local/bin/python, so
"python" is still the pre-existing python2.5.
However, other binaries are installed as though /usr/local/bin/python
were created, so they don't work.
dripton at al ~ $ pydoc
bash: /usr/local/bin/pydoc: /usr/local/bin/python: bad interpreter: No
such file or directory
dripton at al ~ $ idle
bash: /usr/local/bin/idle: /usr/local/bin/python: bad interpreter: No
such file or directory
dripton at al ~ $ smtpd.py
bash: /usr/local/bin/smtpd.py: /usr/local/bin/python: bad interpreter:
No such file or directory
Suggest that "make altinstall" should not put anything in the bin
directory except pythonX.Y and pythonX.Y-config, which are "safe"
because of the embedded version numbers. Another option would be
installing those other binaries but with fixed shebang lines.
----------
components: Build
messages: 55714
nosy: dripton
severity: minor
status: open
title: "make altinstall" installs pydoc, idle, smtpd.py with broken shebang lines
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1120>
__________________________________
From report at bugs.python.org Fri Sep 7 01:30:44 2007
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Sep 2007 23:30:44 -0000
Subject: [New-bugs-announce] [issue1121] Document inspect.getfullargspec()
Message-ID: <1189121444.48.0.486854487775.issue1121@psf.upfronthosting.co.za>
New submission from Brett Cannon:
inspect.getfullargspec() needs to be documented before it is backported
to 2.6.
----------
components: Documentation
keywords: py3k
messages: 55717
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Document inspect.getfullargspec()
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1121>
__________________________________
From report at bugs.python.org Fri Sep 7 02:43:14 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andrew_Gaul=0A=09=09=09=09?=)
Date: Fri, 07 Sep 2007 00:43:14 -0000
Subject: [New-bugs-announce] [issue1122] PyTuple_Size and PyTuple_GET_SIZE
return type documentation incorrect
Message-ID: <1189125794.07.0.790446459894.issue1122@psf.upfronthosting.co.za>
New submission from
Andrew Gaul
:
Documentation claims int, API uses Py_ssize_t.
----------
components: Documentation
files: pytuple_size.patch
messages: 55718
nosy: gaul
severity: minor
status: open
title: PyTuple_Size and PyTuple_GET_SIZE return type documentation incorrect
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1122>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pytuple_size.patch
Type: text/x-patch
Size: 646 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070907/034f733c/attachment.bin
From report at bugs.python.org Fri Sep 7 03:18:41 2007
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 07 Sep 2007 01:18:41 -0000
Subject: [New-bugs-announce] [issue1123] split(None,
maxplit) does not strip whitespace correctly
Message-ID: <1189127921.0.0.701786903755.issue1123@psf.upfronthosting.co.za>
New submission from Nir Soffer:
string object .split doc say (http://docs.python.org/lib/string-
methods.html):
"If sep is not specified or is None, a different splitting algorithm
is applied. First, whitespace characters (spaces, tabs, newlines,
returns, and formfeeds) are stripped from both ends."
If the maxsplit argument is set and is smaller then the number of
possible parts, whitespace is not removed.
Examples:
>>> 'k: v\n'.split(None, 1)
['k:', 'v\n']
Expected: ['k:', 'v']
>>> u'k: v\n'.split(None, 1)
[u'k:', u'v\n']
Expected: [u'k:', u'v']
With larger values of maxsplits, it works correctly:
>>> 'k: v\n'.split(None, 2)
['k:', 'v']
>>> u'k: v\n'.split(None, 2)
[u'k:', u'v']
This looks like implementation bug, because there it does not make sense
that the striping depends on the maxsplit argument, and it will be hard
to explain such behavior.
Maybe the striping should be removed in Python 3? It does not make sense
to strip a string behind your back when you want to split it, and the
caller can easily strip the string if needed.
----------
components: Library (Lib)
messages: 55720
nosy: nirs
severity: normal
status: open
title: split(None, maxplit) does not strip whitespace correctly
versions: Python 2.4, Python 2.5, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1123>
__________________________________
From report at bugs.python.org Fri Sep 7 03:29:04 2007
From: report at bugs.python.org (Edward Abraham)
Date: Fri, 07 Sep 2007 01:29:04 -0000
Subject: [New-bugs-announce] [issue1124] Webchecker not parsing css "@import
url"
Message-ID: <1189128543.92.0.989336234213.issue1124@psf.upfronthosting.co.za>
New submission from Edward Abraham:
webchecker and its dependent, websucker, which are distributed with the
python tools, are not following references to stylesheets given with the
<style>@import url(mystyle.css);</style> declaration ...
This means that the websucker isn't copying across stylesheets ...
----------
components: Demos and Tools
messages: 55722
nosy: ready.eddy
severity: normal
status: open
title: Webchecker not parsing css "@import url"
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124>
__________________________________
From report at bugs.python.org Fri Sep 7 03:30:28 2007
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 07 Sep 2007 01:30:28 -0000
Subject: [New-bugs-announce] [issue1125] bytes.split shold have same
interface as str.split, or different name
Message-ID: <1189128628.62.0.444123560856.issue1125@psf.upfronthosting.co.za>
New submission from Nir Soffer:
>>> b'foo bar'.split()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: split() takes at least 1 argument (0 given)
>>> b'foo bar'.split(None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: expected an object with the buffer interface
str.split and bytes.split should have the same interface, or different
names.
----------
components: Library (Lib)
messages: 55723
nosy: nirs
severity: normal
status: open
title: bytes.split shold have same interface as str.split, or different name
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1125>
__________________________________
From report at bugs.python.org Fri Sep 7 04:00:06 2007
From: report at bugs.python.org (Nir Soffer)
Date: Fri, 07 Sep 2007 02:00:06 -0000
Subject: [New-bugs-announce] [issue1126] file.fileno and file.isatty()
should be implementable by any file like object
Message-ID: <1189130404.46.0.902963366118.issue1126@psf.upfronthosting.co.za>
New submission from Nir Soffer:
The docs (http://docs.python.org/dev/3.0/library/stdtypes.html#sequence-
types-str-bytes-list-tuple-buffer-range) warn that .fileno and .istty
should not be implemented by a file like object.
This require client to check if the file object has the attribute before
they call the method, instead of treating all files the same.
if hasattr(foo, 'istty'):
if foo.istty():
# ...
Instead of:
if foo.istty():
# ...
istty can easily return False. fileno can return invalid file descriptor
number (-1?).
----------
components: Library (Lib)
messages: 55724
nosy: nirs
severity: normal
status: open
title: file.fileno and file.isatty() should be implementable by any file like object
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1126>
__________________________________
From report at bugs.python.org Fri Sep 7 17:38:41 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Anthony_Tuininga=0A=09=09=09=09?=)
Date: Fri, 07 Sep 2007 15:38:41 -0000
Subject: [New-bugs-announce] [issue1128] msilib.Directory.make_short only
handles file names with a single dot in them
Message-ID: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
New submission from
Anthony Tuininga
:
Attached is a patch that fixes the handling of file names with 0 or 2 or
more dots in them.
----------
components: Library (Lib)
files: msilib.__init__.patch
messages: 55736
nosy: atuining
severity: normal
status: open
title: msilib.Directory.make_short only handles file names with a single dot in them
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msilib.__init__.patch
Type: application/octet-stream
Size: 556 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070907/2dce6a39/attachment.obj
From report at bugs.python.org Fri Sep 7 20:41:13 2007
From: report at bugs.python.org (Stefan Sonnenberg-Carstens)
Date: Fri, 07 Sep 2007 18:41:13 -0000
Subject: [New-bugs-announce] [issue1129] OpenSSL detection broken for Python
3.0a1
Message-ID: <1189190473.33.0.541270501112.issue1129@psf.upfronthosting.co.za>
New submission from Stefan Sonnenberg-Carstens:
In line 618 the comparison must be this:
if (openssl_ver >= 0x00908000):
otherwise there are complaints about not being able to build
the _sha256 and _sha512 modules, even if OpenSSL >= 0.9.8 is installed,
as in my case.
----------
components: Build
messages: 55739
nosy: pythonmeister
severity: major
status: open
title: OpenSSL detection broken for Python 3.0a1
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1129>
__________________________________
From report at bugs.python.org Sat Sep 8 16:26:46 2007
From: report at bugs.python.org (Martoon)
Date: Sat, 08 Sep 2007 14:26:46 -0000
Subject: [New-bugs-announce] [issue1131] Reference Manual: "for statement"
links to "break statement"
Message-ID: <1189261606.63.0.731863815779.issue1131@psf.upfronthosting.co.za>
New submission from Martoon:
Error in the Windows distro documentation. If you go to "for" or "for
statement" in the index, it brings you to the doc page for "The break
statement."
----------
components: Documentation, Windows
messages: 55749
nosy: Martoon
severity: minor
status: open
title: Reference Manual: "for statement" links to "break statement"
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1131>
__________________________________
From report at bugs.python.org Sat Sep 8 22:15:36 2007
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9?=)
Date: Sat, 08 Sep 2007 20:15:36 -0000
Subject: [New-bugs-announce] [issue1132] compile error in poplib.py
Message-ID: <1189282536.64.0.420049245875.issue1132@psf.upfronthosting.co.za>
New submission from Andr?:
File "c:\Python30\lib\poplib.py", line 137, in _getlongresp
while line != '.':
TypeError: can't compare bytes and str
----------
components: Library (Lib)
messages: 55753
nosy: andre
severity: normal
status: open
title: compile error in poplib.py
type: compile error
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1132>
__________________________________
From report at bugs.python.org Sun Sep 9 02:18:18 2007
From: report at bugs.python.org (Viktor Ferenczi)
Date: Sun, 09 Sep 2007 00:18:18 -0000
Subject: [New-bugs-announce] [issue1133] python3.0-config raises SyntaxError
Message-ID: <1189297098.34.0.426039385433.issue1133@psf.upfronthosting.co.za>
New submission from Viktor Ferenczi:
Running python3.0-config raises SyntaxError:
$ python3.0-config
File "/usr/local/bin/python3.0-config", line 33
print sysconfig.PREFIX
^
SyntaxError: invalid syntax
OS: Ununtu Feisty, up-to-date
Python: Python 3.0a1, compiled from source,
configured with: --prefix=/usr/local
----------
components: Demos and Tools, Installation
messages: 55757
nosy: complex
severity: normal
status: open
title: python3.0-config raises SyntaxError
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1133>
__________________________________
From report at bugs.python.org Sun Sep 9 02:35:45 2007
From: report at bugs.python.org (Viktor Ferenczi)
Date: Sun, 09 Sep 2007 00:35:45 -0000
Subject: [New-bugs-announce] [issue1134] Parsing a simple script eats all of
your memory
Message-ID: <1189298145.63.0.146267500715.issue1134@psf.upfronthosting.co.za>
New submission from Viktor Ferenczi:
Read the WARNING below, then run the attached script with Python3.0a2.
It will eat all of your memory.
WARNING: Keep a process killing tool or an extra command line at your
fingertips, since this script could render your machine unusable in
about 10-20 seconds depending on your memory and CPU speed!!! YOU ARE
WARNED!
OS: Ubuntu Feisty, up-to-date
Python: Python3.0a1, built from sources,
configured with: --prefix=/usr/local
----------
components: Interpreter Core
files: hungry_script.py
messages: 55758
nosy: complex
severity: critical
status: open
title: Parsing a simple script eats all of your memory
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1134>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hungry_script.py
Type: text/x-python
Size: 179 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070909/5fdd290a/attachment.py
From report at bugs.python.org Sun Sep 9 07:07:26 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=)
Date: Sun, 09 Sep 2007 05:07:26 -0000
Subject: [New-bugs-announce] [issue1135] xview/yview of Tix.Grid is broken
Message-ID: <1189314445.29.0.484479560219.issue1135@psf.upfronthosting.co.za>
New submission from
Hirokazu Yamamoto
:
Attached code "test_tixGrid.py" fails with following error message.
TypeError: yview() takes exactly 1 argument (4 given)
----------
components: Tkinter
files: test_tixGrid.py
messages: 55762
nosy: ocean-city
severity: normal
status: open
title: xview/yview of Tix.Grid is broken
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1135>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_tixGrid.py
Type: text/x-python
Size: 907 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070909/f8ce3c60/attachment.py
From report at bugs.python.org Sun Sep 9 17:09:59 2007
From: report at bugs.python.org (=?utf-8?q?Cristina_Yenyxe_Gonz=C3=A1lez_Garc=C3=ADa?=)
Date: Sun, 09 Sep 2007 15:09:59 -0000
Subject: [New-bugs-announce] [issue1136] Bdb documentation
Message-ID: <1189350598.74.0.444116788582.issue1136@psf.upfronthosting.co.za>
New submission from Cristina Yenyxe Gonz?lez Garc?a:
Hello,
I thought it could be interesting to write some documentation for the
bdb module, since it keeps undocumented on Python 2.6 and 3.0. The
document I attach is written in reStructuredText, and for using it with
2.5 it only needs to change the header for the 'Bdb.user_exception'
method (and convert to LaTeX format, of course).
It will thank a revision because there can be some grammatical errors
(I'm from Spain). Anyway, I hope it helps, and any comment will be
welcomed :D
----------
components: Documentation
files: bdb.rst
messages: 55766
nosy: arklad
severity: normal
status: open
title: Bdb documentation
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1136>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdb.rst
Type: application/octet-stream
Size: 10839 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070909/9f4b19b2/attachment.obj
From report at bugs.python.org Sun Sep 9 18:40:11 2007
From: report at bugs.python.org (Achim Gaedke)
Date: Sun, 09 Sep 2007 16:40:11 -0000
Subject: [New-bugs-announce] [issue1137] pyexpat patch for changing
buffer_size
Message-ID: <1189356011.84.0.968400197849.issue1137@psf.upfronthosting.co.za>
New submission from Achim Gaedke:
Hello!
Sometimes people have big amounts of text/data in xml files. To make
processing more effective, they should be able to change the buffer size
for collecting character data in one string.
Here comes a patch that applies necessary changes in setattr method. It
handles reallocation sufficiently efficient without introducing extra
variables to the parser class.
Also a documentation patch and some test cases are available.
These patches and tests were done with debian etch python2.5, which is
python-2.5.1 . This patch also works on python2.4 .
----------
components: XML
files: pyexpat_c_patch
messages: 55767
nosy: AchimGaedke
severity: normal
status: open
title: pyexpat patch for changing buffer_size
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1137>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pyexpat_c_patch
Type: application/octet-stream
Size: 2544 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070909/b99c513a/attachment.obj
From report at bugs.python.org Mon Sep 10 01:20:00 2007
From: report at bugs.python.org (Collin Winter)
Date: Sun, 09 Sep 2007 23:20:00 -0000
Subject: [New-bugs-announce] [issue1138] Fixer needed for __future__ imports
Message-ID: <1189379999.94.0.155888611794.issue1138@psf.upfronthosting.co.za>
New submission from Collin Winter:
Per
http://mail.python.org/pipermail/python-3000/2007-September/010337.html,
2to3 should strip out __future__ imports. This should probably be added
to the existing import fixer.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 55769
nosy: collinwinter
priority: normal
severity: normal
status: open
title: Fixer needed for __future__ imports
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1138>
__________________________________
From report at bugs.python.org Mon Sep 10 05:27:17 2007
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 10 Sep 2007 03:27:17 -0000
Subject: [New-bugs-announce] [issue1139] PyFile_Encoding should be
PyFile_SetEncoding
Message-ID: <1189394836.73.0.483102180723.issue1139@psf.upfronthosting.co.za>
New submission from Gabriel Genellina:
Describing the PyFile C API, there is a typo:
PyFile_Encoding function does not exist,
should say PyFile_SetEncoding instead.
(This goes down to version 2.3 when the
function was initially added).
http://docs.python.org/dev/c-api/
concrete.html#PyFile_Encoding
----------
components: Documentation
messages: 55774
nosy: gagenellina
severity: normal
status: open
title: PyFile_Encoding should be PyFile_SetEncoding
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1139>
__________________________________
From report at bugs.python.org Mon Sep 10 08:37:19 2007
From: report at bugs.python.org (Beda Kosata)
Date: Mon, 10 Sep 2007 06:37:19 -0000
Subject: [New-bugs-announce] [issue1140] re.sub returns str when processing
empty unicode string
Message-ID: <1189406238.99.0.778554736734.issue1140@psf.upfronthosting.co.za>
New submission from Beda Kosata:
While re.sub normally returns unicode strings when processing unicode,
it returns a normal string when dealing with an empty unicode string.
Example:
>>> print type( re.sub( "XX", "", u""))
<type 'str'>
>>> print type( re.sub( "XX", "", u"A"))
<type 'unicode'>
This inconsistency could lead to annoying bugs (at least it did for me :)
----------
components: Regular Expressions
messages: 55775
nosy: beda
severity: minor
status: open
title: re.sub returns str when processing empty unicode string
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1140>
__________________________________
From report at bugs.python.org Mon Sep 10 14:45:04 2007
From: report at bugs.python.org (christen)
Date: Mon, 10 Sep 2007 12:45:04 -0000
Subject: [New-bugs-announce] [issue1141] reading large files
Message-ID: <1189428303.96.0.66125933613.issue1141@psf.upfronthosting.co.za>
New submission from christen:
September 11, 2007 I downloaded py 3.k
The good news :
Under Windows, Python 3k properly reads files larger than 4 Go (in
contrast to python 2.5 that skips some lines, see below)
The bad news : py 3k is very slow compared to py 2.5; see the results below
the code is
it reads a 4.9 Go file of 81,017,719 lines (a genbank entry of bacterial
sequences)
#######################
import time
print (time.localtime())
fichin=open(r'D:\pythons\16s\total_gb_161_16S.gb')
t0= time.localtime()
print (t0)
i=0
for li in fichin:
i+=1
if i%1000000==0:
print (i,time.localtime())
fichin.close()
print ()
print (i)
print (time.localtime())
#########################
I got the following results (Windows XP 64) on the same machine, using
either py 3k or py 2.5
As soon as my BSD and Linux machines are done with calculations, I will
try that on them.
Best
Richard Christen
python 3k
(2007, 9, 10, 13, 53, 36, 0, 253, 1)
(2007, 9, 10, 13, 53, 36, 0, 253, 1)
1000000 (2007, 9, 10, 13, 53, 49, 0, 253, 1)
2000000 (2007, 9, 10, 13, 54, 3, 0, 253, 1)
3000000 (2007, 9, 10, 13, 54, 18, 0, 253, 1)
4000000 (2007, 9, 10, 13, 54, 32, 0, 253, 1)
5000000 (2007, 9, 10, 13, 54, 47, 0, 253, 1)
....
77000000 (2007, 9, 10, 14, 14, 55, 0, 253, 1)
78000000 (2007, 9, 10, 14, 15, 9, 0, 253, 1)
79000000 (2007, 9, 10, 14, 15, 22, 0, 253, 1)
80000000 (2007, 9, 10, 14, 15, 36, 0, 253, 1)
81000000 (2007, 9, 10, 14, 15, 49, 0, 253, 1)
81017719 #this is the proper number of lines
(2007, 9, 10, 14, 15, 50, 0, 253, 1)
Python 2.5
(2007, 9, 10, 14, 18, 33, 0, 253, 1)
(2007, 9, 10, 14, 18, 33, 0, 253, 1)
(1000000, (2007, 9, 10, 14, 18, 34, 0, 253, 1))
(2000000, (2007, 9, 10, 14, 18, 34, 0, 253, 1))
(3000000, (2007, 9, 10, 14, 18, 35, 0, 253, 1))
(4000000, (2007, 9, 10, 14, 18, 35, 0, 253, 1))
(5000000, (2007, 9, 10, 14, 18, 36, 0, 253, 1))
...
(77000000, (2007, 9, 10, 14, 19, 10, 0, 253, 1))
(78000000, (2007, 9, 10, 14, 19, 11, 0, 253, 1))
(79000000, (2007, 9, 10, 14, 19, 11, 0, 253, 1))
(80000000, (2007, 9, 10, 14, 19, 12, 0, 253, 1))
(81000000, (2007, 9, 10, 14, 19, 12, 0, 253, 1))
()
81014962 #python 2.5 missed some lines !!!!
(2007, 9, 10, 14, 19, 12, 0, 253, 1)
----------
components: Tests
messages: 55777
nosy: Richard.Christen at unice.fr
severity: normal
status: open
title: reading large files
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1141>
__________________________________
From report at bugs.python.org Mon Sep 10 17:52:42 2007
From: report at bugs.python.org (christen)
Date: Mon, 10 Sep 2007 15:52:42 -0000
Subject: [New-bugs-announce] [issue1142] code sample showing errors reading
large files with py 2.5
Message-ID: <1189439562.54.0.204300359031.issue1142@psf.upfronthosting.co.za>
New submission from christen:
Error in reading >4Go files under windows
try this:
import sys
print(sys.version_info)
import time
print (time.strftime('%Y-%m-%d %H:%M:%S'))
liste=[]
start = time.time()
fichout=open('test.txt','w')
for i in xrange(85014961):
if i%5000000==0 and i>0:
print (i,time.time()-start)
fichout.write(str(i)+' '*59+'\n')
fichout.close()
print ('total lines written ',i)
print (i,time.time()-start)
print ('*'*50)
fichin=open('test.txt')
start3 = time.time()
for i,li in enumerate(fichin):
if i%5000000==0 and i>0:
print (i,time.time()-start3)
fichin.close()
print ('total lines read ',i)
print(time.time()-start)
it generates a >4Go file,not all lines are read !!
example:
('total lines written ', 85014960)
('total lines read ', 85014950)
10 lines are missing
if you replace by
fichout.write(str(i)+' '*59+'\n')
file is now under 4Go, is properly read
Used both a 32 and 64 Windows XP machines
seems to work with Linux and BSD (did not tried this example but had no
pb with my home made big files)
Pb : many examples of >4Go files for the human genome and other
biological applications. Almost sure that people are doing mistakes,
because it took me a while before discovering that...
Note : does not happen with py 3k :-)
----------
components: Windows
messages: 55785
nosy: Richard.Christen at unice.fr
severity: urgent
status: open
title: code sample showing errors reading large files with py 2.5
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1142>
__________________________________
From report at bugs.python.org Tue Sep 11 08:13:15 2007
From: report at bugs.python.org (Fredrik Lundh)
Date: Tue, 11 Sep 2007 06:13:15 -0000
Subject: [New-bugs-announce] [issue1143] Updated to latest ElementTree in 2.6
Message-ID: <1189491195.66.0.621818063137.issue1143@psf.upfronthosting.co.za>
New submission from Fredrik Lundh:
The xml.etree package should be updated to ElementTree 1.3/cElementTree
1.0.6 (or later).
----------
assignee: effbot
components: XML
messages: 55811
nosy: effbot
priority: normal
severity: minor
status: open
title: Updated to latest ElementTree in 2.6
type: rfe
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1143>
__________________________________
From report at bugs.python.org Tue Sep 11 13:05:31 2007
From: report at bugs.python.org (David Binger)
Date: Tue, 11 Sep 2007 11:05:31 -0000
Subject: [New-bugs-announce] [issue1144] parsermodule validation out of sync
with Grammar
Message-ID: <1189508731.28.0.0196002397645.issue1144@psf.upfronthosting.co.za>
New submission from David Binger:
>>> parser.sequence2st(parser.suite("class A(object): pass").tolist())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
parser.ParserError: Expected node type 326, got 329.
---
The Grammar in python 3 uses "arglist" instead of "testlist"
for class definitions. The parsermodule's validate_class()
calls validate_testlist() where it should now be calling
validate_arglist().
----------
components: Library (Lib)
messages: 55818
nosy: dbinger
severity: normal
status: open
title: parsermodule validation out of sync with Grammar
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1144>
__________________________________
From report at bugs.python.org Tue Sep 11 13:41:15 2007
From: report at bugs.python.org (Thomas Lee)
Date: Tue, 11 Sep 2007 11:41:15 -0000
Subject: [New-bugs-announce] [issue1145] Allow str.join to join non-string
types (as per PEP 3100)
Message-ID: <1189510875.27.0.109757226088.issue1145@psf.upfronthosting.co.za>
New submission from Thomas Lee:
The current implementation of str.join requires that the parameters
passed to it be string/unicode values. A suggestion to allow it to
accept parameters of any type came up in PEP 3100. Implemented for
Unicode using the attached patch.
It would be trivial to add this functionality to the old string object
too, but I haven't been following the string to unicode discussion too
closely and I'm unsure if the old string object will remain for too much
longer.
----------
components: Interpreter Core
files: join-autostr.patch
messages: 55820
nosy: thomas.lee
severity: minor
status: open
title: Allow str.join to join non-string types (as per PEP 3100)
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1145>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: join-autostr.patch
Type: text/x-patch
Size: 4684 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070911/ee4515ef/attachment.bin
From report at bugs.python.org Tue Sep 11 15:37:37 2007
From: report at bugs.python.org (sam)
Date: Tue, 11 Sep 2007 13:37:37 -0000
Subject: [New-bugs-announce] [issue1146] TextWrap vs words 1-character
shorter than the width
Message-ID: <1189517857.01.0.116632649875.issue1146@psf.upfronthosting.co.za>
New submission from sam:
>>> from textwrap import wrap
>>> wrap("foobarbaz reallylongwordgoeshere", width = 10)
['foobarbaz r', 'eallylongw', 'ordgoesher', 'e']
>>> print [len(s) for s in _]
[11, 10, 10, 1]
This only seems to happen when the first word on the line is exactly one
character shorter than the width, and the next word is too long to fit,
so it is broken:
>>> wrap("foo bar reallylongwordgoeshere", width = 7)
['foo bar', 'reallyl', 'ongword', 'goesher', 'e']
>>> wrap("foobarbaz really longwordgoeshere", width = 10)
['foobarbaz', 'really lon', 'gwordgoesh', 'ere']
>>> wrap("foobarbaz reallylongwordgoeshere", width = 10,
break_long_words = False)
['foobarbaz', 'reallylongwordgoeshere']
This is on Python 2.5, on Windows XP SP2.
----------
messages: 55822
nosy: sam
severity: normal
status: open
title: TextWrap vs words 1-character shorter than the width
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1146>
__________________________________
From report at bugs.python.org Tue Sep 11 17:16:35 2007
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 11 Sep 2007 15:16:35 -0000
Subject: [New-bugs-announce] [issue1147] string exceptions inconsistently
deprecated/disabled
Message-ID: <1189523795.09.0.87571084132.issue1147@psf.upfronthosting.co.za>
New submission from Jean-Paul Calderone:
Python 2.5 deprecated raising string exceptions. It also added the
throw method to generator objects which can be used to raise an
exception, including a string exception. Raising an exception with this
method doesn't issue a deprecation warning.
It looks like Python 2.6 will remove string exceptions entirely.
Current trunk still allows strings to be passed to the throw method of
generators though, and raises the string exception, again without a
deprecation warning.
----------
components: Interpreter Core
messages: 55825
nosy: exarkun
severity: normal
status: open
title: string exceptions inconsistently deprecated/disabled
type: behavior
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1147>
__________________________________
From report at bugs.python.org Tue Sep 11 19:26:25 2007
From: report at bugs.python.org (Eduardo Padoan)
Date: Tue, 11 Sep 2007 17:26:25 -0000
Subject: [New-bugs-announce] [issue1148] TypeError on join - httplib mixing
str and bytes
Message-ID: <1189531585.2.0.192204697498.issue1148@psf.upfronthosting.co.za>
New submission from Eduardo Padoan:
To reproduce:
>>> import httplib
>>> conn = httplib.HTTPConnection("www.python.org")
>>> conn.request("GET", "/index.html")
>>> r1 = conn.getresponse()
>>> r1.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/eopadoan/pub/py3k/Lib/httplib.py", line 540, in read
s = self._safe_read(self.length)
File "/home/eopadoan/pub/py3k/Lib/httplib.py", line 627, in _safe_read
return "".join(s)
TypeError: sequence item 0: expected string or Unicode, bytes found
Also, shouldn't the message be like "...expected str, bytes found"?
----------
components: Library (Lib)
messages: 55827
nosy: eopadoan
severity: normal
status: open
title: TypeError on join - httplib mixing str and bytes
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1148>
__________________________________
From report at bugs.python.org Tue Sep 11 20:03:46 2007
From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Pedro_Coelho?=)
Date: Tue, 11 Sep 2007 18:03:46 -0000
Subject: [New-bugs-announce] [issue1149] fdopen does not work as expected
Message-ID: <1189533826.38.0.958954232674.issue1149@psf.upfronthosting.co.za>
New submission from Lu?s Pedro Coelho:
from os import *
def Fork():
b = fork()
if b < 0:
raise Exception('fork() failed')
return b
r,w=pipe()
b = Fork()
if b == 0:
dup2(w,1)
close(w)
execlp('echo',\
'echo',\
'Hello world')
else:
for line in fdopen(r):
print 'Read %s' % line
I was expecting this code to print "Read Hello World". Instead, it
hangs forever.
Changing "for line in fdopen(r): print 'Read %s' % line"
to "line=read(r,100); print 'Read %s' % line" makes the program work
as expected. This is what I did on my actual production code, but it
seems funny behaviour on the part of fdopen.
I am running on Ubuntu on PowerPC.
----------
components: Library (Lib)
messages: 55829
nosy: luis at luispedro.org
severity: normal
status: open
title: fdopen does not work as expected
type: behavior
versions: Python 2.3, Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1149>
__________________________________
From report at bugs.python.org Tue Sep 11 20:23:03 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Sep 2007 18:23:03 -0000
Subject: [New-bugs-announce] [issue1150] Rename PyBUF_WRITEABLE to
PyBUF_WRITABLE
Message-ID: <1189534983.38.0.207085295331.issue1150@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
Because writeable is not an English word; writable is.
Other names should be fixed as well.
----------
messages: 55830
nosy: gvanrossum
severity: normal
status: open
title: Rename PyBUF_WRITEABLE to PyBUF_WRITABLE
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1150>
__________________________________
From report at bugs.python.org Tue Sep 11 21:26:07 2007
From: report at bugs.python.org (Eduardo Padoan)
Date: Tue, 11 Sep 2007 19:26:07 -0000
Subject: [New-bugs-announce] [issue1151] "TypeError: expected string,
bytes found" instead of KeyboardInterrupt
Message-ID: <1189538767.56.0.704624756031.issue1151@psf.upfronthosting.co.za>
New submission from Eduardo Padoan:
On revision 54803, interactive mode, on linux: if type ctrl+c you type
ctrl+c, it should raise KeyboardInterrupt, but "TypeError: expected
string, bytes found" printed. Also, I could *not* catch it doing:
>>> try:
... while True: pass
... except KeyboardInterrupt:
... print('Ok')
... except TypeError:
... print('Ops')
Ok
To reproduce:
>>> # press ctrl+c...
TypeError: expected string, bytes found
>>>
It seems that it is simply printing the wrong error...
----------
components: Interpreter Core
messages: 55833
nosy: eopadoan
severity: normal
status: open
title: "TypeError: expected string, bytes found" instead of KeyboardInterrupt
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1151>
__________________________________
From report at bugs.python.org Wed Sep 12 07:21:36 2007
From: report at bugs.python.org (Frank Millman)
Date: Wed, 12 Sep 2007 05:21:36 -0000
Subject: [New-bugs-announce] [issue1152] Bug in documentation for
SimpleXMLRPCServer
Message-ID: <1189574496.01.0.0600340666373.issue1152@psf.upfronthosting.co.za>
New submission from Frank Millman:
I spotted a minor bug in the documentation to SimpleXMLRPCServer.
Background:
xmlrpclib.py has the following -
# This class is available as ServerProxy and Server. New code
should
# use ServerProxy, to avoid confusion.
#
...
class ServerProxy:
...
Server = ServerProxy
The bug:
Section 18.25.1 SimpleXMLRPCServer Objects
...
Example:
...
The following client code will call the methods made available by
the preceding server:
import xmlrpclib
s = xmlrpclib.Server('http://localhost:8000')
It should say:
s = xmlrpclib.ServerProxy('http://localhost:8000')
----------
components: Documentation
messages: 55836
nosy: FrankMillman
severity: normal
status: open
title: Bug in documentation for SimpleXMLRPCServer
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152>
__________________________________
From report at bugs.python.org Wed Sep 12 12:46:54 2007
From: report at bugs.python.org (Marcin 'Qrczak' Kowalczyk)
Date: Wed, 12 Sep 2007 10:46:54 -0000
Subject: [New-bugs-announce] [issue1153] help(pickle) fails: unorderable
types: type() < type()
Message-ID: <1189594014.38.0.661760959724.issue1153@psf.upfronthosting.co.za>
New submission from Marcin 'Qrczak' Kowalczyk:
Python 3.0a1 (py3k, Sep 8 2007, 15:57:56)
[GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> help(pickle)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.0/site.py", line 350, in __call__
return pydoc.help(*args, **kwds)
File "/usr/local/lib/python3.0/pydoc.py", line 1685, in __call__
self.help(request)
File "/usr/local/lib/python3.0/pydoc.py", line 1729, in help
else: doc(request, 'Help on %s:')
File "/usr/local/lib/python3.0/pydoc.py", line 1512, in doc
pager(render_doc(thing, title, forceload))
File "/usr/local/lib/python3.0/pydoc.py", line 1490, in render_doc
return title % desc + '\n\n' + text.document(object, name)
File "/usr/local/lib/python3.0/pydoc.py", line 319, in document
if inspect.ismodule(object): return self.docmodule(*args)
File "/usr/local/lib/python3.0/pydoc.py", line 1076, in docmodule
contents.append(self.document(value, key, name))
File "/usr/local/lib/python3.0/pydoc.py", line 320, in document
if inspect.isclass(object): return self.docclass(*args)
File "/usr/local/lib/python3.0/pydoc.py", line 1210, in docclass
lambda t: t[1] == 'data')
File "/usr/local/lib/python3.0/pydoc.py", line 1173, in spilldata
name, mod, maxlen=70, doc=doc) + '\n')
File "/usr/local/lib/python3.0/pydoc.py", line 1295, in docother
repr = self.repr(object)
File "/usr/local/lib/python3.0/repr.py", line 24, in repr
return self.repr1(x, self.maxlevel)
File "/usr/local/lib/python3.0/pydoc.py", line 954, in repr1
return getattr(self, methodname)(x, level)
File "/usr/local/lib/python3.0/repr.py", line 78, in repr_dict
for key in islice(sorted(x), self.maxdict):
TypeError: unorderable types: type() < type()
>>>
----------
components: Library (Lib)
messages: 55839
nosy: Qrczak
severity: normal
status: open
title: help(pickle) fails: unorderable types: type() < type()
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1153>
__________________________________
From report at bugs.python.org Wed Sep 12 18:28:40 2007
From: report at bugs.python.org (hhas)
Date: Wed, 12 Sep 2007 16:28:40 -0000
Subject: [New-bugs-announce] [issue1154] Carbon.CF memory leak
Message-ID: <1189614520.84.0.350968879835.issue1154@psf.upfronthosting.co.za>
New submission from hhas:
CFStringRefObj_Convert leaks memory when passed a str. See attached diff
file for patch.
----------
components: Macintosh
files: CFmodule.diff
messages: 55843
nosy: hhas
severity: normal
status: open
title: Carbon.CF memory leak
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1154>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CFmodule.diff
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070912/4ebd686e/attachment.txt
From report at bugs.python.org Wed Sep 12 19:25:51 2007
From: report at bugs.python.org (hhas)
Date: Wed, 12 Sep 2007 17:25:51 -0000
Subject: [New-bugs-announce] [issue1155] Carbon.CF memory management problem
Message-ID: <1189617951.85.0.870438592148.issue1155@psf.upfronthosting.co.za>
New submission from hhas:
While other CF...RefObj_Convert functions return a borrowed object,
CFStringRefObj_Convert will return either a new or borrowed CFStringRef
depending on the type of value supplied (str, unicode or CFString). As a
result, extensions that use CFStringRefObj_Convert function to (e.g.)
parse arguments - for example, Carbon.Launch
(Launch_LSGetApplicationForInfo, Launch_LSFindApplicationForInfo) - will
leak memory when a str or unicode value is passed.
Three possible solutions:
1. Make all CF...RefObj_Convert functions return a 'new' object (i.e.
call CFRetain if returning an existing CF object) and make callers
responsible for always calling CFRelease on these objects when done.
2. Make CFStringRefObj_Convert accept Carbon.CF.CFStringRef values only,
and make users responsible for calling Carbon.CF.toCF on Python
str/unicode values before passing them to extension functions.
3. Make no changes to existing code, but advise Python users to call
Carbon.CF.toCF themselves before passing text values to extension
functions whose docstrings specify CFStringRef parameters if they wish
to avoid memory leaks.
The third solution would be the obvious choice if future Python
development plans call for the deprecation and eventual removal of
Carbon.CF. If Carbon.CF is to retained in the long term, however, then
some sort of fix would be preferable.
While the other two solutions would inevitable cause some disruption, I
would suggest #1 is the lesser evil as it would require only existing
standard and 3rd-party C extensions to be modified, whereas #2 would
require existing Python code to be modified which would affect end-users
as well.
Note that if solution #1 is used, callers would need to avoid invoking
CFRelease when an older, unfixed version of Carbon.CF is in use as this
would cause a memory error. This shouldn't cause a problem if the fix is
made in a major Python release (whose extensions are incompatible with
earlier versions, and vice-versa). pymactoolbox.h could supply a
suitable macro, e.g.:
#define CarbonCFRelease(v) if (v != NULL) CFRelease(v);
which client code could invoke as:
#ifdef CarbonCFRelease
CarbonCFRelease(someRef);
CarbonCFRelease(anotherRef);
#endif
Unpatched extensions would continue to leak (more) memory, of course,
but there should be no other ill effects.
----------
components: Macintosh
messages: 55846
nosy: hhas
severity: normal
status: open
title: Carbon.CF memory management problem
type: resource usage
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1155>
__________________________________
From report at bugs.python.org Wed Sep 12 20:23:15 2007
From: report at bugs.python.org (Johann Tonsing)
Date: Wed, 12 Sep 2007 18:23:15 -0000
Subject: [New-bugs-announce] [issue1156] Suggested change to _exit function
description in os module documentation
Message-ID: <1189621394.95.0.799707623344.issue1156@psf.upfronthosting.co.za>
New submission from Johann Tonsing:
The document from which http://docs.python.org/lib/os-process.html was
generated contains:
"Note: The standard way to exit is sys.exit(n). _exit() should normally
only be used in the child process after a fork()."
Should "child" be replaced with "parent"?
This also applies to: http://docs.python.org/dev/library/os.html
Did not check the 3.0 docs (where can they be found?).
----------
components: Documentation
messages: 55853
nosy: jtonsing
severity: normal
status: open
title: Suggested change to _exit function description in os module documentation
type: behavior
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1156>
__________________________________
From report at bugs.python.org Wed Sep 12 23:01:35 2007
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Sep 2007 21:01:35 -0000
Subject: [New-bugs-announce] [issue1157] test_urllib2net fails on test_ftp
Message-ID: <1189630894.93.0.494420700317.issue1157@psf.upfronthosting.co.za>
New submission from Guido van Rossum:
======================================================================
ERROR: test_ftp (__main__.OtherNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "Lib/test/test_urllib2net.py", line 173, in test_ftp
self._test_urls(urls, self._extra_handlers())
File "Lib/test/test_urllib2net.py", line 242, in _test_urls
f = urllib2.urlopen(url, req)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
122, in urlopen
return _opener.open(url, data, timeout)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
378, in open
response = self._open(req, data)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
396, in _open
'_open', req)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
356, in _call_chain
result = func(*args)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
1271, in ftp_open
fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib2.py", line
1316, in connect_ftp
self.cache[key] = ftpwrapper(user, passwd, host, port, dirs, timeout)
File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line
783, in __init__
self.init()
File "/usr/local/google/home/guido/python/py3k/Lib/urllib.py", line
790, in init
self.ftp.login(self.user, self.passwd)
File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
372, in login
if resp[0] == '3': resp = self.sendcmd('PASS ' + passwd)
File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
242, in sendcmd
return self.getresp()
File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
208, in getresp
resp = self.getmultiline()
File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
198, in getmultiline
nextline = self.getline()
File "/usr/local/google/home/guido/python/py3k/Lib/ftplib.py", line
181, in getline
line = self.file.readline()
File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1319,
in readline
readahead, pending = self._read_chunk()
File "/usr/local/google/home/guido/python/py3k/Lib/io.py", line 1123,
in _read_chunk
pending = self._decoder.decode(readahead, not readahead)
File
"/usr/local/google/home/guido/python/py3k/Lib/encodings/ascii.py", line
26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 47:
ordinal not in range(128)
----------
messages: 55873
nosy: gvanrossum
severity: normal
status: open
title: test_urllib2net fails on test_ftp
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1157>
__________________________________
From report at bugs.python.org Thu Sep 13 04:26:44 2007
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Sep 2007 02:26:44 -0000
Subject: [New-bugs-announce] [issue1158] %f format for datetime objects
Message-ID: <1189650403.5.0.731044089134.issue1158@psf.upfronthosting.co.za>
New submission from Skip Montanaro:
Attached is a patch for py3k which adds a %f format code to its strftime
method. When included in a format string it expands to the number of
microseconds in the object. date, time and datetime objects all support
the format (though I'm not sure what, if anything, it means for date
objects).
I don't know how practical this is for time.strftime() level because the
inputs are all so excited about being ints. Still, if you wanted to
allow the seconds field to be a float and were willing to cast it to an
int where necessary and shadow struct tm with a pseudo-float-friendly
version of the same, you could probably smash it in there as well.
----------
components: Extension Modules
files: percent-f.diff
keywords: patch, py3k
messages: 55876
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: %f format for datetime objects
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1158>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: percent-f.diff
Type: text/x-diff
Size: 2351 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070913/f31a009c/attachment.diff
From report at bugs.python.org Thu Sep 13 09:22:07 2007
From: report at bugs.python.org (Robert Ancell)
Date: Thu, 13 Sep 2007 07:22:07 -0000
Subject: [New-bugs-announce] [issue1159] os.getenv() not updated after
external module uses C putenv()
Message-ID: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za>
New submission from Robert Ancell:
The Python os.getenv() function accesses an Python dictionary which is
mirroring the process environment. This dictionary is populated when the
interpreter starts and updated when os.environ.__setitem__() or
os.putenv() are called. However if the python program imports an
extension module that uses the system putenv() then the changes cannot
be accessed using the Python standard library.
This has been a problem for us as we have created Python bindings to an
existing C based library that modifies the environment dynamically (not
the best design decision...). The workaround we are using is to create
our own wrapper to the system (Solaris/Linux) getenv().
A potential solution could be to make environ a class where
os.environ.__setitem__() calls putenv(), os.environ.__getitem__() calls
getenv() and os.environ.keys()/items()/iter*() uses **environ (or other
appropriate system call). This does however have undefined issues on how
the environment behaves on various systems (memory leaks etc).
----------
components: Library (Lib)
messages: 55881
nosy: robert.ancell
severity: normal
status: open
title: os.getenv() not updated after external module uses C putenv()
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1159>
__________________________________
From report at bugs.python.org Thu Sep 13 10:00:57 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Guido_Ostkamp=0A=09=09=09=09?=)
Date: Thu, 13 Sep 2007 08:00:57 -0000
Subject: [New-bugs-announce] [issue1160] Medium size regexp crashes python
Message-ID: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
New submission from
Guido Ostkamp
:
Hello,
a medium size regular expression crashes Python 2.5.1 as follows:
Traceback (most recent call last):
File "./regtest.py", line 14, in <module>
m = rematch(pats)
File "./regtest.py", line 12, in rematch
return re.compile(pat).match
File "/export/home/ostkamp/local/lib/python2.5/re.py", line 180, in
compile
return _compile(pattern, flags)
File "/export/home/ostkamp/local/lib/python2.5/re.py", line 231, in
_compile
p = sre_compile.compile(pattern, flags)
File "/export/home/ostkamp/local/lib/python2.5/sre_compile.py", line
530, in compile
groupindex, indexgroup
OverflowError: regular expression code size limit exceeded
This is apparently caused by some code in Modules/_sre.c and
Modules/sre.h as follows:
self->code[i] = (SRE_CODE) value;
if ((unsigned long) self->code[i] != value) {
PyErr_SetString(PyExc_OverflowError,
"regular expression code size limit exceeded");
break;
}
An 'unsigned int' value is unnecessarily squeezed into an 'unsigned
short' field defined in sre.h:
#ifdef Py_UNICODE_WIDE
#define SRE_CODE Py_UCS4
#else
#define SRE_CODE unsigned short
#endif
On all systems I'm working on (SuSE Linux SLES 9, Solaris 8 etc.) the
else case of the ifdef applies which chooses 'unsigned short'.
I don't understand the relationship between 'unicode' and what is
apparently the size of the regular expression stack here.
Some experiments have shown that changing the 'unsigned short' to
'unsigned long' and rebuilding Python fixes the problem.
Here is a test program to reproduce the error:
#!/usr/bin/env python
import re, random, sys
def randhexstring():
return "".join(["%04x" % random.randint(0, 0xffff) for x in range(20)])
pats = [randhexstring() for x in range(1000)]
def rematch(pats):
pat = '(?:%s)' % '|'.join(pats)
return re.compile(pat).match
m = rematch(pats)
count = 0
for s in pats * 100:
if m(s):
count += 1
print count
Regards
Guido
----------
components: Regular Expressions
messages: 55885
nosy: ostkamp
severity: normal
status: open
title: Medium size regexp crashes python
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
__________________________________
From report at bugs.python.org Thu Sep 13 14:23:09 2007
From: report at bugs.python.org (Eduardo Padoan)
Date: Thu, 13 Sep 2007 12:23:09 -0000
Subject: [New-bugs-announce] [issue1161] Mangled chars in offending line of
SyntaxError traceback
Message-ID: <1189686189.66.0.054498459486.issue1161@psf.upfronthosting.co.za>
New submission from Eduardo Padoan:
Python 3.0a1 (py3k:58103, Sep 11 2007, 13:52:21)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> asd asd
File "<stdin>", line 1
P??
^
SyntaxError: invalid syntax
----------
components: Interpreter Core
messages: 55888
nosy: eopadoan
severity: normal
status: open
title: Mangled chars in offending line of SyntaxError traceback
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1161>
__________________________________
From report at bugs.python.org Thu Sep 13 16:35:43 2007
From: report at bugs.python.org (Swaroop)
Date: Thu, 13 Sep 2007 14:35:43 -0000
Subject: [New-bugs-announce] [issue1162] Python doesn't compile on Microsoft
Visual Studio 2008 "Orcas" Beta 2
Message-ID: <1189694143.62.0.229303741197.issue1162@psf.upfronthosting.co.za>
New submission from Swaroop:
I followed the README build instructions for VS2005. I opened
pcbuild.sln in PCbuild8 directory and tried building, and I get the
following errors:
<start of errors>
Warning 1 Command line warning D9035 : option 'Wp64' has been deprecated
and will be removed in a future release cl make_buildinfo
Warning 2 Command line warning D9035 : option 'Wp64' has been deprecated
and will be removed in a future release cl make_versioninfo
Warning 3 warning C4005: 'WRITE_RESTRICTED' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127
pythoncore
Warning 4 warning C4005: 'WRITE_RESTRICTED' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127
pythoncore
Warning 5 warning C4133: 'function' : incompatible types - from
'_typeobject *' to 'PyObject *'
c:\all\code\python-svn\modules\_collectionsmodule.c 1113 pythoncore
Warning 6 warning C4005: 'WRITE_RESTRICTED' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127
pythoncore
Warning 7 warning C4018: '>' : signed/unsigned mismatch
c:\all\code\python-svn\modules\mmapmodule.c 693 pythoncore
Warning 8 warning C4018: '>' : signed/unsigned mismatch
c:\all\code\python-svn\modules\mmapmodule.c 834 pythoncore
Error 9 fatal error C1083: Cannot open include file: 'db.h': No such
file or directory c:\all\code\python-svn\modules\_bsddb.c 90 _bsddb
Warning 10 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification _testcapimodule.obj _testcapi
Warning 11 warning C4005: 'WRITE_RESTRICTED' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _socket
Error 12 error C2373: 'inet_pton' : redefinition; different type
modifiers c:\all\code\python-svn\modules\socketmodule.c 300 _socket
Error 13 error C2373: 'inet_ntop' : redefinition; different type
modifiers c:\all\code\python-svn\modules\socketmodule.c 301 _socket
Error 14 error C2373: 'inet_pton' : redefinition; different type
modifiers c:\all\code\python-svn\modules\socketmodule.c 5124 _socket
Error 15 error C2373: 'inet_ntop' : redefinition; different type
modifiers c:\all\code\python-svn\modules\socketmodule.c 5139 _socket
Warning 16 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification winsound.obj winsound
Warning 17 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification unicodedata.obj unicodedata
Error 18 fatal error C1083: Cannot open include file: 'tcl.h': No such
file or directory c:\all\code\python-svn\modules\_tkinter.c 66 _tkinter
Error 19 fatal error C1083: Cannot open include file: 'tcl.h': No such
file or directory c:\all\code\python-svn\modules\tkappinit.c 16 _tkinter
Warning 20 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification selectmodule.obj select
Error 21 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Error 22 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Error 23 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Error 24 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Error 25 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Error 26 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Error 27 fatal error C1083: Cannot open include file: 'sqlite3.h': No
such file or directory
c:\all\code\python-svn\modules\_sqlite\connection.h 33 _sqlite3
Warning 28 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification _msi.obj _msi
Warning 29 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification _elementtree.obj _elementtree
Warning 30 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification _ctypes_test.obj _ctypes_test
Error 31 fatal error C1083: Cannot open include file: 'bzlib.h': No such
file or directory c:\all\code\python-svn\modules\bz2module.c 12 bz2
Warning 32 warning C4005: 'WRITE_RESTRICTED' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _ctypes
Warning 33 warning C4005: 'WRITE_RESTRICTED' : macro redefinition
c:\program files\microsoft sdks\windows\v6.0a\include\winnt.h 7127 _ctypes
Warning 34 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification pyexpat.obj pyexpat
Warning 35 warning LNK4075: ignoring '/EDITANDCONTINUE' due to
'/INCREMENTAL:NO' specification _ctypes.obj _ctypes
</end of errors>
Are these solvable problems? Is there something I can do to help?
Thanks!
Swaroop
----------
components: Build
messages: 55891
nosy: swaroopch
severity: normal
status: open
title: Python doesn't compile on Microsoft Visual Studio 2008 "Orcas" Beta 2
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1162>
__________________________________
From report at bugs.python.org Thu Sep 13 22:44:44 2007
From: report at bugs.python.org (Jono DiCarlo)
Date: Thu, 13 Sep 2007 20:44:44 -0000
Subject: [New-bugs-announce] [issue1163] Patch to make
py3k/Lib/test/test_thread.py use unittest
Message-ID: <1189716284.14.0.731587467816.issue1163@psf.upfronthosting.co.za>
New submission from Jono DiCarlo:
In the google spreadsheet for py3k tasks for the sprint last month, one
of the listed tasks was to convert Lib/test/test_thread to use the
unittest module, where it previously was using the old-style testing
(i.e. comparing output of print statements to a text file). I'm
attatching a patch that makes that change.
This is my first time submitting a patch to Python, so please let me
know if I'm doing anything wrong (or if this patch is redundant).
----------
components: Tests
files: jdicarlo_stdlibtests_patch_sep7.diff
messages: 55899
nosy: JonoDiCarlo
severity: minor
status: open
title: Patch to make py3k/Lib/test/test_thread.py use unittest
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1163>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdicarlo_stdlibtests_patch_sep7.diff
Type: text/x-patch
Size: 9757 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070913/febdae95/attachment.bin
From report at bugs.python.org Fri Sep 14 21:21:37 2007
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 14 Sep 2007 19:21:37 -0000
Subject: [New-bugs-announce] [issue1164] tp_print slots don't release the GIL
Message-ID: <1189797697.47.0.24596093087.issue1164@psf.upfronthosting.co.za>
New submission from Armin Rigo:
The tp_print slots, used by 'print' statements, don't release the GIL
while writing into the C-level file. This is not only a missing
opportunity, but can cause unexpected deadlocks, as shown in the
attached file.
----------
components: Interpreter Core
files: deadlock1.py
messages: 55913
nosy: arigo
severity: normal
status: open
title: tp_print slots don't release the GIL
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1164>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deadlock1.py
Type: text/x-python
Size: 288 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070914/487f9221/attachment.py
From report at bugs.python.org Sat Sep 15 17:19:47 2007
From: report at bugs.python.org (Eduardo Padoan)
Date: Sat, 15 Sep 2007 15:19:47 -0000
Subject: [New-bugs-announce] [issue1165] Should itertools.count work for
arbitrary integers?
Message-ID: <1189869587.07.0.169329623403.issue1165@psf.upfronthosting.co.za>
New submission from Eduardo Padoan:
Currently, itertools.count.__next__ checks wether the current value is >
PY_SSIZE_T_MAX and raises OverflowError if so. Shouldn't the value be
stored as "long", at least in Py3k? Not that I have any use case for it,
so it is minor.
----------
components: Library (Lib)
messages: 55927
nosy: eopadoan
severity: minor
status: open
title: Should itertools.count work for arbitrary integers?
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1165>
__________________________________
From report at bugs.python.org Sat Sep 15 17:32:00 2007
From: report at bugs.python.org (Eric S. R-eyyyy-mond)
Date: Sat, 15 Sep 2007 15:32:00 -0000
Subject: [New-bugs-announce] [issue1166] NameError when calling malloc
Message-ID: <1189870320.85.0.870817039772.issue1166@psf.upfronthosting.co.za>
New submission from Eric S. R-eyyyy-mond:
I tried this code, and it blew up in my face.
>>> foo = malloc(4096)
NameError: name 'malloc' is not defined
Why?
----------
components: Library (Lib)
keywords: r-eyyy-mond
messages: 55929
nosy: esr
priority: high
severity: normal
status: open
title: NameError when calling malloc
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1166>
__________________________________
From report at bugs.python.org Sun Sep 16 07:37:52 2007
From: report at bugs.python.org (Ian Kelly)
Date: Sun, 16 Sep 2007 05:37:52 -0000
Subject: [New-bugs-announce] [issue1167] gdbm/ndbm 1.8.1+ needs
libgdbm_compat.so
Message-ID: <1189921072.53.0.557521657427.issue1167@psf.upfronthosting.co.za>
New submission from Ian Kelly:
The ndbm functions in gdbm 1.8.1+ require the gdbm_compat library in
addition to gdbm.
----------
components: Build, Extension Modules
files: gdbm_ndbm.diff
messages: 55939
nosy: ikelly
severity: normal
status: open
title: gdbm/ndbm 1.8.1+ needs libgdbm_compat.so
type: compile error
versions: Python 2.5, Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1167>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdbm_ndbm.diff
Type: application/octet-stream
Size: 1019 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070916/7067ae9e/attachment.obj
From report at bugs.python.org Sun Sep 16 09:31:20 2007
From: report at bugs.python.org (Nusret BALCI)
Date: Sun, 16 Sep 2007 07:31:20 -0000
Subject: [New-bugs-announce] [issue1168] complex arithmetic: strange results
with "imag"
Message-ID: <1189927880.3.0.518995379378.issue1168@psf.upfronthosting.co.za>
New submission from Nusret BALCI:
"imag" returns incorrect results if invoked on a literal number.
Looks like a bug.
>>> 1-2j
(1-2j)
>>> 1-2j.real
1.0
>>> 1-2j.imag
-1.0
>>> 1-4j.imag
-3.0
>>> (1-4j).imag
-4.0
>>>
----------
messages: 55940
nosy: newman
severity: normal
status: open
title: complex arithmetic: strange results with "imag"
type: behavior
versions: Python 2.5, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1168>
__________________________________
From report at bugs.python.org Sun Sep 16 18:07:42 2007
From: report at bugs.python.org (Daniele Varrazzo)
Date: Sun, 16 Sep 2007 16:07:42 -0000
Subject: [New-bugs-announce] [issue1169] Option -OO doesn't remove
docstrings from functions
Message-ID: <1189958862.36.0.812206723561.issue1169@psf.upfronthosting.co.za>
New submission from Daniele Varrazzo:
The issue was already addressed in Issue1722485.
The fix applied in rev. 55732, 55733 only fixes module and class
docstrings, not function docstrings.
The attached patch fixed the issue for function docstrings too.
----------
components: None
files: fix_function_docstring.patch
messages: 55945
nosy: piro
severity: normal
status: open
title: Option -OO doesn't remove docstrings from functions
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1169>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_function_docstring.patch
Type: text/x-patch
Size: 419 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070916/41418fd7/attachment.bin
From report at bugs.python.org Mon Sep 17 19:18:34 2007
From: report at bugs.python.org (Mathieu Fenniak)
Date: Mon, 17 Sep 2007 17:18:34 -0000
Subject: [New-bugs-announce] [issue1171] allow subclassing of bytes type
Message-ID: <1190049514.0.0.613469664366.issue1171@psf.upfronthosting.co.za>
New submission from Mathieu Fenniak:
Uploading patch to make bytes type subclassable.
As e-mailed to python-3000 list during discussion with Guido, attached
patch to make bytes type subclassable. Included are unit tests, and a
minor fix for pickling subclass instances (including __dict__ in
bytes_reduce).
----------
files: bytes-subclass-patch.diff
messages: 55970
nosy: mfenniak
severity: minor
status: open
title: allow subclassing of bytes type
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1171>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bytes-subclass-patch.diff
Type: application/octet-stream
Size: 4806 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070917/365ab150/attachment.obj
From report at bugs.python.org Mon Sep 17 21:19:47 2007
From: report at bugs.python.org (Bob Kline)
Date: Mon, 17 Sep 2007 19:19:47 -0000
Subject: [New-bugs-announce] [issue1172] Documentation for done attribute of
FieldStorage class
Message-ID: <1190056787.13.0.107687348277.issue1172@psf.upfronthosting.co.za>
New submission from Bob Kline:
I have attached a patch which adds partial documentation for the done
attribute of the cgi.FieldStorage class. This addition is needed in
order to make it safe to rely on the current behavior of the class,
which sets this attribute to the value -1 when an uploaded file from a
CGI form does not arrive intact.
If I have sufficient free time to do so at some point in the future, I
would like to submit a more extensive modification for the module's
documentation, using a format which matches that used for most of the
other modules (that is, including documentation of all of the methods
and attributes intended for public use), and I'd be inclined to modify
the cgi.py module itself, to use a less opaque approach for conveying
the failure than the 'done' attribute. I'd want some indication that
there was a reasonable chance that if I were to invest the work on this
improvement the results would actually be used (I see my latest patch
for the module has been languishing in the 'ignored' pile for over a
year). If anyone else is doing some overhaul work in this area, please
speak up so we don't end up with duplication of effort.
I would think that this module would be one of the most commonly used in
the entire Python library, and would thus warrant careful maintenance
(including addressing all of the "XXX let's fix this ..." comments.
Cheers!
----------
components: Documentation
files: cgi.rst.diff
messages: 55975
nosy: bkline
severity: normal
status: open
title: Documentation for done attribute of FieldStorage class
type: rfe
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1172>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cgi.rst.diff
Type: text/x-patch
Size: 701 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070917/8ec71105/attachment.bin
From report at bugs.python.org Mon Sep 17 22:52:42 2007
From: report at bugs.python.org (Bruce Frederiksen)
Date: Mon, 17 Sep 2007 20:52:42 -0000
Subject: [New-bugs-announce] [issue1174] new generator methods not
documented in Library Reference
Message-ID: <1190062362.55.0.601253813398.issue1174@psf.upfronthosting.co.za>
New submission from Bruce Frederiksen:
The 2.5 library documentation mentions the new GeneratorExit exception,
but does not show Generator Types with the new 'send', 'throw', 'close'
and '__del__' methods.
----------
components: Documentation
messages: 55981
nosy: dangyogi
severity: minor
status: open
title: new generator methods not documented in Library Reference
type: rfe
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1174>
__________________________________
From report at bugs.python.org Tue Sep 18 12:37:34 2007
From: report at bugs.python.org (Alex Burr)
Date: Tue, 18 Sep 2007 10:37:34 -0000
Subject: [New-bugs-announce] [issue1175] .readline() has bug WRT nonblocking
files
Message-ID: <1190111854.34.0.00279281221972.issue1175@psf.upfronthosting.co.za>
New submission from Alex Burr:
If you have made a file nonblocking using fcntl.fcntl, .readline() will
discard the start of a line if you get EGAIN. It should attach the
partial line to the exception somehow - or at least warn the user.
I observe this on 2.3.5, but the same code exists in TRUNK
----------
components: Interpreter Core
messages: 55993
nosy: ajb
severity: normal
status: open
title: .readline() has bug WRT nonblocking files
type: behavior
versions: Python 2.3
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175>
__________________________________
From report at bugs.python.org Tue Sep 18 18:59:52 2007
From: report at bugs.python.org (Sergio Correia)
Date: Tue, 18 Sep 2007 16:59:52 -0000
Subject: [New-bugs-announce] [issue1176] str.split() takes no keyword
arguments (Should this be expected?)
Message-ID: <1190134792.72.0.164099608894.issue1176@psf.upfronthosting.co.za>
New submission from Sergio Correia:
str.split() does not accept maxsplits as a keyword argument.
If i want to split a string, and, say, get its first word, I do this:
>>> 'SPAM eggs eggs spam spam ham'.split(None, 1)[0]
'SPAM'
However, as documented on help(str.split), the separator is optional, so
I expected this to work:
>>> 'SPAM eggs eggs spam spam ham'.split(maxsplit=1)
Traceback (most recent call last):
File "<pyshell#8>", line 1, in <module>
'SPAM eggs eggs spam spam ham'.split(maxsplit=1)
TypeError: split() takes no keyword arguments
I feel allowing keyword arguments is convenient, but is there a reason
behind not allowing them?
----------
components: Library (Lib)
messages: 56002
nosy: sergioc
severity: minor
status: open
title: str.split() takes no keyword arguments (Should this be expected?)
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1176>
__________________________________
From report at bugs.python.org Tue Sep 18 22:22:53 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=)
Date: Tue, 18 Sep 2007 20:22:53 -0000
Subject: [New-bugs-announce] [issue1177] urllib* 20x responses not OK?
Message-ID: <1190146973.85.0.192058090901.issue1177@psf.upfronthosting.co.za>
New submission from
Jim Jewett
:
Under the http protocol, any 2xx response is OK.
urllib.py and urllib2.py hardcoded only response 200 (the most common).
http://bugs.python.org/issue912845 added 206 as acceptable to urllib2, but
not any other 20x responses. (It also didn't fix urllib.)
Suggested for 2.6, as it does change behavior.
(Also see duplicate http://bugs.python.org/issue971965 which I will try to
close after opening this. )
----------
components: Library (Lib)
messages: 56009
nosy: jimjjewett
severity: normal
status: open
title: urllib* 20x responses not OK?
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1177>
__________________________________
From report at bugs.python.org Wed Sep 19 00:03:30 2007
From: report at bugs.python.org (Tal Einat)
Date: Tue, 18 Sep 2007 22:03:30 -0000
Subject: [New-bugs-announce] [issue1178] IDLE - add "paste code"
functionality
Message-ID: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za>
New submission from Tal Einat:
Patch adding a 'Paste Code' item to the 'Edit' menu, as well as hotkeys.
Using 'Paste Code' instead of the normal paste will remove prompts ('>>>
' or '... ') from the code, and also remove empty lines if pasting to a
shell window.
This allows easily copy/pasting code between shell and editor windows,
as well as easily pasting code from other applications (e.g. a web
browser) into IDLE.
This patch uses IDLE's PyParse.py for parsing code, and Tk's clipboard
API for interaction with the clipboard (it changes the clipboard's
contents, generates a normal paste event, and changes the contents back).
Test only on WinXP SP2 so far, needs to be tested on other platforms,
especially the clipboard interaction.
----------
components: IDLE
files: IDLE_paste_code.070918.patch
messages: 56017
nosy: taleinat
severity: minor
status: open
title: IDLE - add "paste code" functionality
type: behavior
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1178>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDLE_paste_code.070918.patch
Type: application/octet-stream
Size: 5292 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070918/173a1838/attachment.obj
From report at bugs.python.org Wed Sep 19 03:02:34 2007
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 19 Sep 2007 01:02:34 -0000
Subject: [New-bugs-announce] [issue1179] [CVE-2007-4965] Integer overflow in
imageop module
Message-ID: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
New submission from Ismail Donmez:
As reported at
http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065826.html
. There is an integer overflow in imageop module which results in an
interpreter crash. Original proof of concept code is attached.
----------
components: Library (Lib)
files: poc.py
messages: 56020
nosy: cartman
severity: normal
status: open
title: [CVE-2007-4965] Integer overflow in imageop module
type: security
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1179>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: poc.py
Type: text/x-python
Size: 263 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070919/d6fc562e/attachment.py
From report at bugs.python.org Wed Sep 19 23:38:22 2007
From: report at bugs.python.org (Martin Horcicka)
Date: Wed, 19 Sep 2007 21:38:22 -0000
Subject: [New-bugs-announce] [issue1181] Redefine clear() for os.environ to
use unsetenv() if possible
Message-ID: <1190237902.57.0.871382719483.issue1181@psf.upfronthosting.co.za>
New submission from Martin Horcicka:
This patch makes os.environ.clear() to have the same effect as:
for name in os.environ.keys():
del os.environ[name]
I believe that most people expect the effects to be the same anyway.
The practical benefit is a simpler redefinition of the whole environment
if desired (e.g. in scripts run via sudo on unix systems).
----------
components: Library (Lib)
files: os.py.patch
messages: 56048
nosy: horcicka
severity: normal
status: open
title: Redefine clear() for os.environ to use unsetenv() if possible
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1181>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: os.py.patch
Type: text/x-patch
Size: 967 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070919/955263b9/attachment.bin
From report at bugs.python.org Thu Sep 20 18:26:58 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Hirokazu_Yamamoto=0A=09=09=09=09?=)
Date: Thu, 20 Sep 2007 16:26:58 -0000
Subject: [New-bugs-announce] [issue1182] Paticular decimal mod operation
wrongly output NaN.
Message-ID: <1190305618.56.0.684353803069.issue1182@psf.upfronthosting.co.za>
New submission from
Hirokazu Yamamoto
:
Following code illegally print "NaN" on Python2.5.
from decimal import *
d1 = Decimal("23.08589694291355371979265447")
d2 = Decimal("2.302585092994045640179914546844")
print d1 % d2
Python2.6(trunk) print 0.06004601297309731799350900156
----------
components: Library (Lib)
messages: 56056
nosy: ocean-city
severity: normal
status: open
title: Paticular decimal mod operation wrongly output NaN.
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182>
__________________________________
From report at bugs.python.org Thu Sep 20 21:35:42 2007
From: report at bugs.python.org (David Ripton)
Date: Thu, 20 Sep 2007 19:35:42 -0000
Subject: [New-bugs-announce] [issue1183] race in
SocketServer.ForkingMixIn.collect_children
Message-ID: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za>
New submission from David Ripton:
CentOS Linux 5, Python 2.4.3 (but code appears unchanged in 2.5 and
trunk, so I don't believe this bug has already been fixed)
We have an xmlrpc server that subclasses DocXMLRPCServer.DocXMLRPCServer
and SocketServer.ForkingMixIn. Under load, it sometimes crashes with an
error in SocketServer.ForkingMixIn.collect_children
The bug is that collect_children calls os.waitpid with pid 0, so it
waits for any child. But then it assumes that the pid found was in the
list self.active_children, and attempts to remove it from that list
without a try block. However, another call to collect_children could
have already removed it, so we get "ValueError: list.remove(x): x not in
list"
The fix is just adding a try/except block around the attempt to remove
pid from self.active children.
diff -u SocketServer.py /tmp/SocketServer.py
--- SocketServer.py 2007-08-27 10:52:24.000000000 -0400
+++ /tmp/SocketServer.py 2007-09-20 15:34:00.000000000 -0400
@@ -421,7 +421,10 @@
except os.error:
pid = None
if not pid: break
- self.active_children.remove(pid)
+ try:
+ self.active_children.remove(pid)
+ except ValueError:
+ pass
def process_request(self, request, client_address):
"""Fork a new subprocess to process the request."""
----------
components: Library (Lib)
messages: 56065
nosy: dripton
severity: normal
status: open
title: race in SocketServer.ForkingMixIn.collect_children
type: crash
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1183>
__________________________________
From report at bugs.python.org Fri Sep 21 00:38:04 2007
From: report at bugs.python.org (Adam Hupp)
Date: Thu, 20 Sep 2007 22:38:04 -0000
Subject: [New-bugs-announce] [issue1184] test fixes for immutable bytes
change
Message-ID: <1190327884.17.0.303606254957.issue1184@psf.upfronthosting.co.za>
New submission from Adam Hupp:
This patch resolves most of the test failures introduced by Jeffrey
Yasskin's immutable bytes change.
The remaining failures are:
test_io
test_mailbox
test_mhlib
test_old_mailbox
test_email
test_univnewlines
The first 4 are the same problem. An array('B') is passed to
PyArg_ParseTuple("t#..."). This results in "TypeError: Cannot be a
character buffer" from ascii_decode in _codecsmodule.c.
Note: This patch is also includes Jeffrey's original changes.
----------
components: Interpreter Core, Library (Lib)
files: immutable-bytes-test-fix.patch
messages: 56066
nosy: hupp
severity: normal
status: open
title: test fixes for immutable bytes change
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1184>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: immutable-bytes-test-fix.patch
Type: application/octet-stream
Size: 46512 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070920/38b741d4/attachment-0001.obj
From report at bugs.python.org Fri Sep 21 00:51:45 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 20 Sep 2007 22:51:45 -0000
Subject: [New-bugs-announce] [issue1185] py3k: Completely remove nb_coerce
slot
Message-ID: <1190328705.55.0.555438383037.issue1185@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
Arguments coercion has been removed in py3k for a while, but there are
still some traces of it.
This patch removes the nb_coerce slot and the last usages of __coerce__.
Documentation is also updated: Py_TPFLAGS_CHECKTYPES does not exists
anymore.
Note: I ran the testsuite on Windows only.
----------
components: Interpreter Core
files: nocoerce.diff
messages: 56067
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: Completely remove nb_coerce slot
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nocoerce.diff
Type: application/octet-stream
Size: 11152 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070920/7914859d/attachment.obj
From report at bugs.python.org Fri Sep 21 11:51:55 2007
From: report at bugs.python.org (Michael Hoffman)
Date: Fri, 21 Sep 2007 09:51:55 -0000
Subject: [New-bugs-announce] [issue1186] optparse documentation: -- being
collapsed to - in HTML
Message-ID: <1190368314.95.0.279950247421.issue1186@psf.upfronthosting.co.za>
New submission from Michael Hoffman:
See <http://docs.python.org/lib/optparse-callback-example-6.html> where
it says 'either "-" or "-" can be option arguments'. One of these should
be --. The same error occurs several times on the same page.
Not a problem in the Optik docs at
<http://optik.sourceforge.net/doc/1.5/callbacks.html>.
----------
components: Documentation
messages: 56074
nosy: gward, hoffman
severity: normal
status: open
title: optparse documentation: -- being collapsed to - in HTML
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1186>
__________________________________
From report at bugs.python.org Fri Sep 21 20:42:09 2007
From: report at bugs.python.org (Andrew Nissen)
Date: Fri, 21 Sep 2007 18:42:09 -0000
Subject: [New-bugs-announce] [issue1187] pipe fd handling issues in
subprocess.py on POSIX
Message-ID: <1190400129.03.0.21752289973.issue1187@psf.upfronthosting.co.za>
New submission from Andrew Nissen:
Revision 53293 appears to have missed some of the logic inherent in the
previous code. There also appears to be problems with the way that the
dup2 calls are made that can result in a behavior different then
intended under a number of circumstances.
fix_fileno.py demonstrates the improper behavior
----------
components: Library (Lib)
files: fix_fileno.py
messages: 56079
nosy: anissen
severity: minor
status: open
title: pipe fd handling issues in subprocess.py on POSIX
type: behavior
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1187>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_fileno.py
Type: text/x-python
Size: 515 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070921/b9cc658e/attachment.py
From report at bugs.python.org Sat Sep 22 02:33:37 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Philip_Jenvey=0A=09=09=09=09?=)
Date: Sat, 22 Sep 2007 00:33:37 -0000
Subject: [New-bugs-announce] [issue1188] universal newlines doesn't identify
CRLF during tell()
Message-ID: <1190421217.52.0.890075732591.issue1188@psf.upfronthosting.co.za>
New submission from
Philip Jenvey
:
tell() will skip the next LF (after a CR sets f_skipnextlf) when
universal newline support is enabled; essentially doing part of the work
of read(). However it does not identify CRLF as a newline, as read()
would, e.g.:
>>> open('/tmp/crlf', 'wb').write('CRLF\r\nEOF')
>>> fp = open('/tmp/crlf', 'U')
>>> fp.read()
'CRLF\nEOF'
>>> fp.newlines # correct when read()ing
'\r\n'
>>> fp = open('/tmp/crlf', 'U')
>>> fp.readline()
'CRLF\n'
>>> fp.newlines
>>> fp.tell()
6L
>>> fp.newlines # tell() skipped ahead..
>>> fp.readline()
'EOF'
>>> fp.newlines # ..but never identified CRLF
>>>
The following patch makes tell() mark CRLF as a newline in this case,
and ensures so with an added test to test_univnewlines.py. It's against
trunk, r28227
----------
components: Library (Lib)
files: univnewline_tell-r58227.diff
messages: 56085
nosy: pjenvey
severity: normal
status: open
title: universal newlines doesn't identify CRLF during tell()
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1188>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: univnewline_tell-r58227.diff
Type: application/octet-stream
Size: 1003 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070922/0e5ec3d1/attachment.obj
From report at bugs.python.org Sat Sep 22 02:44:25 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 22 Sep 2007 00:44:25 -0000
Subject: [New-bugs-announce] [issue1189] Documentation for tp_as_number
tp_as_sequence tp_as_mapping
Message-ID: <1190421865.82.0.564547764267.issue1189@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
This patch adds documentation for all the fields in the tp_as_number,
tp_as_sequence and tp_as_mapping structures.
It may not be complete, but is still better than the XXX in the current
docs.
This is my first contribution to the doc, feel free to amend it!
This patch describes the python3.0 situation, which is simpler since the
removal of coercion. It can serve as a start for 2.6 as well; a second
patch about coercion will follow.
PS: it's really a pleasure to use the new ReST format.
----------
components: Documentation
files: numbermethods-py3k.diff
messages: 56087
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Documentation for tp_as_number tp_as_sequence tp_as_mapping
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1189>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: numbermethods-py3k.diff
Type: application/octet-stream
Size: 7835 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070922/76a80e17/attachment.obj
From report at bugs.python.org Sat Sep 22 19:08:31 2007
From: report at bugs.python.org (Michael Lawrence)
Date: Sat, 22 Sep 2007 17:08:31 -0000
Subject: [New-bugs-announce] [issue1190] Windows rants& sugestions.
Message-ID: <1190480911.5.0.176921994431.issue1190@psf.upfronthosting.co.za>
New submission from Michael Lawrence:
TCL Perl , resources , sometimes with the python tool kit , i'd want
certin compontents removed ,
namely tcl/tk ; on a custom Installer Do you have windows TCL/TK
(YES/no) (Yes) and the gui option panel to repoiit items add perl ruby
ponteirs etc.
Alt Python (type) I/E Unix or Cygwin
ALT perl , Iterix is a real sweet set of tools ,
But mainly Adding Path Statments and getting rid of other Python
interpriters, and just using main python,
version'd python is nice but , often force C:\Python
for windows i just wish you could index other dirs of python code , etc
and compile them to pyc with a right click option.
some programs use full blown python stubs , anyhow with a path option
etc , be nice to not have orphaned stubs, etc.
Juice and others use older python compiler etc, a script to hunt down
compile > default python = C:\Python\python.exe etc.
also lib paths on python for windows \python\lib-ver keep scripts for
migration. etc.
just for sake of argument give upgrade ease and less python25; 25; 26 ;
30b folders
and for testing can put the stable into main |python|bin
beta into |python|testing|bin etc.
thouse are my few irks with windows , having main tcl path specified is
resonable because with a utility it is eassy to script-name.tcl >
filename.dll , wich offers some speed.
I dont program to much but , I do try not to have wastes of disk space.
just the option of setting TCL/TK , perl ruby etc for python to call
from default location would be a plus , and would save some disk space.
and if the tcl/tk were updated wouldnt break links.
and if
jsee or just the java plugin were installed to have system vabiles etc
for usage.
PATHEXT add item for executable , can add ruby perl etc to it as well
for py or pyc, this too would force a default python interpriter,
option. the curent python for widows is alot faster than the older mini
ones in other apps.
anyhow thats my 2 ? cents
----------
components: Windows
messages: 56089
nosy: wolfstar359
severity: minor
status: open
title: Windows rants& sugestions.
type: resource usage
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1190>
__________________________________
From report at bugs.python.org Sun Sep 23 01:28:42 2007
From: report at bugs.python.org (Bryan Henderson)
Date: Sat, 22 Sep 2007 23:28:42 -0000
Subject: [New-bugs-announce] [issue1191] Berkeley DB prerequisite
inconsistent
Message-ID: <1190503722.68.0.665728858894.issue1191@psf.upfronthosting.co.za>
New submission from Bryan Henderson:
There's some inconsistency among the code and documentation as to the
required level of Berkeley DB. I don't know what the proper
resolution, but I'm sure someone familiar with the history of this code
does. Something needs to be done to reduce the amount of time it takes
someone (as it did me) to deal with not having the expected level of
Berkeley DB installed.
I attached a file with a detailed explanation of my observations.
----------
components: Build
files: problem_description.txt
messages: 56093
nosy: giraffedata
severity: normal
status: open
title: Berkeley DB prerequisite inconsistent
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: problem_description.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070922/433629b5/attachment.txt
From report at bugs.python.org Mon Sep 24 05:39:00 2007
From: report at bugs.python.org (Robert T McQuaid)
Date: Mon, 24 Sep 2007 03:39:00 -0000
Subject: [New-bugs-announce] [issue1192] Python 3 documents crash Firefox
Message-ID: <1190605139.92.0.443157487158.issue1192@psf.upfronthosting.co.za>
New submission from Robert T McQuaid:
I downloaded python-3.0a1.msi for Windows XP and after install converted
the documentation from chm format to html with the hh.exe utility in XP.
The resulting files crashed Firefox version 2.0 (it slowly chokes to
death in a dozen operations), but worked fine on Opera 9.21.
----------
components: Documentation
messages: 56099
nosy: rtmq
severity: minor
status: open
title: Python 3 documents crash Firefox
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1192>
__________________________________
From report at bugs.python.org Mon Sep 24 06:51:53 2007
From: report at bugs.python.org (Fan Decheng)
Date: Mon, 24 Sep 2007 04:51:53 -0000
Subject: [New-bugs-announce] [issue1193] os.system() encoding bug on Windows
Message-ID: <1190609513.75.0.19939188132.issue1193@psf.upfronthosting.co.za>
New submission from Fan Decheng:
Python 3.0 uses utf-8 encoding, but os.system() when running on Windows
uses
the system default encoding, which may be "cp936" or "mbcs". They are
incompatible.
----------
components: Library (Lib)
messages: 56101
nosy: r_mosaic
severity: major
status: open
title: os.system() encoding bug on Windows
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193>
__________________________________
From report at bugs.python.org Mon Sep 24 08:26:40 2007
From: report at bugs.python.org (Fan Decheng)
Date: Mon, 24 Sep 2007 06:26:40 -0000
Subject: [New-bugs-announce] [issue1194] The reduce() documentation is lost
in Python 3.0a1
Message-ID: <1190615200.14.0.737231266393.issue1194@psf.upfronthosting.co.za>
New submission from Fan Decheng:
The reduce() documentation is lost in Python 3.0a1.
In the documentation, functools.reduce() points onto itself, so no
further explanation can be found.
----------
components: Documentation
messages: 56103
nosy: r_mosaic
severity: minor
status: open
title: The reduce() documentation is lost in Python 3.0a1
type: rfe
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1194>
__________________________________
From report at bugs.python.org Mon Sep 24 12:48:56 2007
From: report at bugs.python.org (Rebecca Breu)
Date: Mon, 24 Sep 2007 10:48:56 -0000
Subject: [New-bugs-announce] [issue1195] Problems on Linux with Ctrl-D and
Ctrl-C during raw_input
Message-ID: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
New submission from Rebecca Breu:
Run the program:
while True:
try:
s = raw_input('> ')
except:
pass
Press Ctrl-D and then Ctrl-C, and you get
Traceback (most recent call last):
File "test.py", line 5, in ?
s = raw_input('> ')
KeyboardInterrupt
Pressing just Ctrl-D or Ctrl-C continues the loop as expected, Ctrl-D
after Ctrl-C works, too. Only Ctrl-C after Ctrl-D sucks, even when you
try to catch "EOFError" and "KeybordInterrupt" explicitly.
The problem occurs with Python 2.4 and 2.5 on Debian testing, friends
confirmed the error under Ubuntu/2.5 and Gentoo/?.
The error does not occur when you import readline first.
Ah, and by the way: http://docs.python.org/lib/reporting-bugs.html
still links to the sourceforce bucktracker.
----------
components: None
messages: 56109
nosy: Rebecca
severity: normal
status: open
title: Problems on Linux with Ctrl-D and Ctrl-C during raw_input
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
__________________________________
From report at bugs.python.org Mon Sep 24 14:04:16 2007
From: report at bugs.python.org (Tim Delaney)
Date: Mon, 24 Sep 2007 12:04:16 -0000
Subject: [New-bugs-announce] [issue1196] int() documentation does not
specify default radix
Message-ID: <1190635456.12.0.478143217592.issue1196@psf.upfronthosting.co.za>
New submission from Tim Delaney:
The int() documentation (section 2.1) does not specify the default
radix used. Alternatively, it does not specify the default behaviour
for string parsing.
Experimentally, it's parsing with a default radix of 10 - I recall in
an earlier version of Python it parsed with a default radix of zero
(i.e. dependent on the string contents).
I would suggest the following text:
int( [x[, radix]])
Convert a string or number to a plain integer. If the argument is a
string, it must contain a possibly signed decimal number representable
as a Python integer, possibly embedded in whitespace. The radix
parameter gives the base for the conversion and may be any integer in
the range [2, 36], or zero. If radix is zero, the proper radix is
guessed based on the contents of string; the interpretation is the same
as for integer literals. If radix is specified and x is not a string,
TypeError is raised. If radix is not specified, and x is a string, the
interpretation is as if a radix of 10 was specified. Otherwise, the
argument may be a plain or long integer or a floating point number.
Conversion of floating point numbers to integers truncates (towards
zero). If the argument is outside the integer range a long object will
be returned instead. If no arguments are given, returns 0.
----------
components: Documentation
messages: 56110
nosy: tcdelaney
severity: normal
status: open
title: int() documentation does not specify default radix
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1196>
__________________________________
From report at bugs.python.org Mon Sep 24 20:12:05 2007
From: report at bugs.python.org (Paul F. Dubois)
Date: Mon, 24 Sep 2007 18:12:05 -0000
Subject: [New-bugs-announce] [issue1198] Test of 2to3 component auditor
Message-ID: <1190657525.85.0.487762391432.issue1198@psf.upfronthosting.co.za>
New submission from Paul F. Dubois:
This is a test issue, please ignore.
----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 56123
nosy: collinwinter, dubois
severity: minor
status: open
title: Test of 2to3 component auditor
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1198>
__________________________________
From report at bugs.python.org Tue Sep 25 02:31:57 2007
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Sep 2007 00:31:57 -0000
Subject: [New-bugs-announce] [issue1199] Documentation for tp_as_number...
version 2.6
Message-ID: <1190680317.48.0.930951647845.issue1199@psf.upfronthosting.co.za>
New submission from Amaury Forgeot d'Arc:
This patch is similar to http://bugs.python.org/issue1189, but in line
with python svn trunk (and 2.5 most probably as well): documentation of
all slots of tp_as_number, tp_as_mapping, tp_as_sequence.
The main difference with 3.0 is the coercion.
----------
components: Documentation
files: numbermethods-2.6.diff
messages: 56124
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Documentation for tp_as_number... version 2.6
versions: Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1199>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: numbermethods-2.6.diff
Type: application/octet-stream
Size: 9865 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070925/5a2cc7d2/attachment.obj
From report at bugs.python.org Tue Sep 25 07:25:32 2007
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 25 Sep 2007 05:25:32 -0000
Subject: [New-bugs-announce] [issue1200] Allow array.array to be parsed by
the t# format unit.
Message-ID: <1190697931.82.0.81567230307.issue1200@psf.upfronthosting.co.za>
New submission from Jeffrey Yasskin:
This changes PyArg_ParseTuple()'s "t#" to request a PyBUF_SIMPLE buffer
like all of the other buffer-using format units instead of
PyBUF_CHARACTER. Objects with multi-byte units wind up
byte-order-dependent. Alternately, it might make sense to have
array.array('b') and array.array('B') accept the PyBUF_CHARACTER flag.
I haven't actually tested this patch on a big-endian machine.
----------
components: Interpreter Core
files: let_t_format_take_array.patch
messages: 56126
nosy: jyasskin
severity: normal
status: open
title: Allow array.array to be parsed by the t# format unit.
type: behavior
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1200>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: let_t_format_take_array.patch
Type: application/octet-stream
Size: 4198 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070925/8549bd6b/attachment-0001.obj
From report at bugs.python.org Tue Sep 25 10:27:01 2007
From: report at bugs.python.org (zip)
Date: Tue, 25 Sep 2007 08:27:01 -0000
Subject: [New-bugs-announce] [issue1201] Error in array concept
Message-ID: <1190708820.99.0.177688390446.issue1201@psf.upfronthosting.co.za>
New submission from zip:
http://docs.python.org/tut/node5.html
The best way to remember how slices work is to think of the indices as
pointing between characters, with the left edge of the first character
numbered 0. Then the right edge of the last character of a string of n
characters has index n, for example:
--
This is not possible because counting starts from 0 so the last charater
must be n-1.
----------
components: Documentation
messages: 56129
nosy: zip
severity: minor
status: open
title: Error in array concept
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1201>
__________________________________
From report at bugs.python.org Tue Sep 25 13:31:11 2007
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 25 Sep 2007 11:31:11 -0000
Subject: [New-bugs-announce] [issue1202] zlib.crc32() and adler32() return
value
Message-ID: <1190719871.47.0.233788425538.issue1202@psf.upfronthosting.co.za>
New submission from Armin Rigo:
The functions zlib.crc32() and zlib.adler32() return a signed value
in the range(-2147483648, 2147483648) on 32-bit platforms, but an
unsigned value in the range(0, 4294967296) on 64-bit platforms. This
means that half the possible answers are numerically different on these
two kinds of platforms.
Ideally, this should be fixed by having them always return unsigned
numbers (their C return type is unsigned too). It's unclear if we can
do this without breaking existing code, though :-(
----------
components: Extension Modules
messages: 56130
nosy: arigo
severity: normal
status: open
title: zlib.crc32() and adler32() return value
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1202>
__________________________________
From report at bugs.python.org Tue Sep 25 18:29:23 2007
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 25 Sep 2007 16:29:23 -0000
Subject: [New-bugs-announce] [issue1203] ctypes doesn't work on Mac with
--disable-toolbox-glue
Message-ID: <1190737763.36.0.452761453951.issue1203@psf.upfronthosting.co.za>
New submission from Bill Janssen:
If you build Python with --disable-toolbox-glue on OS X, the attempt to
import ctypes fails because it critically depends on "gestalt", one of
the modules in the toolbox. It only uses this to check whether the OS
level is 10.4 or something earlier, and only once, at load. Might be a
good idea to substitute a check which doesn't require the toolbox, such
as looking at platform.release().
----------
components: Library (Lib), Macintosh
messages: 56132
nosy: janssen
severity: normal
status: open
title: ctypes doesn't work on Mac with --disable-toolbox-glue
type: behavior
versions: Python 2.6, Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1203>
__________________________________
From report at bugs.python.org Tue Sep 25 21:34:08 2007
From: report at bugs.python.org (Mike Beachy)
Date: Tue, 25 Sep 2007 19:34:08 -0000
Subject: [New-bugs-announce] [issue1204] readline configuration for shared
libs w/o curses dependencies
Message-ID: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
New submission from Mike Beachy:
For RHEL 3 (and it also appears RHEL 4 and 5) the libreadline shared lib
has no specified lib requirement that satisfies the tgetent and related
symbols. (These symbols are provided by ncursesw, ncurses, curses,
termcap as noted in the python setup.py.) The configure script does not
add these required libs in for the readline tests, and so the autoconf
tests will fail and it will incorrectly determine that readline is not
present (and so not define HAVE_RL_COMPLETION_MATCHES etc.)
I guess this generally does not prevent the readline module from being
compiled since setup.py does its own search for readline and adds in the
needed curses library. It does prevent proper declaration of the
completion_matches function, however. On 32 bit systems this doesn't
matter but on 64 bit ones it does as the undeclared (but present in
libreadline) completion_matches returns a char **.
The fix checked in with r54874 after the 2.5.1 release (issue 1703270)
to Modules/readline.c fixes the problem for completion_matches
specifically, but the problem of incorrect determination of readline
presence still exists.
Attached is a patch to fix the problem: it adds the necessary additional
library to the temporary LIBS definition in the readline tests, using
the same order of curses libs specified in setup.py. (The patch includes
the changes for the configure script in addition to configure.in.)
----------
components: Installation
files: full.patch
messages: 56140
nosy: mbeachy
severity: normal
status: open
title: readline configuration for shared libs w/o curses dependencies
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: full.patch
Type: text/x-patch
Size: 3595 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070925/7d6dc67f/attachment.bin
From report at bugs.python.org Wed Sep 26 09:55:35 2007
From: report at bugs.python.org (Francesco Cosoleto)
Date: Wed, 26 Sep 2007 07:55:35 -0000
Subject: [New-bugs-announce] [issue1205] urllib fail to read URL contents,
urllib2 crash Python
Message-ID: <1190793332.9.0.29899287923.issue1205@psf.upfronthosting.co.za>
New submission from Francesco Cosoleto:
urllib fail to read URL contents, urllib2 crash Python
Python version:
-------------------------
Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)]
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Python 2.4.4 (#2, Aug 16 2007, 00:34:54)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
-------------------------
Working with GNU wget:
-------------------------
$ wget -S http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud
--08:42:21-- http://www.recherche.fr/encyclopedie/Thomas-Robert_Bugeaud
=> `Thomas-Robert_Bugeaud'
Risoluzione di www.recherche.fr in corso... 88.191.11.214
Connessione a www.recherche.fr|88.191.11.214:80... connesso.
HTTP richiesta inviata, aspetto la risposta...
HTTP/1.1 200 OK
Date: Wed, 26 Sep 2007 06:42:53 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.3-0.dotdeb.1 with Suhosin-Patch
X-Powered-By: PHP/5.2.3-0.dotdeb.1
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
Lunghezza: non specificato [text/html]
[ <=> ]
267,080 --.--K/s
08:42:42 (14.11 KB/s) - "Thomas-Robert_Bugeaud" salvato [267080]
-------------------------
Python:
-------------------------
>>> import urllib
>>> a = urllib.urlopen('http://www.recherche.fr/encyclopedie/Thomas-
Robert_Bugeaud')
>>> c = a.read(1024*1024*2)
>>> len(c)
1035220
>>> c[63000:64000]
'he.fr en page d\'accueil</a><br>\n <span>Partenaires :</span> <a
href="http://www.cartes.fr/" target="_blank">Cartes\n
postales</a> <a href="http://www.deux.fr/script/"
target="_blank">Rencontres\n gratuites\n </a> <a
href="http://www.new.fr/" target="_blank">Noms\n de domaine
gratuits</a> <a href="http://www.netencyclo.com/"
target="_blank">Encyclopedia</a> </p>\n <p style="text-
align:center;"><a href="http://www.futureobject.com/"
target="_blank"><img src="http://www.recherche.fr/images/logo_fo.gif"
border="0" height="25" width="96"></a></p>\n\n </p>\n </div>\n
</div><!-- site -->\n</body>\n</html>\n\r\n\x00\x00\x00\x00\x00\x00\x00
\x00\x00[...omission...]\x00\x00\x00\x00'
-------------------------
As above, but with urllib2 module instead of urllib:
-------------------------
File "/usr/lib/python2.5/socket.py", line 291, in read
data = self._sock.recv(recv_size)
File "/usr/lib/python2.5/httplib.py", line 509, in read
return self._read_chunked(amt)
File "/usr/lib/python2.5/httplib.py", line 548, in _read_chunked
chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: '\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00[...omission...]\x00\x00\x00\x00\x00\x00\x00
\
-------------------------
As above, but with Python 2.4:
-------------------------
>>> import urllib2
>>> a = urllib2.urlopen('http://www.recherche.fr/encyclopedie/Thomas-
Robert_Bugeaud')
>>>
>>> c = a.read(1024*1024*2)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/socket.py", line 295, in read
data = self._sock.recv(recv_size)
File "/usr/lib/python2.4/httplib.py", line 460, in read
return self._read_chunked(amt)
File "/usr/lib/python2.4/httplib.py", line 499, in _read_chunked
chunk_left = int(line, 16)
ValueError: invalid literal for int():
-------------------------
Regards,
Francesco Cosoleto
----------
components: None
messages: 56143
nosy: cosoleto
severity: normal
status: open
title: urllib fail to read URL contents, urllib2 crash Python
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1205>
__________________________________
From report at bugs.python.org Wed Sep 26 18:48:42 2007
From: report at bugs.python.org (Oleg Broytmann)
Date: Wed, 26 Sep 2007 16:48:42 -0000
Subject: [New-bugs-announce] [issue1206] logging/__init__.py
Message-ID: <1190825322.64.0.711764543828.issue1206@psf.upfronthosting.co.za>
New submission from Oleg Broytmann:
See the thread in the python-dev mailing list:
http://mail.python.org/pipermail/python-dev/2007-September/074732.html
----------
components: Library (Lib)
files: __init__.py.patch
messages: 56145
nosy: phd
severity: minor
status: open
title: logging/__init__.py
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1206>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: __init__.py.patch
Type: text/x-diff
Size: 541 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070926/938081f5/attachment.patch
From report at bugs.python.org Wed Sep 26 21:25:04 2007
From: report at bugs.python.org (Bluebird)
Date: Wed, 26 Sep 2007 19:25:04 -0000
Subject: [New-bugs-announce] [issue1207] Load tests from path (patch
included)
Message-ID: <1190834704.12.0.956914269209.issue1207@psf.upfronthosting.co.za>
New submission from Bluebird:
Something very nice about unittest is that it can find automatically the
TestCase that you declare, and the test methods of every test case. This
makes the operation of adding or removing tests very simple.
For test modules however, there is nothing to automatically load all the
modules of a given directory. I think that would be very helpful.
Here is my proposal, to add to the set of TestLoader methods:
============================
def loadTestsFromPath( path='', filePattern='test*.py' ):
'''Load all the TestCase in all the module of the given path.
path: directory containing test files
filePattern: glob pattern to find test modules inside path. Default
is test*.py
The path will be converted into an import statement so anything that
can not be imported will
not work. The path must be relative to the current directory, and
can not include '.' and '..'
directories.
To simply load all the test files of the current directories, pass
an empty path (the default).
Return a test suite containing all the tests.
'''
if len(path) == 0:
pathPattern = filePattern
else:
pathPattern = path + '/' + filePattern
pathPattern = os.path.normpath( pathPattern )
fileList = glob.glob( pathPattern )
mainSuite = TestSuite()
for f in fileList:
importName = f[:-3]
importName = importName.replace( '\\', '.' )
importName = importName.replace( '/', '.' )
suite = defaultTestLoader.loadTestsFromName(importName)
mainSuite._tests.extend( suite._tests )
return mainSuite
===================
I use it like this: on my project, I have the following directory
organisation:
vy
+ run_all_tests.py
+ tests
- run_tests.py
- test_xxx.py
- test_yyy.py
+ libvy
+ tests
- run_tests.py
- test_xxx.py
- test_yyy.py
+ qvy
+ tests
- run_tests.py
- test_xxx.py
- test_yyy.py
I can do either:
- cd libvy/tests && python run_tests.py
- cd qvy/tests && python run_tests.py
- cd tests && python run_tests.py
- run_all_tests.py
Each time I add a new test module, it is automatically picked up by the
test runners thank to the loadFromPath() feature. It makes it easy to
maintain the global test suite that runs all the tests. That's the most
important one because that test suite is responsible for non regression.
run_tests.py:
=============
if __name__ == '__main__':
mainSuite = TestSuite()
mainSuite._tests.extend( loadTestsFromPath('.')._tests )
ttr = TextTestRunner(verbosity=2)
ttr.run( mainSuite )
run_all_tests.py:
=================
if __name__ == '__main__':
mainSuite = TestSuite()
mainSuite._tests.extend( loadTestsFromPath( 'libvy/tests' )._tests )
mainSuite._tests.extend( loadTestsFromPath( 'qvy/tests' )._tests )
mainSuite._tests.extend( loadTestsFromPath( 'tests' )._tests )
ttr = TextTestRunner(verbosity=2)
ttr.run( mainSuite )
----------
components: Tests
messages: 56148
nosy: bluebird
severity: normal
status: open
title: Load tests from path (patch included)
type: rfe
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207>
__________________________________
From report at bugs.python.org Wed Sep 26 22:34:54 2007
From: report at bugs.python.org (Martin Horcicka)
Date: Wed, 26 Sep 2007 20:34:54 -0000
Subject: [New-bugs-announce] [issue1208] Match object should be guaranteed
to always be true
Message-ID: <1190838894.61.0.476932713989.issue1208@psf.upfronthosting.co.za>
New submission from Martin Horcicka:
Many people expect the match object from the re module to always be
true. They use it this way:
if regexp.match(string): do_something()
Some people do not expect it and use it differently:
if regexp.match(string) is not None: do_something()
Even in the standard library both ways are used. The first way is
simpler and nicer and thus better, in my opinion.
Current implementation of the match object (implemented as
_sre.SRE_Match object in Modules/_sre.c) seems to guarantee the trueness
(someone should check it) but in fact, there is no guarantee described
in the documentation.
----------
components: Documentation, Library (Lib)
messages: 56149
nosy: horcicka
severity: normal
status: open
title: Match object should be guaranteed to always be true
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1208>
__________________________________
From report at bugs.python.org Thu Sep 27 02:23:46 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Jim_Jewett=0A=09=09=09=09?=)
Date: Thu, 27 Sep 2007 00:23:46 -0000
Subject: [New-bugs-announce] [issue1209] IOError won't accept tuples longer
than 3
Message-ID: <1190852626.6.0.0118628699735.issue1209@psf.upfronthosting.co.za>
New submission from
Jim Jewett
:
EnvironmentError (including subclass IOError) has special treatment when
constructed with a 2-tuple or 3-tuple. A four-tuple turns off this special
treatment (and was used by urllib for that reason). As of 2.5, a four-tuple
raises a TypeError instead of just turning off the special treatment.
----------
components: Extension Modules
messages: 56150
nosy: jimjjewett
severity: normal
status: open
title: IOError won't accept tuples longer than 3
type: behavior
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1209>
__________________________________
From report at bugs.python.org Thu Sep 27 07:49:34 2007
From: report at bugs.python.org (Robert T McQuaid)
Date: Thu, 27 Sep 2007 05:49:34 -0000
Subject: [New-bugs-announce] [issue1210] imaplib does not run under Python 3
Message-ID: <1190872174.76.0.553436258502.issue1210@psf.upfronthosting.co.za>
New submission from Robert T McQuaid:
imaplib does not run under Python 3.
The following two-line python program, named testimap.py,
works when run from a Windows XP system shell prompt
using Python 2.5.1, but fails with Python 3.0. It
appears that the logic does not follow the distinction
between characters and bytes in Python 3.
import imaplib
mail=imaplib.IMAP4("mail.rtmq.infosathse.com")
e:\python25\python testimap.py
e:\python30\python testimap.py 2>f:syserr
The last line produced the trace:
Traceback (most recent call last):
File "testimap.py", line 10, in <module>
mail=imaplib.IMAP4("mail.rtmq.infosathse.com")
File "e:\python30\lib\imaplib.py", line 184, in __init__
self.welcome = self._get_response()
File "e:\python30\lib\imaplib.py", line 962, in _get_response
self._append_untagged(typ, dat)
File "e:\python30\lib\imaplib.py", line 800, in _append_untagged
if typ in ur:
TypeError: unhashable type: 'bytes'
----------
components: Library (Lib)
messages: 56154
nosy: rtmq
severity: normal
status: open
title: imaplib does not run under Python 3
type: crash
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1210>
__________________________________
From report at bugs.python.org Thu Sep 27 16:59:42 2007
From: report at bugs.python.org (Peter Harris)
Date: Thu, 27 Sep 2007 14:59:42 -0000
Subject: [New-bugs-announce] [issue1211] cleanup patch for 3.0
tutorial/interpreter.rst
Message-ID: <1190905181.89.0.902267878315.issue1211@psf.upfronthosting.co.za>
New submission from Peter Harris:
Proposed cleanup patch for tutorial/interpreter.rst
----------
components: Documentation
files: interpreter.diff
messages: 56164
nosy: scav
severity: normal
status: open
title: cleanup patch for 3.0 tutorial/interpreter.rst
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1211>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interpreter.diff
Type: application/octet-stream
Size: 2197 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070927/589afca7/attachment.obj
From report at bugs.python.org Thu Sep 27 17:09:34 2007
From: report at bugs.python.org (Peter Harris)
Date: Thu, 27 Sep 2007 15:09:34 -0000
Subject: [New-bugs-announce] [issue1212] 3.0 tutorial/introduction.rst
mentions 'long'
Message-ID: <1190905773.75.0.769437858357.issue1212@psf.upfronthosting.co.za>
New submission from Peter Harris:
Remove reference to 'long' in tutorial/introduction.rst.
Patch attached.
----------
components: Documentation
files: introduction.diff
messages: 56165
nosy: scav
severity: normal
status: open
title: 3.0 tutorial/introduction.rst mentions 'long'
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1212>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: introduction.diff
Type: application/octet-stream
Size: 566 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070927/0c753b60/attachment.obj
From report at bugs.python.org Thu Sep 27 17:44:39 2007
From: report at bugs.python.org (Peter Harris)
Date: Thu, 27 Sep 2007 15:44:39 -0000
Subject: [New-bugs-announce] [issue1213] 3.0 tutorial/classes.rst patch
Message-ID: <1190907879.6.0.718273481834.issue1213@psf.upfronthosting.co.za>
New submission from Peter Harris:
I think this wording is a little clearer and removes implied reference
to earlier Python versions, while still giving a simplistic
tutorial-level idea of what the MRO is. YMMV, so please disregard if
I've made it worse.
----------
components: Documentation
files: classes.diff
messages: 56166
nosy: scav
severity: normal
status: open
title: 3.0 tutorial/classes.rst patch
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1213>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: classes.diff
Type: application/octet-stream
Size: 1697 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070927/a916b18e/attachment.obj
From report at bugs.python.org Thu Sep 27 18:25:56 2007
From: report at bugs.python.org (steenie)
Date: Thu, 27 Sep 2007 16:25:56 -0000
Subject: [New-bugs-announce] [issue1214] Timeout in CGIXMLRPCRequestHandler
under IIS
Message-ID: <1190910356.54.0.93332478952.issue1214@psf.upfronthosting.co.za>
New submission from steenie:
Using CGIXMLRPCRequestHandler results in a timeout if running behind
Internet Information Server/CGI. Maybe there is no eof on sys.stdin
under IIS and python continues to read even if there is no more data
available. The same runs without problems under Apache/CGI.
Reading only os.environ['CONTENT_LENGTH'] bytes from sys.stdin will as
well work under IIS (see patch).
----------
components: Windows
files: SimpleXMLRPCServer.diff
messages: 56168
nosy: steenie
severity: normal
status: open
title: Timeout in CGIXMLRPCRequestHandler under IIS
versions: Python 2.5, Python 2.6
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1214>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleXMLRPCServer.diff
Type: text/x-patch
Size: 647 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070927/8ecb9ab4/attachment.bin
From report at bugs.python.org Thu Sep 27 19:05:24 2007
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 27 Sep 2007 17:05:24 -0000
Subject: [New-bugs-announce] [issue1215] Python hang when catching a segfault
Message-ID: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
New submission from Miki Tebeka:
The following code hangs Python:
#!/usr/bin/env python
import segfault
import signal
from os import _exit
from sys import stdout
def handler(signal, stackframe):
print "OUCH"
stdout.flush()
_exit(1)
if __name__ == "__main__":
from sys import argv
signal.signal(signal.SIGSEGV, handler)
segfault.segfault()
segfault is the following C module:
#include <Python.h>
static PyObject *
segfault(PyObject *self, PyObject *args)
{
char *c;
c = 0;
*c = 'a';
return Py_BuildValue("");
}
static PyMethodDef Methods[] = {
{ "segfault", segfault, METH_VARARGS, "will segfault"},
{NULL, NULL, 0, NULL} /* Sentinel */
};
PyMODINIT_FUNC
initsegfault(void)
{
Py_InitModule("segfault", Methods);
}
----------
components: Interpreter Core
messages: 56169
nosy: tebeka
severity: normal
status: open
title: Python hang when catching a segfault
type: crash
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
__________________________________
From report at bugs.python.org Thu Sep 27 19:54:12 2007
From: report at bugs.python.org (Karthik Rajagopalan)
Date: Thu, 27 Sep 2007 17:54:12 -0000
Subject: [New-bugs-announce] [issue1216] Python2.5.1 fails to compile under
VC.NET2002 ( 7.0 )
Message-ID: <1190915652.22.0.762495234548.issue1216@psf.upfronthosting.co.za>
New submission from Karthik Rajagopalan:
Hi,
We see following compiler error when 'Python2.5.1' is compiled under
VC.NET 2002 ( 7.0.9466 ). This happens in 'pythoncore' project:
<ERROR>
------ Build started: Project: pythoncore, Configuration: Release
Win32 ------
Compiling...
zutil.c
....
....
sha512module.c
\python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2059:
syntax error : 'bad suffix on number'
\python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2146:
syntax error : missing ')' before identifier 'L'
\python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2144:
syntax error : '<Unknown>' should be preceded by '<Unknown>'
\python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2144:
syntax error : '<Unknown>' should be preceded by '<Unknown>'
\python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2143:
syntax error : missing ')' before 'identifier'
\python-build\Python-2.5.1\Modules\sha512module.c(146) : error C2059:
syntax error : 'bad suffix on number'
</ERROR>
The fix for the above problem is given below where _MSC_VER is
increased more than 1300 that has LL and ULL literal suffix. VC.NET2002
is a C89 compiler and it doesn't have LL and ULL support.
/* VC 7.1 has them and VC 6.0 does not. VC 6.0 has a version number of
1200.
Microsoft eMbedded Visual C++ 4.0 has a version number of 1201 and
doesn't
define these.
If some compiler does not provide them, modify the #if
appropriately. */
#if defined(_MSC_VER)
#if _MSC_VER > 1300
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#else
/* VC6 & eVC4 don't support the C99 LL suffix for 64-bit integer
literals */
#define Py_LL(x) x##I64
#define Py_ULL(x) Py_LL(x##U)
#endif /* _MSC_VER > 1300 */
#endif /* _MSC_VER */
#endif
Please let me know your comments and if the fix looks rights, please
incorporate in your future release.
-Karthik Rajagopalan
D.E.Shaw India Software Pvt Ltd
----------
messages: 56176
nosy: kartlee
severity: normal
status: open
title: Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )
type: compile error
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1216>
__________________________________
From report at bugs.python.org Thu Sep 27 21:27:17 2007
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 27 Sep 2007 19:27:17 -0000
Subject: [New-bugs-announce] [issue1218] Restrict Google search to docs when
in the docs subtree?
Message-ID: <1190921237.18.0.0623041657599.issue1218@psf.upfronthosting.co.za>
New submission from Skip Montanaro:
It was reported to webmaster at python.org today that Thomas Heller's
pyhelp.cgi script is not available (yields 403 Forbidden). For the
time being I removed that link from http://www.python.org/doc/.
Still, there is the Google search box at the top of the page. Alas,
that only restricts the search to www.python.org. It would be nice if
on those pages under the /doc/... tree the relevant parameter
(sitesearch?) restricted the search to the doc tree. Can this be done
easily?
(On a related note, shouldn't the website be listed as a separate
component in the classification section?)
----------
components: Documentation
messages: 56179
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Restrict Google search to docs when in the docs subtree?
type: behavior
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1218>
__________________________________
From report at bugs.python.org Thu Sep 27 21:18:55 2007
From: report at bugs.python.org (=?utf-8?q?=0A=09=09=09=09=09Andres_Riancho=0A=09=09=09=09?=)
Date: Thu, 27 Sep 2007 19:18:55 -0000
Subject: [New-bugs-announce] [issue1217] infinite loop in re module
Message-ID: <1190920735.17.0.528461177884.issue1217@psf.upfronthosting.co.za>
New submission from
Andres Riancho
:
dz0 at dz0cybsec:/tmp$ python
Python 2.4.4 (#2, Aug 16 2007, 02:03:40)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.findall( '.*://(.*):(.*)@.*' , file('a.txt').read() )
===!infinite loop here!===
===!execute "kill pid"!===
Terminated
dz0 at dz0cybsec:/tmp$
dz0 at dz0cybsec:/tmp$ dpkg -l python
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version
Description
+++-=================================-=================================-==================================================================================
ii python 2.4.4-6
An interactive high-level object-oriented language (default version)
dz0 at dz0cybsec:/tmp$
dz0 at dz0cybsec:/tmp$ uname -a
Linux dz0cybsec 2.6.21-2-k7 #1 SMP Wed Jul 11 04:29:08 UTC 2007 i686
GNU/Linux
dz0 at dz0cybsec:/tmp$
See attached a.txt file.
----------
components: Regular Expressions
files: a.txt
messages: 56178
nosy: andresriancho
severity: normal
status: open
title: infinite loop in re module
type: resource usage
versions: Python 2.4
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1217>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a.txt
Url: http://mail.python.org/pipermail/new-bugs-announce/attachments/20070927/fd7c8e91/attachment-0001.txt
From report at bugs.python.org Fri Sep 28 13:07:32 2007
From: report at bugs.python.org (Peter Harris)
Date: Fri, 28 Sep 2007 11:07:32 -0000
Subject: [New-bugs-announce] [issue1219] 3.0 library/stdtypes.rst patch
Message-ID: <1190977652.36.0.432494906754.issue1219@psf.upfronthosting.co.za>
New submission from Peter Harris:
Cleanup (removal of 2.x references, long etc. ). I'm not 100% sure I've
got the rich-comparison stuff correct.
----------
components: Documentation
files: stdtypes.diff
messages: 56186
nosy: scav
severity: normal
status: open
title: 3.0 library/stdtypes.rst patch
versions: Python 3.0
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1219>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdtypes.diff
Type: application/octet-stream
Size: 11433 bytes
Desc: not available
Url : http://mail.python.org/pipermail/new-bugs-announce/attachments/20070928/22596581/attachment.obj
From report at bugs.python.org Sun Sep 30 05:27:54 2007
From: report at bugs.python.org (Justin Bronn)
Date: Sun, 30 Sep 2007 03:27:54 -0000
Subject: [New-bugs-announce] [issue1220] popen3 website documentation
inconsistency
Message-ID: <1191122873.79.0.547825097703.issue1220@psf.upfronthosting.co.za>
New submission from Justin Bronn:
The Python website says that the following tuple is returned from
popen3: "Returns the file objects (child_stdout, child_stdin,
child_stderr)." See http://docs.python.org/lib/module-popen2.html.
However, the docstring of popen3 gets the order right (using Python 2.5.1):
"The file objects (child_stdin, child_stdout, child_stderr) are
returned." See `help(os.popen3)`.
----------
components: Documentation
messages: 56198
nosy: jbronn
severity: normal
status: open
title: popen3 website documentation inconsistency
versions: Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220>
__________________________________
From report at bugs.python.org Sun Sep 30 14:39:04 2007
From: report at bugs.python.org (helmut)
Date: Sun, 30 Sep 2007 12:39:04 -0000
Subject: [New-bugs-announce] [issue1221] email.Utils.parseaddr("a(WRONG)@b")
Message-ID: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za>
New submission from helmut:
>>> email.Utils.parseaddr("a(WRONG)@b")
('WRONG WRONG', 'a at b')
I believe this is wrong.
----------
components: Library (Lib)
messages: 56199
nosy: helmut
severity: normal
status: open
title: email.Utils.parseaddr("a(WRONG)@b")
type: behavior
versions: Python 2.4, Python 2.5
__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1221>
__________________________________