From report at bugs.python.org Tue Jul 1 02:10:51 2008 From: report at bugs.python.org (vizcayno) Date: Tue, 01 Jul 2008 00:10:51 +0000 Subject: [New-bugs-announce] [issue3247] dir of an "_sre.SRE_Match" object not working In-Reply-To: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za> Message-ID: <1214871051.34.0.403559137594.issue3247@psf.upfronthosting.co.za> New submission from vizcayno : For Windows XP SP3: v = 'add 1 to 4.56' import re r=re.search("([0-9]+)\D+(\d+\.\d+)","add 1 to 4.56") r <_sre.SRE_Match object at 0x00BED920> r.groups() ('1', '4.56') dir(r) [] in pyhton 2.5 it shows: ['__copy__', '__deepcopy__', 'end', 'expand', 'group', 'groupdict', 'gro ups', 'span', 'start'] ---------- components: Regular Expressions messages: 69031 nosy: vizcayno severity: normal status: open title: dir of an "_sre.SRE_Match" object not working type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 02:46:14 2008 From: report at bugs.python.org (Guilherme Polo) Date: Tue, 01 Jul 2008 00:46:14 +0000 Subject: [New-bugs-announce] [issue3248] ScrolledText can't be placed in a PanedWindow In-Reply-To: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> Message-ID: <1214873174.02.0.0621752990515.issue3248@psf.upfronthosting.co.za> New submission from Guilherme Polo : Right now ScrolledText can't be added to a Tkinter.PanedWindow, also can't be added to a ttk.Notebook (which is not part of the stdlib), because it is a lacking a proper __str__ method. Run the following sample code to check how it fails: import Tkinter import ScrolledText paned = Tkinter.PanedWindow() stext = ScrolledText.ScrolledText(paned) paned.add(stext) ---------- components: Tkinter files: scrolledtext_masterstr.diff keywords: patch messages: 69037 nosy: gpolo severity: normal status: open title: ScrolledText can't be placed in a PanedWindow versions: Python 2.6 Added file: http://bugs.python.org/file10787/scrolledtext_masterstr.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 11:19:14 2008 From: report at bugs.python.org (Chris Withers) Date: Tue, 01 Jul 2008 09:19:14 +0000 Subject: [New-bugs-announce] [issue3249] bug adding datetime.timedelta to datetime.date In-Reply-To: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za> Message-ID: <1214903954.23.0.462888022865.issue3249@psf.upfronthosting.co.za> New submission from Chris Withers : The following demonstrates the problem: >>> from datetime import datetime,timedelta >>> datetime.now().date()+timedelta(hours=1) datetime.date(2008, 7, 1) I'd expect the above to either result in a TypeError or (preferably) datetime.datetime(2008, 7, 1, 1, 0) ---------- components: Library (Lib) messages: 69041 nosy: cjw296 severity: normal status: open title: bug adding datetime.timedelta to datetime.date versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 11:49:00 2008 From: report at bugs.python.org (Chris Withers) Date: Tue, 01 Jul 2008 09:49:00 +0000 Subject: [New-bugs-announce] [issue3250] datetime.time does not support arithmetic In-Reply-To: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za> Message-ID: <1214905740.54.0.833672968887.issue3250@psf.upfronthosting.co.za> New submission from Chris Withers : >>> from datetime import time >>> time(9,0)-time(8,0) Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for -: 'datetime.time' and 'datetime.time' I'd expect a datetime.timedelta(0,3600) ---------- components: Library (Lib) messages: 69042 nosy: cjw296 severity: normal status: open title: datetime.time does not support arithmetic versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 15:55:15 2008 From: report at bugs.python.org (Wolfgang Langner) Date: Tue, 01 Jul 2008 13:55:15 +0000 Subject: [New-bugs-announce] [issue3251] references are case insensitive In-Reply-To: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za> Message-ID: <1214920515.1.0.0323158580641.issue3251@psf.upfronthosting.co.za> New submission from Wolfgang Langner : References can be added case sensitive as .. _myRef: but only used case insensitive with :ref:`myref` usage of :ref:`myRef` doesn't generate a working reference. Make this behavior consistent please, always case insensitive or always case sensitive. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 69045 nosy: georg.brandl, tds333 severity: normal status: open title: references are case insensitive _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 17:39:12 2008 From: report at bugs.python.org (Mark Summerfield) Date: Tue, 01 Jul 2008 15:39:12 +0000 Subject: [New-bugs-announce] [issue3252] str.tobytes() and bytes/bytearray.tostr() In-Reply-To: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za> Message-ID: <1214926752.5.0.120483296731.issue3252@psf.upfronthosting.co.za> New submission from Mark Summerfield : I know it is almost certainly too late, but I think a lot of people will be confused by str.decode() and bytes.encode() (or was that the other way around)? Calling the methods str.tobytes() and bytes.tostr() (or nicer, str.to_bytes() and bytes.to_str()) would be hard to confuse and IMO will lead to fewer bug reports and complaints once Python 3.0 final comes out. And there is a kind of precedent in that threading.isDaemon() became threading.is_daemon() between 30a5 and 30b1. ---------- components: Interpreter Core messages: 69047 nosy: mark severity: normal status: open title: str.tobytes() and bytes/bytearray.tostr() type: feature request versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 19:35:09 2008 From: report at bugs.python.org (grissiom) Date: Tue, 01 Jul 2008 17:35:09 +0000 Subject: [New-bugs-announce] [issue3253] shutil.move bahave unexpected in fat32 In-Reply-To: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za> Message-ID: <1214933709.34.0.0595495782723.issue3253@psf.upfronthosting.co.za> New submission from grissiom : Build the environment in a fat32 file system: $echo test > test_move $mkdir testmove If I shutil.move('test_move', 'testmove'), it will raise: Traceback (most recent call last): File "testmove.py", line 5, in shutil.move('test_move', 'test_python') File "/usr/lib/python2.5/shutil.py", line 199, in move copy2(src,dst) File "/usr/lib/python2.5/shutil.py", line 92, in copy2 copystat(src, dst) File "/usr/lib/python2.5/shutil.py", line 69, in copystat os.chmod(dst, mode) OSError: [Errno 1] Operation not permitted: 'test_python/test_move' If I shutil.move('test_move', 'testmove/testmove'), it will succeed quietly. This problem doesn't happen in an ext3 file system. ---------- components: Library (Lib) messages: 69053 nosy: grissiom severity: normal status: open title: shutil.move bahave unexpected in fat32 type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 1 23:36:18 2008 From: report at bugs.python.org (cvp) Date: Tue, 01 Jul 2008 21:36:18 +0000 Subject: [New-bugs-announce] [issue3254] Suggestion: change default behavior of __ne__ In-Reply-To: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za> Message-ID: <1214948178.75.0.219769334273.issue3254@psf.upfronthosting.co.za> New submission from cvp : After defining my own __eq__ method for a class that judged equality based on a 'name' variable, imagine my surprise to see this: In [20]: my_graph.edges[-1].end == my_graph.vertices[-1] Out [20]: True In [21]: my_graph.edges[-1].end != my_graph.vertices[-1] Out [21]: True ...all because I forgot to modify __ne__ as well. I think __ne__ should be changed to 'not __eq__' for the sake of consistency. ---------- messages: 69078 nosy: cvp severity: normal status: open title: Suggestion: change default behavior of __ne__ type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 10:43:13 2008 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Wed, 02 Jul 2008 08:43:13 +0000 Subject: [New-bugs-announce] [issue3255] [proposal] alternative for re.sub In-Reply-To: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za> Message-ID: <1214988192.81.0.533532272888.issue3255@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : I often do same mistake again and again. Most of re module's method takes optional argument "flags" like this. finditer( pattern, string[, flags]) But, sub() takes optional argument "count" not "flags". sub( pattern, repl, string[, count]) So, when I write this code, it doesn't behave like what I want. re.sub("<[^>]+>", "", content, re.S) I think it would be nice if the method which takes optional argument "flags" and do same behavior with re.compile(pattern[, flags]).sub(repl, string). Thank you. ---------- components: Regular Expressions messages: 69087 nosy: ocean-city severity: normal status: open title: [proposal] alternative for re.sub type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 15:32:19 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Wed, 02 Jul 2008 13:32:19 +0000 Subject: [New-bugs-announce] [issue3256] Multiprocessing docs are not 3.0-ready In-Reply-To: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za> Message-ID: <1215005539.48.0.894176779867.issue3256@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : Multiprocessing docs contain examples, that are not valid py3k code, mostly because of print used as a statement. Example (taken from multiprocessing.rst): from multiprocessing import Process def f(name): print 'hello', name if __name__ == '__main__': p = Process(target=f, args=('bob',)) p.start() p.join() If no one is working on this already, than I'll start fixing this and will present a patch in 2 or 3 days. ---------- assignee: georg.brandl components: Documentation messages: 69090 nosy: georg.brandl, jnoller, mishok13, roudkerk severity: normal status: open title: Multiprocessing docs are not 3.0-ready versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 16:42:43 2008 From: report at bugs.python.org (fgoujeon) Date: Wed, 02 Jul 2008 14:42:43 +0000 Subject: [New-bugs-announce] [issue3257] "#define socklen_t int" in pyconfig.h In-Reply-To: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za> Message-ID: <1215009763.56.0.986428726612.issue3257@psf.upfronthosting.co.za> New submission from fgoujeon : Hello all, I'm using MinGW 4.2.1 and was unable to compile my code when including pyconfig.h. The culpables are these lines (from line 428): /* Define to `int' if doesn't define. */ #if 1 //_MSC_VER + 0 >= 1300 /* VC.NET typedefs socklen_t in ws2tcpip.h. */ #else #define socklen_t int #endif MinGW (at least the version I use) typedefs socklen_t too, in ws2tcpip.h (at line 272): typedef int socklen_t; When the #define takes effect, code becomes: typedef socklen_t socklen_t; ...which leads to a compile error (really hard to understand): C:/MinGW/include/ws2tcpip.h:272: error: multiple types in one declaration I hope these details will be useful for you. I'm available for another questions. Thanks! ---------- components: Library (Lib) messages: 69097 nosy: fgoujeon severity: normal status: open title: "#define socklen_t int" in pyconfig.h type: compile error versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 18:28:05 2008 From: report at bugs.python.org (Tim Golden) Date: Wed, 02 Jul 2008 16:28:05 +0000 Subject: [New-bugs-announce] [issue3258] ctypes assertion failure in trunk In-Reply-To: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za> Message-ID: <1215016085.03.0.206242811608.issue3258@psf.upfronthosting.co.za> New submission from Tim Golden : The following code raises an Assertion Failure under debug in r64518 running on Windows XP SP2: import ctypes class X (ctypes.Structure): pass ctypes.POINTER (X) Assertion failed: PyErr_Occurred(), file ..\Modules\_ctypes\_ctypes.c, line 309 ---------- assignee: theller components: ctypes messages: 69102 nosy: theller, tim.golden severity: normal status: open title: ctypes assertion failure in trunk type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 21:54:08 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Jul 2008 19:54:08 +0000 Subject: [New-bugs-announce] [issue3259] fix_imports needs to be using the 'as' keyword In-Reply-To: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za> Message-ID: <1215028447.57.0.637458413942.issue3259@psf.upfronthosting.co.za> New submission from Brett Cannon : If you run ``echo "import commands" | ./2to3 -f imports -``, you end up with ``import subprocess``. That's bad as the code in the module works off of 'commands'. The fix really should be ``import subprocess as commands``. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 69113 nosy: brett.cannon, collinwinter priority: critical severity: normal status: open title: fix_imports needs to be using the 'as' keyword _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 22:02:15 2008 From: report at bugs.python.org (Brett Cannon) Date: Wed, 02 Jul 2008 20:02:15 +0000 Subject: [New-bugs-announce] [issue3260] fix_imports does not handle intra-package renames In-Reply-To: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za> Message-ID: <1215028935.08.0.401449015598.issue3260@psf.upfronthosting.co.za> New submission from Brett Cannon : ``from test import test_support`` should lead to ``from test import support as test_support``. Also does not work for ``from test.test_support import Error``. There is also no good way to handle ``import test.test_support`` since ``import test.test_support as test.support`` is an error. Perhaps ``import test.support; test.test_support = support``? At the moment test.support is the only rename like this, so it is not critical that this be fixed immediately as probably few people use the module outside of the stdlib. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 69114 nosy: brett.cannon, collinwinter priority: high severity: normal status: open title: fix_imports does not handle intra-package renames type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 2 22:06:54 2008 From: report at bugs.python.org (Leonardo Soto) Date: Wed, 02 Jul 2008 20:06:54 +0000 Subject: [New-bugs-announce] [issue3261] Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes In-Reply-To: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za> Message-ID: <1215029214.12.0.399957478898.issue3261@psf.upfronthosting.co.za> New submission from Leonardo Soto : http://svn.python.org/projects/python/branches/release25-maint/Lib/test/test_cookielib.py contains non-utf8 bytes. Currently, That confuses Jython. ---------- messages: 69115 nosy: leosoto severity: normal status: open title: Lib/test/test_cookielib declares utf-8 encoding, but contains non-valid bytes versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 00:07:49 2008 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 02 Jul 2008 22:07:49 +0000 Subject: [New-bugs-announce] [issue3262] re.split doesn't split with zero-width regex In-Reply-To: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za> Message-ID: <1215036469.9.0.581701421463.issue3262@psf.upfronthosting.co.za> New submission from Matthew Barnett : re.split doesn't split a string when the regex matches a zero characters. For example: re.split(r'\b', 'a b') returns ['a b'] instead of ['', 'a', ' ', 'b', '']. re.split(r'(? _______________________________________ From report at bugs.python.org Thu Jul 3 01:06:54 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Jul 2008 23:06:54 +0000 Subject: [New-bugs-announce] [issue3263] Odd code fragment in ABC definitions In-Reply-To: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za> Message-ID: <1215040014.35.0.00933223845259.issue3263@psf.upfronthosting.co.za> New submission from Raymond Hettinger : In the Hashable ABC, there is a peculiar code fragment: if "__hash__" in B.__dict__: if B.__dict__["__hash__"]: return True break When would the innermost if-statement ever be False? Is there a reason to define __hash__ to be something that evaluates to False? ---------- assignee: gvanrossum messages: 69140 nosy: gvanrossum, rhettinger severity: normal status: open title: Odd code fragment in ABC definitions versions: Python 2.5, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 01:12:02 2008 From: report at bugs.python.org (Martin Mokrejs) Date: Wed, 02 Jul 2008 23:12:02 +0000 Subject: [New-bugs-announce] [issue3264] Use -lcrypto instead of -lcrypt on Solaris 2.6 when available In-Reply-To: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za> Message-ID: <1215040322.48.0.501787907219.issue3264@psf.upfronthosting.co.za> New submission from Martin Mokrejs : Hi, although the issues libraries to be created with -fpic are known I still do believe ./config could do something here: building 'crypt' extension gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o -L/usr/local/lib -lcrypt -o build/lib.solaris-2.6-sun4u-2.5/crypt.so Text relocation remains referenced against symbol offset in file _des_setkey 0x4 /usr/lib/libcrypt.a(crypt.o) _des_encrypt 0x10 /usr/lib/libcrypt.a(crypt.o) _des_crypt 0x1c /usr/lib/libcrypt.a(crypt.o) 0x4 /usr/lib/libcrypt.a(des_crypt.o) 0x8 /usr/lib/libcrypt.a(des_crypt.o) ... ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status # gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/cryptmodule.o -L/usr/local/lib -lcrypto -o build/lib.solaris-2.6-sun4u-2.5/crypt.so # ---------- components: Build messages: 69144 nosy: mmokrejs severity: normal status: open title: Use -lcrypto instead of -lcrypt on Solaris 2.6 when available versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 02:07:46 2008 From: report at bugs.python.org (Martin Mokrejs) Date: Thu, 03 Jul 2008 00:07:46 +0000 Subject: [New-bugs-announce] [issue3265] Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared In-Reply-To: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za> Message-ID: <1215043666.75.0.766151712273.issue3265@psf.upfronthosting.co.za> New submission from Martin Mokrejs : Hi, when building on Solaris 2.6 with gcc I get the following error: building '_ctypes' extension gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callbacks.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.o /usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c: In function `_CallProc': /usr/scratch/Python-2.5.2/Modules/_ctypes/callproc.c:921: warning: implicit declaration of function `alloca' gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/stgdict.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/cfield.o gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi/include -Ibuild/temp.solaris-2.6-sun4u-2.5/libffi -I/usr/scratch/Python-2.5.2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.o /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c: In function `more_core': /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared (first use in this function) /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: (Each undeclared identifier is reported only once /usr/scratch/Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: for each function it appears in.) building '_ctypes_test' extension gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o gcc -shared -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/_ctypes/_ctypes_test.o -L/usr/local/lib -o build/lib.solaris-2.6-sun4u-2.5/_ctypes_test.so Let me add that I see -fPIC in the top-level Makefile but do not know why -static is not in the same variable as well. Anyway, it is not a shared library problem I think as I already recompiled my bzip2, openssl and ncurses libs with "-shared -fpic". ;-) ---------- messages: 69152 nosy: mmokrejs severity: normal status: open title: Python-2.5.2/Modules/_ctypes/malloc_closure.c:70: error: `MAP_ANONYMOUS' undeclared versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 02:14:14 2008 From: report at bugs.python.org (Martin Mokrejs) Date: Thu, 03 Jul 2008 00:14:14 +0000 Subject: [New-bugs-announce] [issue3266] Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared In-Reply-To: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za> Message-ID: <1215044054.48.0.722645405249.issue3266@psf.upfronthosting.co.za> New submission from Martin Mokrejs : Some typo in the sources showing up on Solaris 2.6 only? building 'mmap' extension gcc -shared -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/scratch/Python-2.5.2/./Include -I. -IInclude -I./Include -I/usr/local/include -I/usr/scratch/Python-2.5.2/Include -I/usr/scratch/Python-2.5.2 -c /usr/scratch/Python-2.5.2/Modules/mmapmodule.c -o build/temp.solaris-2.6-sun4u-2.5/usr/scratch/Python-2.5.2/Modules/mmapmodule.o /usr/scratch/Python-2.5.2/Modules/mmapmodule.c: In function `new_mmap_object': /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: warning: implicit declaration of function `open' /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared (first use in this function) /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: (Each undeclared identifier is reported only once /usr/scratch/Python-2.5.2/Modules/mmapmodule.c:915: error: for each function it appears in.) ---------- components: Build messages: 69153 nosy: mmokrejs severity: normal status: open title: Python-2.5.2/Modules/mmapmodule.c:915: error: `O_RDWR' undeclared versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 08:28:19 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Thu, 03 Jul 2008 06:28:19 +0000 Subject: [New-bugs-announce] [issue3267] yield in list comprehensions possibly broken in 3.0 In-Reply-To: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za> Message-ID: <1215066499.8.0.630576860475.issue3267@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : This may be a known consequence of python 3.0, but I couldn't find any reference to it, nor a test case that covers it. Here's a valid use of yield in 2.5.1: >>> def foo(): ... x=[(yield x) for x in 1,2,3] ... yield 5 ... yield x >>> x=foo() >>> x.next() 1 >>> x.send(6) 2 >>> x.send(7) 3 >>> x.send(8) 5 >>> x.send(9) [6, 7, 8] >>> x.send(10) Traceback (most recent call last): File "", line 1, in StopIteration But in python 3.0, this code results in: >>> def foo(): ... x=[(yield x) for x in (1,2,3)] ... yield 5 ... yield x >>> x=foo() >>> next(x) 5 >>> x.send(6) at 0x3678f0> >>> x.send(7) Traceback (most recent call last): File "", line 1, in StopIteration Looking further, it seems that this is a comprehension: >>> def foo(): [(yield 5)] >>> type(foo()) Whereas this is not: >>> def foo(): [(yield 5) for x in range(3)] >>> type(foo()) Is this expected behavior? ---------- components: Interpreter Core messages: 69168 nosy: erickt severity: normal status: open title: yield in list comprehensions possibly broken in 3.0 versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 08:31:39 2008 From: report at bugs.python.org (Adam Olsen) Date: Thu, 03 Jul 2008 06:31:39 +0000 Subject: [New-bugs-announce] [issue3268] Cleanup of tp_basicsize inheritance In-Reply-To: <1215066698.99.0.380668265624.issue3268@psf.upfronthosting.co.za> Message-ID: <1215066698.99.0.380668265624.issue3268@psf.upfronthosting.co.za> New submission from Adam Olsen : inherit_special contains logic to inherit the base type's tp_basicsize if the new type doesn't have it set. The logic was spread over several lines, but actually does almost nothing (presumably an artifact of previous versions), so here's a patch to clean it up. There was also an incorrect comment which I've removed. A new one should perhaps be added explaining what the other code there does, but it's not affected by what I'm changing, and I'm not sure why it's doing what it's doing anyway, so I'll leave that to someone else. ---------- files: python-inheritsize.diff keywords: patch messages: 69169 nosy: Rhamphoryncus, nnorwitz severity: normal status: open title: Cleanup of tp_basicsize inheritance Added file: http://bugs.python.org/file10798/python-inheritsize.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 13:47:36 2008 From: report at bugs.python.org (=?utf-8?q?Neven_Gor=C5=A1i=C4=87?=) Date: Thu, 03 Jul 2008 11:47:36 +0000 Subject: [New-bugs-announce] [issue3269] strptime() makes an error concerning second in arg In-Reply-To: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za> Message-ID: <1215085656.87.0.45612671084.issue3269@psf.upfronthosting.co.za> New submission from Neven Gor?i? : strptime() allows 60 and 61 sec, but not 62 sec in arg. string >>> s='02/28/2000 12:33:61 AM' >>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p') (2000, 2, 28, 0, 33, 61, 0, 59, -1) >>> s='02/28/2000 12:33:62 AM' >>> time.strptime(s,'%m/%d/%Y %I:%M:%S %p') Traceback (most recent call last): File "", line 1, in time.strptime(s,'%m/%d/%Y %I:%M:%S %p') File "C:\Python25\lib\_strptime.py", line 330, in strptime (data_string, format)) ValueError: time data did not match format: data=02/28/2000 12:33:62 AM fmt=%m/%d/%Y %I:%M:%S %p ---------- components: None messages: 69192 nosy: nevgor severity: normal status: open title: strptime() makes an error concerning second in arg type: compile error versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 14:58:44 2008 From: report at bugs.python.org (Jesse Noller) Date: Thu, 03 Jul 2008 12:58:44 +0000 Subject: [New-bugs-announce] [issue3270] test_multiprocessing: test_listener_client flakiness In-Reply-To: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za> Message-ID: <1215089924.76.0.76828097682.issue3270@psf.upfronthosting.co.za> New submission from Jesse Noller : Per mail thread: http://mail.python.org/pipermail/python-dev/2008-June/080497.html Attached is the patch to connection.py to drop the fqdn call. Final suggestion from Trent: > This is a common problem. Binding to '127.0.0.1' will bind to *only* > that address; Indeed. > binding to "" will bind to *all* addresses the machine > is known by. Agreed again. I believe what we're dealing with here though is a lack of clarity regarding what role the 'address' attribute exposed by multiprocess.connection.Listener should play. The way test_listener_client() is written, it effectively treats 'address' as an end-point that can be connected to directly (irrespective of the underlying family (i.e. AF_INET, AF_UNIX, AF_PIPE)). I believe the problems we've run into stem from the fact that the API doesn't provide any guarantees as to what 'address' represents. The test suite assumes it always reflects a connectable end-point, which I think is more than reasonable. Unfortunately, nothing stops us from breaking this invariant by constructing the object as Listener(family='AF_INET', address=('0.0.0.0', 0)). How do I connect to an AF_INET Listener (i.e. SocketListener) instance whose 'address' attribute reports '0.0.0.0' as the host? I can't. So, for now, I think we should enforce this invariant by raising an exception in Listener.__init__() if self._socket.getsockbyname()[0] returns '0.0.0.0'. In effect, tightening up the API such that we can guarantee Listener.address will always represent a connectable end- point. We can look at how to service 'listen on all available interfaces' semantics at a later date -- that adds far less value IMO than being able to depend on the said guarantee. ---------- assignee: jnoller components: Library (Lib) files: connection.patch keywords: patch messages: 69197 nosy: jnoller, roudkerk priority: high severity: normal status: open title: test_multiprocessing: test_listener_client flakiness versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10801/connection.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 17:10:00 2008 From: report at bugs.python.org (vizcayno) Date: Thu, 03 Jul 2008 15:10:00 +0000 Subject: [New-bugs-announce] [issue3271] iter.next() or iter.__next__() ? In-Reply-To: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za> Message-ID: <1215097800.56.0.268941545187.issue3271@psf.upfronthosting.co.za> New submission from vizcayno : For Win XP SP3 I do next in py30.b1: a=[9,8,1,2] it=iter(a) it.next() Traceback (most recent call last): File "", line 1, in AttributeError: 'list_iterator' object has no attribute 'next' but doing: it.__next__() 9 it.__next__() 8 it is ok. However, manual of Py3.0 indicates iter.next() as valid. Python 25 does not accept "it.__next__()" but "it.next()" Regards. ---------- assignee: georg.brandl components: Documentation messages: 69205 nosy: georg.brandl, vizcayno severity: normal status: open title: iter.next() or iter.__next__() ? type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 18:48:38 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Thu, 03 Jul 2008 16:48:38 +0000 Subject: [New-bugs-announce] [issue3272] Multiprocessing hangs when multiprocessing.Pool methods are called In-Reply-To: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za> Message-ID: <1215103718.59.0.127699249536.issue3272@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : `multiprocessing` hangs, when `multiprocessing.Pool` methods `map`, `imap`, `imap_unordered`, `apply`, `apply_async`, `map_async` are called. Here is an example: Python 3.0b1+ (py3k:64686M, Jul 3 2008, 13:06:13) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from multiprocessing import Pool >>> Pool(processes=4).imap(lambda x: x, range(10)) >>> Pool(processes=4).map(lambda x: x, range(10)) Exception in thread Thread-13: Traceback (most recent call last): File "/usr/local/lib/python3.0/threading.py", line 492, in _bootstrap_inner self.run() File "/usr/local/lib/python3.0/threading.py", line 447, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 225, in _handle_tasks put(task) File "/usr/local/lib/python3.0/pickle.py", line 1319, in dumps Pickler(f, protocol).dump(obj) File "/usr/local/lib/python3.0/multiprocessing/util.py", line 311, in _reduce_method if m.__self__ is None: AttributeError: 'function' object has no attribute '__self__' Process PoolWorker-28: Traceback (most recent call last): File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232, in _bootstrap self.run() File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in worker task = get() File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337, in get Process PoolWorker-27: Traceback (most recent call last): File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232, in _bootstrap self.run() File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in worker task = get() File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337, in get Process PoolWorker-26: Traceback (most recent call last): File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232, in _bootstrap Process PoolWorker-25: Traceback (most recent call last): File "/usr/local/lib/python3.0/multiprocessing/process.py", line 232, in _bootstrap self.run() File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in worker task = get() File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 337, in get self.run() File "/usr/local/lib/python3.0/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.0/multiprocessing/pool.py", line 57, in worker task = get() File "/usr/local/lib/python3.0/multiprocessing/queues.py", line 339, in get return recv() KeyboardInterrupt racquire() KeyboardInterrupt racquire() KeyboardInterrupt racquire() KeyboardInterrupt Terminated The same happens on latest trunk of Python 2.6. Note, `map` and `apply` methods hang Python interpreter completely, so I have to use `kill` utility to exit Python. ---------- components: Library (Lib) messages: 69207 nosy: jnoller, mishok13, roudkerk severity: normal status: open title: Multiprocessing hangs when multiprocessing.Pool methods are called type: crash versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 19:03:29 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Thu, 03 Jul 2008 17:03:29 +0000 Subject: [New-bugs-announce] [issue3273] multiprocessing and meaningful errors In-Reply-To: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za> Message-ID: <1215104608.98.0.798137013067.issue3273@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : multiprocessing uses a lot of `assert` statements all over the code. I propose to change this way to a more readable and understandable. For example: Lib/multiprocessing/managers.py, line 136: assert isinstance(authkey, bytes) >From my point of view, raising an AssertionError is not enough in this case. I propose changing this one to more intuitive: if not isinstance(authkey, bytes): raise TypeError("'authkey' argument should be an instance of 'bytes'") (Well, maybe message could be more descriptive. :) ) And this goes for all of the multiprocessing code base. Should I consider writing a patch for this? ---------- components: Library (Lib) messages: 69208 nosy: jnoller, mishok13, roudkerk severity: normal status: open title: multiprocessing and meaningful errors type: feature request versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 19:54:09 2008 From: report at bugs.python.org (Daniel Stutzbach) Date: Thu, 03 Jul 2008 17:54:09 +0000 Subject: [New-bugs-announce] [issue3274] Py_CLEAR(tmp) seg faults In-Reply-To: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za> Message-ID: <1215107649.04.0.488182300536.issue3274@psf.upfronthosting.co.za> New submission from Daniel Stutzbach : I'm writing a C extension module and discovered that Py_CLEAR() causes a crash if the programmer happened to name their variable "tmp". The Py_CLEAR() macro internally uses the name "tmp" in a new scope, hiding the callers "tmp", and calling Py_DECREF() on an essentially random bit of memory. I suggest changing Py_CLEAR() to use something a little less common than "tmp". Perhaps "_py_tmp". For easy reference, here's how Py_CLEAR() is defined now: #define Py_CLEAR(op) \ do { \ if (op) { \ PyObject *tmp = (PyObject *)(op); \ (op) = NULL; \ Py_DECREF(tmp); \ } \ } while (0) ---------- components: Interpreter Core messages: 69213 nosy: stutzbach severity: normal status: open title: Py_CLEAR(tmp) seg faults type: crash versions: Python 2.5, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 3 22:43:13 2008 From: report at bugs.python.org (Daniel Colascione) Date: Thu, 03 Jul 2008 20:43:13 +0000 Subject: [New-bugs-announce] [issue3275] Control flow not optimized In-Reply-To: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za> Message-ID: <1215117793.84.0.876575778362.issue3275@psf.upfronthosting.co.za> New submission from Daniel Colascione : Consider: import dis def foo(): if 0 and 1: return "hi" dis.dis(foo) What I get is 2 0 LOAD_CONST 1 (0) 3 JUMP_IF_FALSE 15 (to 21) 6 POP_TOP 7 LOAD_CONST 2 (1) 10 JUMP_IF_FALSE 8 (to 21) 13 POP_TOP 14 LOAD_CONST 3 ('hi') 17 RETURN_VALUE 18 JUMP_FORWARD 1 (to 22) >> 21 POP_TOP >> 22 LOAD_CONST 0 (None) 25 RETURN_VALUE What I'd expect to see is: 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE ---------- components: Interpreter Core messages: 69230 nosy: quotemstr severity: normal status: open title: Control flow not optimized type: performance versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 02:19:29 2008 From: report at bugs.python.org (toxik) Date: Fri, 04 Jul 2008 00:19:29 +0000 Subject: [New-bugs-announce] [issue3276] httplib.HTTPConnection._send_request should not blindly assume dicts for headers In-Reply-To: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za> Message-ID: <1215130769.47.0.0230905543783.issue3276@psf.upfronthosting.co.za> New submission from toxik : Presently it's impossible to use httplib.HTTPConnection.request and send the several headers with the same name. This is because _send_request assumes a dict is passed in, or a dict-like interface. Obviously one could make a list subclass or some such and give it an iteritems that returns itself, but IMHO the solution is to fix httplib. Attached patch changes the current behavior to using iteritems only if it exists, otherwise iterate directly (which would fit with sequences of two- tuples). ---------- components: Library (Lib) files: httplib.py.diff keywords: patch messages: 69234 nosy: ludvig.ericson severity: normal status: open title: httplib.HTTPConnection._send_request should not blindly assume dicts for headers versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5 Added file: http://bugs.python.org/file10807/httplib.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 03:51:20 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 04 Jul 2008 01:51:20 +0000 Subject: [New-bugs-announce] [issue3277] socket's OOB data management is broken on FreeBSD In-Reply-To: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za> Message-ID: <1215136280.08.0.736342433953.issue3277@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : I've tried to run the code below on Windows XP and Linux Ubuntu and it works as expected. Here is the output: expt -> o read -> fo On FreeBSD 7.0 it raises the following exception: expt -> o read -> fo Exception in thread Thread-1: Traceback (most recent call last): File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap self.run() File "/usr/local/lib/python2.5/threading.py", line 440, in run self.__target(*self.__args, **self.__kwargs) File "_test2.py", line 13, in server data = conn.recv(1024, socket.MSG_OOB) error: (22, 'Invalid argument') --- code --- import socket, select, threading, time, os def server(): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('', 1024)) s.listen(1) conn, addr = s.accept() conn.setblocking(0) while 1: r, w, e = select.select([conn], [conn], [conn], 0.01) if e: data = conn.recv(1024, socket.MSG_OOB) print "expt -> " + data if r: data = conn.recv(1024) print "read -> " + data threading.Thread(target=server).start() time.sleep(0.1) s = socket.socket() s.connect(('127.0.0.1', 1024)) s.sendall('foo', socket.MSG_OOB) --- /code --- ---------- messages: 69236 nosy: giampaolo.rodola severity: normal status: open title: socket's OOB data management is broken on FreeBSD versions: Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 04:18:01 2008 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 04 Jul 2008 02:18:01 +0000 Subject: [New-bugs-announce] [issue3278] socket's SO_REUSEADDR option does not work on FreeBSD In-Reply-To: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za> Message-ID: <1215137881.67.0.331390936209.issue3278@psf.upfronthosting.co.za> New submission from Giampaolo Rodola' : When the SO_OOBINLINE option is used against a socket, out-of-band data should be placed in the normal data input stream as it is received. In fact this is what happens on Windows and Linux by using the script below. On FreeBSD this does not happen. select instead of returning a "readable" file descriptor returns an "exceptional" file descriptor. Later, when we try to read some data from the socket, the following exception is raised: Exception in thread Thread-1: Traceback (most recent call last): File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap self.run() File "/usr/local/lib/python2.5/threading.py", line 440, in run self.__target(*self.__args, **self.__kwargs) File "_test2.py", line 14, in server data = conn.recv(1024, socket.MSG_OOB) error: (22, 'Invalid argument') --- code --- import socket, select, threading, time, os def server(): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind(('', 1024)) s.listen(1) conn, addr = s.accept() conn.setblocking(0) conn.setsockopt(socket.SOL_SOCKET, socket.SO_OOBINLINE, 1) while 1: r, w, e = select.select([conn], [conn], [conn], 0.01) if r: # the socket is supposed to be in the "readable" list data = conn.recv(1024) print "read -> " + data if e: # ...but not in the "exception" list data = conn.recv(1024, socket.MSG_OOB) print "expt -> " + data threading.Thread(target=server).start() time.sleep(0.1) s = socket.socket() s.connect(('127.0.0.1', 1024)) s.sendall('x', socket.MSG_OOB) --- /code --- ---------- components: Library (Lib) messages: 69237 nosy: giampaolo.rodola severity: normal status: open title: socket's SO_REUSEADDR option does not work on FreeBSD type: behavior versions: Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 05:40:27 2008 From: report at bugs.python.org (Roger Upole) Date: Fri, 04 Jul 2008 03:40:27 +0000 Subject: [New-bugs-announce] [issue3279] import of site.py fails on startup In-Reply-To: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za> Message-ID: <1215142827.44.0.225986561599.issue3279@psf.upfronthosting.co.za> New submission from Roger Upole : In pythonrun.c, initstdio injects 'open' into builtins. However, initsite is called before initstdio and site.py uses open. Running with -v, this traceback is printed: Traceback (most recent call last): File "j:\python30\lib\site.py", line 518, in main() File "j:\python30\lib\site.py", line 501, in main known_paths = addsitepackages(known_paths) File "j:\python30\lib\site.py", line 281, in addsitepackages addsitedir(sitedir, known_paths) File "j:\python30\lib\site.py", line 178, in addsitedir addpackage(sitedir, name, known_paths) File "j:\python30\lib\site.py", line 141, in addpackage f = open(fullname, "rU") NameError: global name 'open' is not defined ---------- messages: 69240 nosy: rupole severity: normal status: open title: import of site.py fails on startup versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 11:02:04 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 04 Jul 2008 09:02:04 +0000 Subject: [New-bugs-announce] [issue3280] %c format does not accept large numbers on ucs-2 builds In-Reply-To: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za> Message-ID: <1215162124.14.0.169970018317.issue3280@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : Since python3.0, chr(0x2f81a) works even on narrow Unicode builds, but >>> "%c" % 0x2f81a OverflowError: %c arg not in range(0x10000) (narrow Python build) Likewise, Py_BuildValue("C") should accept codes outside the BMP. ---------- components: Unicode messages: 69247 nosy: amaury.forgeotdarc severity: normal status: open title: %c format does not accept large numbers on ucs-2 builds versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 13:00:31 2008 From: report at bugs.python.org (LI Daobing) Date: Fri, 04 Jul 2008 11:00:31 +0000 Subject: [New-bugs-announce] [issue3281] support r"\" In-Reply-To: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za> Message-ID: <1215169231.64.0.700296369871.issue3281@psf.upfronthosting.co.za> New submission from LI Daobing : currently r"\" or r'\' is not a valid string literal and it is already documented. but this exception is not simple enough, it make users confused when they found that r'C:\Program\Python\' does not work as expected. please consider support this, thanks. ---------- components: None messages: 69249 nosy: lidaobing severity: normal status: open title: support r"\" type: feature request versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 15:30:06 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 04 Jul 2008 13:30:06 +0000 Subject: [New-bugs-announce] [issue3282] Undefined unicode characters should be non-printable In-Reply-To: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za> Message-ID: <1215178206.2.0.370394116016.issue3282@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : str.isprintable() returns True for undefined unicode code points: >>> c = "\ufffe" >>> unicodedata.category(c) 'Cn' # (Other, Not Assigned) >>> c.isprintable() True Same for "\u0242", "\ufb12"... The cause is probably in unicodectype.c: _PyUnicode_IsPrintable(): return (ctype->flags & NONPRINTABLE_MASK) == 0; but ctype->flags is 0 for undefined chars. ---------- components: Unicode messages: 69254 nosy: amaury.forgeotdarc severity: normal status: open title: Undefined unicode characters should be non-printable versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 15:45:11 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Fri, 04 Jul 2008 13:45:11 +0000 Subject: [New-bugs-announce] [issue3283] multiprocessing.connection doesn't import AuthenticationError, while using it In-Reply-To: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za> Message-ID: <1215179111.5.0.100147287247.issue3283@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : Lib/multiprocessing/connection.py contains two uses of AuthenticationError, while it's not imported from multiprocessing package. This exception is used in deliver_challenge() and answer_challenge() functions. I've attached a small patch that fixes possible NameError while calling any of these two functions. ---------- components: Library (Lib) files: multiprocessing.connection.py.diff keywords: patch messages: 69255 nosy: jnoller, mishok13, roudkerk severity: normal status: open title: multiprocessing.connection doesn't import AuthenticationError, while using it versions: Python 3.0 Added file: http://bugs.python.org/file10809/multiprocessing.connection.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 21:26:09 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Jul 2008 19:26:09 +0000 Subject: [New-bugs-announce] [issue3284] Delete obsolete 'Unicode' in Py3 str docstrings; related fixes In-Reply-To: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za> Message-ID: <1215199569.07.0.941434192746.issue3284@psf.upfronthosting.co.za> New submission from Terry J. Reedy : In 3.0b1, several str methods have 'Unicode' in their docstrings leftover from 2.x when str *was* unicode. For center count ljust rjust translate 'Unicode' should be deleted before 'string'. For 'translate', I presume 'Unicode ordinal' should be left as is as was done for 'maketrans'. For lstrip rstrip strip "If chars is a str, it will be converted to unicode before stripping" should be deleted. Bytes (which replace old str) and bytearrays are not automatically converted. Other fixes For maketrans the word 'then' should be removed from 'will then be' in the fourth line since it only confuses. The conversion is the first and only thing done in the one-argument case. For lstrip rstrip strip remove ', Unicode' from "TypeError: strip arg must be None, unicode or str" For ljust rjust "TypeError: The fill character cannot be converted to Unicode" should be changed to TypeError: The fill character cannot be implicitly converted to str" or even, copying from several other method error messages TypeError: Can't convert 'bytes' object to str implicitly" or perhaps best would be "TypeError: For the fill char, can't convert 'bytes' object to str implicitly" The other methods taking str args seem to have been updated already. ---------- assignee: georg.brandl components: Documentation keywords: easy messages: 69263 nosy: georg.brandl, tjreedy severity: normal status: open title: Delete obsolete 'Unicode' in Py3 str docstrings; related fixes versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 21:36:27 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Jul 2008 19:36:27 +0000 Subject: [New-bugs-announce] [issue3285] Fraction.from_any() In-Reply-To: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za> Message-ID: <1215200187.54.0.0352827858842.issue3285@psf.upfronthosting.co.za> New submission from Raymond Hettinger : After exercising the fractions module, I've found it problematic that there isn't a unified constructor to handle mixed data input types. For example, when updating the accurate summation recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/393090 to show how it could be done with rational arithmetic. Handling mixed-type inputs required writing a factory function: def makefrac(x): if isinstance(x, Decimal): return Fraction.from_decimal(x) if isinstance(x, float): return Fraction.from_float(x) return Fraction(x) That function supported a clean version of the recipe: def frsum(iterable): return float(sum(map(makefrac, iterable))) It would have been much better if that functionality were built into the class definition. See attached patch. ---------- components: Library (Lib) files: from_any.diff keywords: patch messages: 69264 nosy: rhettinger severity: normal status: open title: Fraction.from_any() type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10810/from_any.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 21:45:25 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Jul 2008 19:45:25 +0000 Subject: [New-bugs-announce] [issue3286] IDLE opens window too low on Windows In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za> Message-ID: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za> New submission from Terry J. Reedy : On my Windows XP system, IDLE opens windows too low, even the first, so that the bottom is behind the task bar. When I move the window up, close, and reopen, it occasionally remembers the position but usually forgets. Always remembering would be nicer. It also seems to me that the default should at least be centered, but preferably even higher since new windows are cascaded down. Or Configure/General could have an initial position for first window entry just below or above the initial size. ---------- components: IDLE messages: 69265 nosy: tjreedy severity: normal status: open title: IDLE opens window too low on Windows type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 4 21:57:23 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 04 Jul 2008 19:57:23 +0000 Subject: [New-bugs-announce] [issue3287] Fraction constructor should raise TypeError instead of AttributeError In-Reply-To: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za> Message-ID: <1215201443.11.0.460100125282.issue3287@psf.upfronthosting.co.za> New submission from Raymond Hettinger : >>> from fractions import * >>> Fraction(3.1) Traceback (most recent call last): File "", line 1, in Fraction(3.1) File "C:\Python26\lib\fractions.py", line 100, in __new__ numerator = numerator.__index__() AttributeError: 'float' object has no attribute '__index__' ---------- assignee: jyasskin components: Library (Lib) messages: 69267 nosy: jyasskin, rhettinger severity: normal status: open title: Fraction constructor should raise TypeError instead of AttributeError type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 5 12:41:18 2008 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 05 Jul 2008 10:41:18 +0000 Subject: [New-bugs-announce] [issue3288] float.as_integer_ratio method is not documented In-Reply-To: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za> Message-ID: <1215254478.03.0.190528446429.issue3288@psf.upfronthosting.co.za> New submission from Mark Dickinson : The float.as_integer_ratio method needs to be documented somewhere other than whatsnew/2.6.rst. ---------- assignee: georg.brandl components: Documentation messages: 69277 nosy: georg.brandl, marketdickinson severity: normal status: open title: float.as_integer_ratio method is not documented versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 5 18:13:29 2008 From: report at bugs.python.org (Jon Nelson) Date: Sat, 05 Jul 2008 16:13:29 +0000 Subject: [New-bugs-announce] [issue3289] unnecessary call to time and localtime slows time.mktime In-Reply-To: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za> Message-ID: <1215274409.55.0.482276845315.issue3289@psf.upfronthosting.co.za> New submission from Jon Nelson : Basically, time.mktime calls time and localtime, and then overwrites those results. Removing these unnecessary calls results in a fairly noticeable speedup, lower double-digit percentile improvements for applications that do time parsing, for example. The patch below is for 2.5, but should apply to more recent versions. diff --git a/Modules/timemodule.c b/Modules/timemodule.c index be02ec2..dad235a 100644 --- a/Modules/timemodule.c +++ b/Modules/timemodule.c @@ -599,8 +599,6 @@ time_mktime(PyObject *self, PyObject *tup) { struct tm buf; time_t tt; - tt = time(&tt); - buf = *localtime(&tt); if (!gettmarg(tup, &buf)) return NULL; tt = mktime(&buf); ---------- components: Extension Modules messages: 69283 nosy: nother_jnelson severity: normal status: open title: unnecessary call to time and localtime slows time.mktime type: performance versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 5 21:09:07 2008 From: report at bugs.python.org (Sacha Varma) Date: Sat, 05 Jul 2008 19:09:07 +0000 Subject: [New-bugs-announce] [issue3290] python-config --cflags includes irrelevant flags In-Reply-To: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za> Message-ID: <1215284947.23.0.370691849564.issue3290@psf.upfronthosting.co.za> New submission from Sacha Varma : As I understand it, python-config --cflags is intended to yield the C compiler flags needed to compile a program that uses Python headers and libraries (as opposed to the C flags needed to compile python itself). However, it seems to include irrelevant options such as -Wall and -O3, which interfere with the build (for example, by enabling optimisation in a debug build): $ python-config --cflags -I/opt/Python-2.5.1/include/python2.5 -I/opt/Python-2.5.1/include/python2.5 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes ---------- components: Build messages: 69289 nosy: sacha severity: normal status: open title: python-config --cflags includes irrelevant flags type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 5 22:29:43 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Jul 2008 20:29:43 +0000 Subject: [New-bugs-announce] [issue3291] rlcompleter doesn't work anymore In-Reply-To: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za> Message-ID: <1215289783.17.0.918141616629.issue3291@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In the latest py3k versions, rlcompleter doesn't work anymore. Pressing the tab key (with tab-completion enabled) doesn't produce anything on screen. ---------- components: Library (Lib) messages: 69293 nosy: pitrou severity: normal status: open title: rlcompleter doesn't work anymore type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 5 23:37:34 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Jul 2008 21:37:34 +0000 Subject: [New-bugs-announce] [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x] In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za> Message-ID: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za> New submission from Terry J. Reedy : Suggested changes to Lib Ref Manual: Sequence Types --...(3.6 for 2.5) (These are mostly based on an issue posted on c.l.p. The Plone Archetypes package (which I know nothing of) was reported as suggesting that users pass sys.maxint, to indicate 'insert at end', to one of their functions that uses .insert. A user with an AMD64 did that ... and I could not find doc proof that the crash was not a Python bug.) Main section: Before the operation list, change "n, i and j are integers:" to "n, i, j, and k are integers:" After the above, add "An implementation may limit the range of position indexes (some uses of i below)." I do not know if this limitation, actual for CPython is documented elsewhere, but it should be here. In particular, i is used as both position and slice index. Consider using i only as a magnitude-limited position index (an 'index-sized integer' as one error message puts it) and j,k,l for unlimited slice and other integers. This would slightly change the suggestions above and entail replacements in the table here and in following subsections. Mutable Sequence Types In 3.0, .count and .index are general sequence methods and should be moved up to that section. (For .index, parameters i & j are not (limited) position indexes but simply integers for comparison. The notation change suggested above would make this clear without one having to experiment or infer from the comparison rule.) The line "s.insert(i, x) same as s[i:i] = [x]" is not true when i is outside the range of allow position indexes. If i is not defined as a limited range integer (and the implementation not changed ;-) add a footnote "only when i is within the range of allowed position indexes." Is there a policy on documenting possible operation-specific exceptions? I consider them part of the interface. Or should I bring this up on pydev? For 3.0, footnotes 3 and 7 (in this subsection) document 2, for 4 different operations. Here are a couple more related to this issue. In the main section, for s[i]: 2.x IndexError: cannot fit 'long' into an index-sized integer 3.0 IndexError: cannot fit 'int' into an index-sized integer In the subsection, for s.insert(i,x): 2.x OverflowError: long int too large to convert to int 3.0 OverflowError: Python int too large to convert to C ssize_t I actually think the OverflowError should be changed to IndexError since the problem is the same in both cases, but that is a different issue. ---------- assignee: georg.brandl components: Documentation messages: 69302 nosy: georg.brandl, tjreedy severity: normal status: open title: Position index limit; s.insert(i,x) not same as s[i:i]=[x] versions: Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 00:05:03 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Jul 2008 22:05:03 +0000 Subject: [New-bugs-announce] [issue3293] incorrect comments for PyObject_ReleaseBuffer In-Reply-To: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za> Message-ID: <1215295503.07.0.531699971785.issue3293@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The declaration for PyObject_ReleaseBuffer (in Include/abstract.h) has the following comments attached to it. But the part about the return value is wrong since the function is defined as returning void. Also, PEP 3118 says it always succeeds so it can't return an error code. By the way, may I suggest that having the buffer API declared in abstract.h but the Py_buffer struct declared in object.h (and why not in bufferobject.h?) is slightly confusing. /* C-API version of the releasebuffer function call. It checks to make sure the object has the required function pointer and issues the call. The obj must have the buffer interface or this function will cause a segfault (i.e. it is assumed to be called only after a corresponding getbuffer which already verified the existence of the tp_as_buffer pointer). Returns 0 on success and -1 (with an error raised) on failure. This function always succeeds (as a NO-OP) if there is no releasebuffer function for the object so that it can always be called when the consumer is done with the buffer */ ---------- components: Interpreter Core messages: 69303 nosy: pitrou severity: normal status: open title: incorrect comments for PyObject_ReleaseBuffer versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 00:27:06 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Jul 2008 22:27:06 +0000 Subject: [New-bugs-announce] [issue3294] SVN repository contains an incorrect symbolic link In-Reply-To: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za> Message-ID: <1215296826.02.0.0693304727833.issue3294@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In the py3k SVN branch I can see the following link. I suppose it is a mistake? $ ls -la Mac/IDLE/IDLE.app/Contents/MacOS/Python lrwxrwxrwx 1 antoine antoine 92 2008-07-01 22:33 Mac/IDLE/IDLE.app/Contents/MacOS/Python -> /Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python ---------- components: Build, Macintosh messages: 69305 nosy: pitrou severity: normal status: open title: SVN repository contains an incorrect symbolic link versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 00:29:39 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 05 Jul 2008 22:29:39 +0000 Subject: [New-bugs-announce] [issue3295] PyExc_BufferError is declared but nowhere defined In-Reply-To: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za> Message-ID: <1215296979.37.0.223488731028.issue3295@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Astonishingly, PyExc_BufferError is defined in pyerrors.h but it is defined nowhere. Consequently, any piece of code raising a PyExc_BufferError will cause the interpreter to crash as soon as it tries to do something with the exception... ---------- components: Interpreter Core messages: 69306 nosy: pitrou severity: normal status: open title: PyExc_BufferError is declared but nowhere defined type: crash versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 01:31:08 2008 From: report at bugs.python.org (Florian Mayer) Date: Sat, 05 Jul 2008 23:31:08 +0000 Subject: [New-bugs-announce] [issue3296] print function not executed in python 3.0 tutorial In-Reply-To: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za> Message-ID: <1215300668.3.0.525831221198.issue3296@psf.upfronthosting.co.za> New submission from Florian Mayer : It is for sure only a minor issue, but the new tutorial should not confuse readers as the print function is not executed here and does not do anything at all. Patch is attached. ---------- assignee: georg.brandl components: Documentation files: doc-patch messages: 69311 nosy: georg.brandl, segfaulthunter severity: normal status: open title: print function not executed in python 3.0 tutorial versions: Python 3.0 Added file: http://bugs.python.org/file10824/doc-patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 08:58:44 2008 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Jul 2008 06:58:44 +0000 Subject: [New-bugs-announce] [issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created In-Reply-To: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za> Message-ID: <1215327524.42.0.065323704773.issue3297@psf.upfronthosting.co.za> New submission from Ezio Melotti : Problem: when you have Unicode characters with a code point greater than U+FFFF written directly in the source file (that is, not in the form u'\Uxxxxxxxx' but as normal chars in a u'' string) the interpreter uses surrogate pairs for representing these characters only if the pyc doesn't exist. When the pyc is created it uses a "normal" character (\Uxxxxxxxx instead of the pair \uxxxx\uxxxx). This could lead to an unexpected behavior while comparing Unicode strings or in other situations (even if it could be solved without problems in different ways - using u'\Uxxxxxxx' or u'\uxxx' instead of the characters, encoding them before comparing - there shouldn't be differences between a py and its pyc). Tested on: Ubuntu 8.04 with python 2.4: Uses a surrogate pair. Ubuntu 8.04 with python 2.5: Uses a surrogate pair. Windows XP SP2 with python 2.4: Uses a "normal" character. Steps to reproduce the problem: 1a. download the attached file or create it following the next step; 1b. in a UTF-8-aware console write `print unichr(int('10123', 16))` (or any codepoint >= 10000), copy the printed character (depending on the console it could be a box, two box or a character) in a file with the lines `# -*- coding: utf-8 -*-`, `print 'Result:', u'' == u'\U00010123'` and `print 'Repr:', repr(u''), repr(u'\U00010123')`. Save the file in UTF-8; 2. open a python interpreter and import the file (`import unicodetest`). It should print `Result: False` and `Repr: u'\ud800\udd23' u'\U00010123'` (the character is represented as a surrogate pair). During this step the pyc file is created. 3. from the python interpreter write `reload(unicodetest)`. Now it should print `Result: True` and `Repr: u'\U00010123' u'\U00010123'` (the char is represented as a "normal" character). Any other reload will print True. If you delete the pyc and reload again it will print False. (Instead of using reload() is also possible to create a function and call it from the module when it's loaded and again with unicodetest.func(), the result will be the same.) Expected behavior: The interpreter should use the same representation in both the situation (and print True in both the tests). Another solution could be to change the behavior of == to return True if a normal char is compared with its surrogate pair (if it makes sense). Further informations: The character used for the test is part of the "Unicode Plane 1" (see http://en.wikipedia.org/wiki/Basic_Multilingual_Plane). More information about the surrogate pairs can be found here: http://en.wikipedia.org/wiki/Surrogate_pair#Encoding_of_characters_outside_the_BMP ---------- components: Unicode files: unicodetest.py messages: 69321 nosy: ezio.melotti, lemburg severity: normal status: open title: Python interpreter uses Unicode surrogate pairs only before the pyc is created type: behavior versions: Python 2.4, Python 2.5 Added file: http://bugs.python.org/file10826/unicodetest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 15:09:49 2008 From: report at bugs.python.org (Stavros Korokithakis) Date: Sun, 06 Jul 2008 13:09:49 +0000 Subject: [New-bugs-announce] [issue3298] Multiline string with quotes is not parsed correctly. In-Reply-To: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za> Message-ID: <1215349788.94.0.987157911353.issue3298@psf.upfronthosting.co.za> New submission from Stavros Korokithakis : A multiline string with quotes next to the ending quote is not parsed correctly: In [1]: """A "test"""" ------------------------------------------------------------ File "", line 1 """A "test"""" ^ : EOL while scanning single-quoted string Is this normal behaviour? It seems to me like the parser should parse everything inside the triple double quotes (there is no ambiguity). ---------- components: Interpreter Core messages: 69326 nosy: Stavros severity: normal status: open title: Multiline string with quotes is not parsed correctly. type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 16:20:44 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 14:20:44 +0000 Subject: [New-bugs-announce] [issue3299] invalid object destruction in re.finditer() In-Reply-To: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za> Message-ID: <1215354044.0.0.987178228996.issue3299@psf.upfronthosting.co.za> New submission from STINNER Victor : "import re: re.finditer("a", {})" crash on Python 2.x (tested with svn trunk) because of an invalid use of PyObject_NEW/PyObject_DEL. The error is in pattern_scanner(), in block "if (!string) { ... }". - scanner_dealloc() calls Py_DECREF(self->pattern); whereas pattern attribute is not initialized - scanner_dealloc() calls PyObject_DEL(self); whereas scanner_dealloc() is already the destructor of self object! I wrote a patch to fix these errors. Please review my patch, I don't know C API very well. I also patched _compile(): replace PyObject_DEL() by Py_DECREF(). Is it really needed? ---------- components: Library (Lib) files: re_finditer.patch keywords: patch messages: 69331 nosy: haypo severity: normal status: open title: invalid object destruction in re.finditer() type: crash versions: Python 2.6 Added file: http://bugs.python.org/file10828/re_finditer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 16:52:10 2008 From: report at bugs.python.org (Matt Giuca) Date: Sun, 06 Jul 2008 14:52:10 +0000 Subject: [New-bugs-announce] [issue3300] urllib.quote and unquote - Unicode issues In-Reply-To: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za> Message-ID: <1215355930.42.0.79499861143.issue3300@psf.upfronthosting.co.za> New submission from Matt Giuca : Three Unicode-related problems with urllib.parse.quote and urllib.parse.unquote in Python 3.0. (Patch attached). Firstly, unquote appears not to have been modified from Python 2, where it is designed to output a byte string. In Python 3, it outputs a unicode string, implicitly decoded as ISO-8859-1 (the code points are the same as the bytes). RFC 3986 states that the percent-encoded byte values should be decoded as UTF-8. http://tools.ietf.org/html/rfc3986 section 2.5. Current behaviour: >>> urllib.parse.unquote("%CE%A3") '??' (or '\u00ce\u00a3') Desired behaviour: >>> urllib.parse.unquote("%CE%A3") '?' (or '\u03a3') Secondly, while quote *has* been modified to encode to UTF-8 before percent-encoding, it does not work correctly for characters in range(128, 256), due to a special case in the code which again treats the code point values as byte values. Current behaviour: >>> urllib.parse.quote('\u00e9') '%E9' Desired behaviour: >>> urllib.parse.quote('\u00e9') '%C3%A9' Note that currently, quoting characters less than 256 will use ISO-8859-1, while quoting characters 256 or higher will use UTF-8! Thirdly, the "safe" argument to quote does not work for characters above 256, since these are excluded from the special case. I thought I would fix this at the same time, but it's really a separate issue. Current behaviour: >>> urllib.parse.quote('??', safe='?') '%CE%A3%CF%B0' Desired behaviour: >>> urllib.parse.quote('??', safe='?') '?%CF%B0' A patch which fixes all three issues is attached. Note that unquote now needs to handle the case where the UTF-8 sequence is invalid. This is currently handled by "replace" (invalid sequences are replaced by '\ufffd'). I would like to add an optional "errors" argument to unquote, defaulting to "replace", to allow the user to override this behaviour, but I didn't put that in because it would change the interface. Note I also changed one of the test cases, which had the wrong expected output. (String literal was manually UTF-8 encoded, designed for Python 2; nonsensical when viewed as a Python 3 Unicode string). All urllib test cases pass. Patch is for branch /branches/py3k, revision 64752. Note: The above unquote issue also manifests itself in Python 2 for Unicode strings, but it's hazy as to what the behaviour should be, and would break existing programs, so I'm just patching the Py3k branch. Commit log: urllib.parse.unquote: Fixed percent-encoded octets being implicitly decoded as ISO-8859-1; now decode as UTF-8, as per RFC 3986. urllib.parse.quote: Fixed characters in range(128, 256) being implicitly encoded as ISO-8859-1; now encode as UTF-8. Also fixed characters greater than 256 not responding to "safe", and also not being cached. Lib/test/test_urllib.py: Updated one test case for unquote which expected the wrong output. The new version of unquote passes the new test case. ---------- components: Library (Lib) files: parse.py.patch keywords: patch messages: 69333 nosy: mgiuca severity: normal status: open title: urllib.quote and unquote - Unicode issues type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10829/parse.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 17:12:30 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 15:12:30 +0000 Subject: [New-bugs-announce] [issue3301] DoS when lo is negative in bisect.insort_right() / _left() In-Reply-To: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za> Message-ID: <1215357141.61.0.853561189902.issue3301@psf.upfronthosting.co.za> New submission from STINNER Victor : "import bisect; bisect.insort(range(4), -1, -1)" goes into an unlimited loop. Workaround: replace negative lo value by zero. The function may raise an exception. ---------- components: Library (Lib) files: bisect_lo.patch keywords: patch messages: 69334 nosy: haypo severity: normal status: open title: DoS when lo is negative in bisect.insort_right() / _left() type: crash versions: Python 2.6 Added file: http://bugs.python.org/file10830/bisect_lo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 17:46:48 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 15:46:48 +0000 Subject: [New-bugs-announce] [issue3302] segfault on gettext(None) In-Reply-To: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za> Message-ID: <1215359208.89.0.118295330664.issue3302@psf.upfronthosting.co.za> New submission from STINNER Victor : msgid of gettext(), dgettext(), dcgettext() C functions can not be NULL (domainname can be NULL): "import locale; locale.gettext(None)" generates a segfault. domainname argument of bindtextdomain() have to be a non empty string: "locale.bindtextdomain(NULL, NULL)" or locale.bindtextdomain('', NULL)" generates an OSError(0). Attached patch fixes the two bugs. ---------- components: Extension Modules files: locale_none.patch keywords: patch messages: 69335 nosy: haypo severity: normal status: open title: segfault on gettext(None) versions: Python 2.6 Added file: http://bugs.python.org/file10831/locale_none.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 18:06:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 16:06:10 +0000 Subject: [New-bugs-announce] [issue3303] invalid ref count on locale.strcoll() error In-Reply-To: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za> Message-ID: <1215360370.12.0.415668125666.issue3303@psf.upfronthosting.co.za> New submission from STINNER Victor : If locale.strcoll(a, b) fails because PyUnicode_FromObject(b) fails, refcount of a is wrong. Attached patch fixes the problem. ---------- components: Library (Lib) files: locale_strcoll_rel1.patch keywords: patch messages: 69336 nosy: haypo severity: normal status: open title: invalid ref count on locale.strcoll() error type: crash versions: Python 2.6 Added file: http://bugs.python.org/file10832/locale_strcoll_rel1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 18:30:22 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 16:30:22 +0000 Subject: [New-bugs-announce] [issue3304] invalid call to PyMem_Free() in fileio_init() In-Reply-To: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za> Message-ID: <1215361822.52.0.122745729251.issue3304@psf.upfronthosting.co.za> New submission from STINNER Victor : fileio_init() calls PyMem_Free(name); whereas name comes from PyArg_ParseTupleAndKeywords(). Attached patch removes this invalid call. The bug may also affect Python3.0. ---------- components: Library (Lib) files: fileio_pymem_free.patch keywords: patch messages: 69338 nosy: haypo severity: normal status: open title: invalid call to PyMem_Free() in fileio_init() versions: Python 2.6 Added file: http://bugs.python.org/file10833/fileio_pymem_free.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 20:27:40 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 18:27:40 +0000 Subject: [New-bugs-announce] [issue3305] Use Py_XDECREF() instead of Py_DECREF() in MultibyteCodec and MultibyteStreamReader In-Reply-To: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za> Message-ID: <1215368860.06.0.0616450486424.issue3305@psf.upfronthosting.co.za> New submission from STINNER Victor : Functions mbstreamwriter_dealloc() and mbstreamreader_dealloc() of Modules/cjkcodecs/multibytecodec.c uses Py_DECREF() to free stream attribute memory, but this attribute may be NULL if MultibyteCodec or MultibyteStreamReader constructor fails. Simple fix: use Py_XDECREF(). Example: >>> import _multibytecodec >>> _multibytecodec.MultibyteStreamReader(None) Erreur de segmentation (core dumped) ---------- components: Library (Lib) files: multibytecodec_py_xdecref.patch keywords: patch messages: 69347 nosy: haypo severity: normal status: open title: Use Py_XDECREF() instead of Py_DECREF() in MultibyteCodec and MultibyteStreamReader versions: Python 2.6 Added file: http://bugs.python.org/file10834/multibytecodec_py_xdecref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 6 23:57:59 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 21:57:59 +0000 Subject: [New-bugs-announce] [issue3306] audioop.findmax() crashs with negative length In-Reply-To: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za> Message-ID: <1215381479.48.0.0542422679202.issue3306@psf.upfronthosting.co.za> New submission from STINNER Victor : Example: >>> import audioop >>> audioop.findmax(''.join( chr(x) for x in xrange(256)), -2392392) Erreur de segmentation (core dumped) The problem is that audioop_findmax() doesn't check len2 for negative value. Here is a patch ;-) ---------- components: Library (Lib) files: audioop_findmax.patch keywords: patch messages: 69356 nosy: haypo severity: normal status: open title: audioop.findmax() crashs with negative length versions: Python 2.6 Added file: http://bugs.python.org/file10835/audioop_findmax.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 00:56:01 2008 From: report at bugs.python.org (STINNER Victor) Date: Sun, 06 Jul 2008 22:56:01 +0000 Subject: [New-bugs-announce] [issue3307] invalid check of _bsddb creation failure In-Reply-To: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za> Message-ID: <1215384961.05.0.023038653338.issue3307@psf.upfronthosting.co.za> New submission from STINNER Victor : newDBObject(), called by DB_construct(), doesn't check correctly the result of all to the external function db_create(). It checks if self->db is NULL, but db_create() doesn't change self->db value on error. So if self->db is uninitialized, the error is not catched. Two ideas to fix the bug: - check "if (err)" instead of "if (self->db != NULL)" - set self->db=NULL before calling db_create() I implemented the second proposition in the attached patch. Note: The bug occurs with PYDEBUG, I don't know if PyObject_New() fills new allocate memory to zero (I think no, but I'm not sure). ---------- components: Library (Lib) files: bsddb_create.patch keywords: patch messages: 69358 nosy: haypo severity: normal status: open title: invalid check of _bsddb creation failure versions: Python 2.6 Added file: http://bugs.python.org/file10836/bsddb_create.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 02:16:21 2008 From: report at bugs.python.org (Roger Binns) Date: Mon, 07 Jul 2008 00:16:21 +0000 Subject: [New-bugs-announce] [issue3308] MinGW built extensions do not load (specified procedure cannot be found) In-Reply-To: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za> Message-ID: <1215389781.12.0.716617737168.issue3308@psf.upfronthosting.co.za> New submission from Roger Binns : My extension (apsw) builds and runs just fine on Linux, Mac and Windows for Python 2.3, 2.4 and 2.5. For Linux and Mac Python 2.6 beta 1 and Python 3.0 beta 1 also work just fine. However on Windows using MinGW and Python 2.6 beta 1 and Python 3.0 beta 1 the pyd fails to load claiming the "specified procedure cannot be found". The compile/link is just fine and pexports shows the procedure is present. # Compile lines c:/python26/python setup.py build --compile=mingw32 install c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DSQLITE_THREADSAFE=1 -DNDEBUG=1 -DEXPERIMENTAL=1 -DAPSW_USE_SQLITE_AMALGAMATION=\"C:\apsw\sqlite3.c\" -Ic:\python26\include -Ic:\python26\PC -c apsw.c -o build\temp.win32-2.6\Release\apsw.o writing build\temp.win32-2.6\Release\apsw.def c:\mingw\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.6\Release\apsw.o build\temp.win32-2.6\Release\apsw.def -Lc:\python26\libs -Lc:\python26\PCbuild -lpython26 -lmsvcr90 -o build\lib.win32-2.6\apsw.pyd # Running ImportError: DLL load failed: The specified procedure could not be found. # Pexports C:\apsw>pexports build\lib.win32-2.6\apsw.pyd LIBRARY apsw.pyd EXPORTS initapsw When using Python 3.0 things are substantially the same except the init function is PyInit_apsw. MinGW was installed using the default configuration with the automated installer http://sourceforge.net/forum/forum.php?forum_id=817299 The libmsvcr90.a is part of MinGW found in c:\MinGW\lib ---------- components: Distutils messages: 69361 nosy: rogerbinns severity: normal status: open title: MinGW built extensions do not load (specified procedure cannot be found) versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 02:46:01 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jul 2008 00:46:01 +0000 Subject: [New-bugs-announce] [issue3309] missing lock release in BZ2File_iternext() In-Reply-To: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za> Message-ID: <1215391561.36.0.549542846727.issue3309@psf.upfronthosting.co.za> New submission from STINNER Victor : Call BZ2File_iternext() on closed file doesn't release the lock. Example: ----------- import bz2 obj = bz2.BZ2File('/etc/issue') obj.close() try: #?acquire the lock obj.next() except ValueError, err: #?but don't release the lock print err # DEAD LOCK here obj.readlines() ----------- Attached patch fixes this bug. ---------- components: Library (Lib) files: bz2_lock.patch keywords: patch messages: 69362 nosy: haypo severity: normal status: open title: missing lock release in BZ2File_iternext() versions: Python 2.6 Added file: http://bugs.python.org/file10837/bz2_lock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 03:00:53 2008 From: report at bugs.python.org (Alexis Layton) Date: Mon, 07 Jul 2008 01:00:53 +0000 Subject: [New-bugs-announce] [issue3310] Out-of-date example 3.0b1 Tutorial Classes page, 'issubclass' In-Reply-To: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za> Message-ID: <1215392453.51.0.124729172537.issue3310@psf.upfronthosting.co.za> New submission from Alexis Layton : The bullet example for 'issubclass' should be updated since neither 'unicode' or 'basestring' are valid anymore. ---------- assignee: georg.brandl components: Documentation messages: 69363 nosy: alexis.layton, georg.brandl severity: normal status: open title: Out-of-date example 3.0b1 Tutorial Classes page, 'issubclass' type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 03:18:40 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jul 2008 01:18:40 +0000 Subject: [New-bugs-announce] [issue3311] block operation on closed socket/pipe for multiprocessing In-Reply-To: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za> Message-ID: <1215393520.85.0.811591651843.issue3311@psf.upfronthosting.co.za> New submission from STINNER Victor : _multiprocessing Connection methods don't check if handle is valid or not. If you close the socket/pipe, Python may crash on operations, especially in poll() on FD_SET(...handle, &rdfs). Example of crash: ---------------------- import _multiprocessing obj = _multiprocessing.Connection(755) obj.close() obj.poll() ---------------------- Attached patch is a proposition of fix to check handle in all Connection methods using the handle. ---------- components: Library (Lib) files: multiprocessing_closed.patch keywords: patch messages: 69365 nosy: haypo severity: normal status: open title: block operation on closed socket/pipe for multiprocessing versions: Python 2.6 Added file: http://bugs.python.org/file10838/multiprocessing_closed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 15:16:52 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jul 2008 13:16:52 +0000 Subject: [New-bugs-announce] [issue3312] bugs in _sqlite module In-Reply-To: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za> Message-ID: <1215436611.84.0.797718972528.issue3312@psf.upfronthosting.co.za> New submission from STINNER Victor : (A) module_register_adapter() doesn't check microprotocols_add() result, whereas it can fails (eg. dict setitem error). Example: "import _sqlite3; _sqlite3.register_adapter({}, None)" => should raise a TypeError (unhashable type: 'dict'). (B) Connection.set_isolation_level() tries to create the string "BEGIN "+isolation_level and the store it as PyString in begin_statement. But if the result can not be converted to string, Python crashs. Example: >>> import _sqlite3 >>> c=_sqlite3.Connection("a") >>> c.isolation_level = u"\xe9" Erreur de segmentation (core dumped) Attached patch fix the two bugs. ---------- components: Library (Lib) files: _sqlite.patch keywords: patch messages: 69387 nosy: haypo severity: normal status: open title: bugs in _sqlite module versions: Python 2.6 Added file: http://bugs.python.org/file10841/_sqlite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 15:24:33 2008 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Jul 2008 13:24:33 +0000 Subject: [New-bugs-announce] [issue3313] dlopen() error with no error message from dlerror() In-Reply-To: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za> Message-ID: <1215437073.22.0.670628810168.issue3313@psf.upfronthosting.co.za> New submission from STINNER Victor : Python dl_open() function (from dl module) calls dlopen() and check its result: if it's NULL, it's an error. This is correct if I read the man page. But with an invalid flag value (-1), dlopen() returns NULL but dlerror() also gives a NULL pointer. Example: >>> import dl >>> dl.open("/usr/lib/libm.so", -1) Erreur de segmentation (core dumped) Workaround: use a static error message if dlerror() returns NULL. I wrote a patch for dl_open() but other functions (in ctypes module?) should also call dlerror(). ---------- components: Library (Lib) files: dl_open.patch keywords: patch messages: 69388 nosy: haypo severity: normal status: open title: dlopen() error with no error message from dlerror() type: crash versions: Python 2.6 Added file: http://bugs.python.org/file10842/dl_open.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 16:50:30 2008 From: report at bugs.python.org (Matt Giuca) Date: Mon, 07 Jul 2008 14:50:30 +0000 Subject: [New-bugs-announce] [issue3314] urllib.parse doesn't import sys In-Reply-To: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za> Message-ID: <1215442230.29.0.593652627296.issue3314@psf.upfronthosting.co.za> New submission from Matt Giuca : urllib.parse doesn't import sys, which is needed on line 368, in an error condition for urlencode. This is only a problem when urlencode has a TypeError. Current behaviour: >>> urllib.parse.urlencode("foo") NameError: global name 'sys' is not defined Desired behaviour: >>> urllib.parse.urlencode("foo") TypeError: not a valid non-string sequence or mapping object Only affects Python 3.0. (After urllib module was split up). Patch attached, for revision 64772. Commit log: urllib/parse.py: Added missing "import sys". ---------- components: Library (Lib) files: parse.py.patch keywords: patch messages: 69389 nosy: mgiuca severity: normal status: open title: urllib.parse doesn't import sys type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file10843/parse.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 16:57:43 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Mon, 07 Jul 2008 14:57:43 +0000 Subject: [New-bugs-announce] [issue3315] abc.rst little error In-Reply-To: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za> Message-ID: <1215442663.49.0.883181790002.issue3315@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : 'make html' with latest py3k sources produces this warning: WARNING: /home/mishok/doc/python/abc-doc-bug/Doc/library/abc.rst:11: term not in glossary: abstract base classes I've applied little patch that fixes this. ---------- assignee: georg.brandl components: Documentation files: abc.rst.diff keywords: patch messages: 69390 nosy: georg.brandl, mishok13 severity: normal status: open title: abc.rst little error versions: Python 3.0 Added file: http://bugs.python.org/file10844/abc.rst.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 22:36:54 2008 From: report at bugs.python.org (Nick Edds) Date: Mon, 07 Jul 2008 20:36:54 +0000 Subject: [New-bugs-announce] [issue3316] Proposal for fix_urllib In-Reply-To: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za> Message-ID: <1215463014.46.0.808311046124.issue3316@psf.upfronthosting.co.za> New submission from Nick Edds : Here is my proposed fix_urllib. The transform function is massive because there are a lot of cases, so maybe I should break it into separate functions for each case, and it could maybe do with some more documentation as well. I also use FromImport from fixer_util.py even though it warns against doing so for dotted imports because it appears to work. The temp.py file is a dummy python file that you can test it on to get an idea of what it does. I think it's got all the desired functionality, but I'm not an expert on the urllib changes so let me know if I missed anything. I haven't written tests for it yet, but assuming it looks reasonable, I can do that later today or tomorrow. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: fix_urllib.diff keywords: patch messages: 69395 nosy: brett.cannon, collinwinter, nedds severity: normal status: open title: Proposal for fix_urllib Added file: http://bugs.python.org/file10845/fix_urllib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 7 22:57:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 07 Jul 2008 20:57:49 +0000 Subject: [New-bugs-announce] [issue3317] duplicate lines in zipfile.py In-Reply-To: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za> Message-ID: <1215464269.75.0.951317701658.issue3317@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : Since r64688, zipfile.py contains duplicated definitions. The attached patch removes them. Also, Twisted uses a zipfile item that have been renamed by this change: zipfile.stringFileHeader (now magicFileHeader). This makes some tests fail on the community buildbots. See the rightmost column on http://www.python.org/dev/buildbot/community/trunk/ I suggest to rename all magicXXX variables back to stringXXX. ---------- assignee: loewis components: Library (Lib) messages: 69398 nosy: amaury.forgeotdarc, loewis severity: normal status: open title: duplicate lines in zipfile.py type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 8 03:43:13 2008 From: report at bugs.python.org (unutbu) Date: Tue, 08 Jul 2008 01:43:13 +0000 Subject: [New-bugs-announce] [issue3318] Documentation: timeit: "lower bound" should read "upper bound" In-Reply-To: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za> Message-ID: <1215481393.4.0.322080093727.issue3318@psf.upfronthosting.co.za> New submission from unutbu : Re: http://docs.python.org/lib/module-timeit.html Where the documentation says "In a typical case, the lowest value gives a lower bound for how fast your machine can run the given code snippet", it should read instead, "In a typical case, the lowest value gives an upper bound for how fast your machine can run the given code snippet". Clearly, if a machine can run a code snippet in x seconds with background processes, then the fastest the machine can run the code snippet (without background processes) should be <= x seconds. Therefore x is an upper bound rather than a lower bound. ---------- assignee: georg.brandl components: Documentation messages: 69405 nosy: georg.brandl, unutbu severity: normal status: open title: Documentation: timeit: "lower bound" should read "upper bound" versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 8 10:44:06 2008 From: report at bugs.python.org (Michael Patrick O'Keefe) Date: Tue, 08 Jul 2008 08:44:06 +0000 Subject: [New-bugs-announce] [issue3319] pystone.main(10) causes ZeroDivisionError In-Reply-To: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za> Message-ID: <1215506646.09.0.809082477748.issue3319@psf.upfronthosting.co.za> New submission from Michael Patrick O'Keefe : The following call results in a ZeroDivisionError in python 2.5.2 and python 3.0 alpha 3 (I presume this is also an issue for Python 2.6 but I can't explicitly confirm): >>> from test import pystone >>> pystone.main(10) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py", line 61, in main benchtime, stones = pystones(loops) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py", line 68, in pystones return Proc0(loops) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/test/pystone.py", line 131, in Proc0 return benchtime, (loops / benchtime) ZeroDivisionError: float division Note the patch I submitted checks if the benchtime is equal to 0.0 (which apparently happens on my Mac OS 10.5 PPC). If this is the case I arbitrarily set the benchtime to 1e-6. I'm not sure what the units of the benchtime variable is (seconds?). Anyhow, this fixes the issue but can someone review to confirm this is the correct behavior? Thanks! -Michael ---------- components: Library (Lib), Tests files: pystone_patch.txt messages: 69418 nosy: mokeefe severity: normal status: open title: pystone.main(10) causes ZeroDivisionError type: behavior versions: Python 2.5, Python 3.0 Added file: http://bugs.python.org/file10853/pystone_patch.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 8 15:31:24 2008 From: report at bugs.python.org (DSM) Date: Tue, 08 Jul 2008 13:31:24 +0000 Subject: [New-bugs-announce] [issue3320] various doc typos In-Reply-To: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za> Message-ID: <1215523884.32.0.11626417694.issue3320@psf.upfronthosting.co.za> New submission from DSM : Boredom resulted in a handful of doc copyedits against 64789. One error I did note in the doc tree but didn't correct because it's in code: includes/mp_distributing.py contains the typo _logger.propogate = 0 which ISTM will leave the logger's propagate flag on. I can't imagine this has any real consequence but I've never used either module. ---------- assignee: georg.brandl components: Documentation files: typos1.diff keywords: patch messages: 69428 nosy: dsm001, georg.brandl severity: normal status: open title: various doc typos versions: Python 2.6 Added file: http://bugs.python.org/file10857/typos1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 00:45:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jul 2008 22:45:10 +0000 Subject: [New-bugs-announce] [issue3321] _multiprocessing.Connection() doesn't check handle In-Reply-To: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za> Message-ID: <1215557110.58.0.0473055429054.issue3321@psf.upfronthosting.co.za> New submission from STINNER Victor : _multiprocessing.Connection() allows to use any positive (or nul) number has socket handle. If you use an invalid file descriptor, poll() method may crash (especially for big positive integer). Example: >>> import _multiprocessing >>> obj = _multiprocessing.Connection(44977608) >>> obj.poll() Erreur de segmentation (core dumped) Fix: use fstat() to make sure that the handle is valid. Attached patch implements this feature. Another solution would be to reuse code from Modules/selectmodule.c. ---------- components: Library (Lib) files: _multiprocessing_connection.patch keywords: patch messages: 69446 nosy: haypo severity: normal status: open title: _multiprocessing.Connection() doesn't check handle versions: Python 2.6 Added file: http://bugs.python.org/file10860/_multiprocessing_connection.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 00:58:10 2008 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Jul 2008 22:58:10 +0000 Subject: [New-bugs-announce] [issue3322] bugs in scanstring_str() and scanstring_unicode() of _json module In-Reply-To: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za> Message-ID: <1215557890.28.0.315205708793.issue3322@psf.upfronthosting.co.za> New submission from STINNER Victor : scanstring_str() and scanstring_unicode() functions don't end value whereas it can be outside input string range. A check like this is needed: if (end < 0 || len <= end) { PyErr_SetString(PyExc_ValueError, "xxx"); return NULL; } next is set to begin but few lines later (before first use of next), it's set to end: for (next = end; ...). In error message, eg. "Invalid control character at (...)", begin is used as character position but I think that the right position is in the variable "end" (or maybe "next"?). I'm unable to fix these functions because I don't understand the code. ---------- components: Library (Lib) messages: 69447 nosy: haypo severity: normal status: open title: bugs in scanstring_str() and scanstring_unicode() of _json module type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 09:22:59 2008 From: report at bugs.python.org (Andy) Date: Wed, 09 Jul 2008 07:22:59 +0000 Subject: [New-bugs-announce] [issue3323] Clarify __slots__ behaviour when inheriting In-Reply-To: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za> Message-ID: <1215588179.05.0.980604972121.issue3323@psf.upfronthosting.co.za> New submission from Andy : Suggest clarification on behaviour of the __slots__ attribute when inheriting from classes that don't have __slots__ defined. Obviously the superclass automatically creates __dict__, and it seems the subclass inherits this. I presume this is expected behaviour, but I think it would be worth clarifying in the 'Notes on using __slots__' section - perhaps add something like: "If you define __slots__ on a subclass when its superclass doesn't have __slots__ defined, the superclass will automatically create a __dict__ instance which will be inherited by the subclass (as will other instance attributes). Defining __slots__ on the subclass doesn't block this inheritance." ---------- assignee: georg.brandl components: Documentation messages: 69460 nosy: georg.brandl, strangefeatures severity: normal status: open title: Clarify __slots__ behaviour when inheriting type: feature request versions: Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 13:32:14 2008 From: report at bugs.python.org (ThomasH) Date: Wed, 09 Jul 2008 11:32:14 +0000 Subject: [New-bugs-announce] [issue3324] Broken link in online doc In-Reply-To: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za> Message-ID: <1215603134.48.0.502276263753.issue3324@psf.upfronthosting.co.za> New submission from ThomasH : The page http://docs.python.org/inst/search-path.html contains a broken link to site module documentation. Is: http://www.python.org/doc/devel/lib/module-site.html Should be: http://docs.python.org/lib/module-site.html ---------- assignee: georg.brandl components: Documentation messages: 69462 nosy: ThomasH, georg.brandl severity: normal status: open title: Broken link in online doc type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 14:01:24 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Wed, 09 Jul 2008 12:01:24 +0000 Subject: [New-bugs-announce] [issue3325] use of cPickle in multiprocessing In-Reply-To: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za> Message-ID: <1215604884.64.0.41728166922.issue3325@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : There are two places in multiprocessing where cPickle (gone from py3k already) is used. Both of them are in try .. except, so they don't break code. Here is a patch that removes these uses. ---------- components: Library (Lib) messages: 69463 nosy: jnoller, mishok13, roudkerk severity: normal status: open title: use of cPickle in multiprocessing versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 14:11:20 2008 From: report at bugs.python.org (Ismail Donmez) Date: Wed, 09 Jul 2008 12:11:20 +0000 Subject: [New-bugs-announce] [issue3326] py3k shouldn't use -fno-strict-aliasing anymore In-Reply-To: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za> Message-ID: <1215605479.82.0.766368773223.issue3326@psf.upfronthosting.co.za> New submission from Ismail Donmez : py3k branch is still using -fno-strict-aliasing but I tested with gcc 4.3.1 and there are no strict aliasing warnings when this flag is removed. Attached patch for py3k branch removes this flag. After applying the patch configure should be regenerated with autoconf. ---------- components: Interpreter Core files: strict-aliasing.patch keywords: patch messages: 69465 nosy: cartman severity: normal status: open title: py3k shouldn't use -fno-strict-aliasing anymore type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file10868/strict-aliasing.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 15:33:42 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 09 Jul 2008 13:33:42 +0000 Subject: [New-bugs-announce] [issue3327] NULL member in modules_by_index In-Reply-To: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za> Message-ID: <1215610422.7.0.838989499254.issue3327@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : In _PyState_AddModule(), a list of (initially) 20 elements is created, but there is no guarantee that all elements are initialized. In particular, it appears that element 0 is always NULL. This is bad since this list is accessible through introspection, e.g. by gc.get_objects() ---------- components: Interpreter Core messages: 69469 nosy: krisvale severity: normal status: open title: NULL member in modules_by_index type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 18:48:52 2008 From: report at bugs.python.org (Dominic Lavoie) Date: Wed, 09 Jul 2008 16:48:52 +0000 Subject: [New-bugs-announce] [issue3328] When PyObject_CallMethod fails, refcount is incorrect In-Reply-To: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za> Message-ID: <1215622132.38.0.408050175684.issue3328@psf.upfronthosting.co.za> New submission from Dominic Lavoie : This issue is similar to issue 1229429. In the called Python method, a regular expression fails to compile & PyEval_CallMethod() returns 0. However, the reference count is incremented by 1 which prevents the object from being destroyed. Could the problem be in classobject.c, in instancemethod_call() ? if (newarg == NULL) return NULL; Py_INCREF(self); PyTuple_SET_ITEM(newarg, 0, self); for (i = 0; i < argcount; i++) { PyObject *v = PyTuple_GET_ITEM(arg, i); Py_XINCREF(v); PyTuple_SET_ITEM(newarg, i+1, v); } arg = newarg; } result = PyObject_Call((PyObject *)func, arg, kw); Py_DECREF(arg); return result; } If result is null, should Py_DECREF(self) be called in the case where self was non-null ? ---------- components: Interpreter Core messages: 69474 nosy: dominic.lavoie severity: normal status: open title: When PyObject_CallMethod fails, refcount is incorrect type: resource usage versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 21:48:53 2008 From: report at bugs.python.org (Jukka Laurila) Date: Wed, 09 Jul 2008 19:48:53 +0000 Subject: [New-bugs-announce] [issue3329] API for setting the memory allocator used by Python In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za> Message-ID: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za> New submission from Jukka Laurila : Currently Python always uses the C library malloc/realloc/free as the underlying mechanism for requesting memory from the OS, but especially on memory-limited platforms it is often desirable to be able to override the allocator and to redirect all Python's allocations to use a special heap. This will make it possible to free memory back to the operating system without restarting the process, and to reduce fragmentation by separating Python's allocations from the rest of the program. The proposal is to make it possible to set the allocator used by the Python interpreter by calling the following function before Py_Initialize(): void Py_SetAllocator(void* (*alloc)(size_t), void* (*realloc)(void*, size_t), void (*free)(void*)) Direct function calls to malloc/realloc/free in obmalloc.c must be replaced with calls through the function pointers set through this function. By default these would of course point to the C stdlib malloc/realloc/free. ---------- components: Interpreter Core messages: 69482 nosy: jlaurila severity: normal status: open title: API for setting the memory allocator used by Python type: feature request versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 9 23:37:00 2008 From: report at bugs.python.org (Adrian Petrescu) Date: Wed, 09 Jul 2008 21:37:00 +0000 Subject: [New-bugs-announce] [issue3330] webbrowser module doesn't correctly handle '|' character. In-Reply-To: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za> Message-ID: <1215639420.18.0.00968952650069.issue3330@psf.upfronthosting.co.za> New submission from Adrian Petrescu : The webbrowser module seems to treat URLs containing the "|" character differently based on whether the browser is already running or not. For instance, consider the following python script: import webbrowser url = "http://foo.com/bar.html?var=x|y|z" webbrowser.open(url) If you run this script while the browser is already running (so that webbrowser.open creates a new tab) this behaves as you would expect, with the given URL as an address. However, if a browser is not already running, when webbrowser.open creates it, it seems to interpret the "|" as a seperator character, so that the browser will open with THREE tabs, one open to "http://foo.com/bar.html?var=x", one to "http://y" and one to "http://z". This is clearly a bug, webbrowser module should be smart enough to escape the "|" character if the browser is interpreting that line differently. This happens in Linux with Python 2.5 and Firefox 3.0. Not sure if it happens with anything else. ---------- components: Library (Lib) messages: 69488 nosy: AdrianP severity: normal status: open title: webbrowser module doesn't correctly handle '|' character. type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 10 11:38:22 2008 From: report at bugs.python.org (Carl Johnson) Date: Thu, 10 Jul 2008 09:38:22 +0000 Subject: [New-bugs-announce] [issue3331] Possible inconsistency in behavior of list comprehensions vs. generator expressions In-Reply-To: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za> Message-ID: <1215682702.48.0.892529833903.issue3331@psf.upfronthosting.co.za> New submission from Carl Johnson : Compare the following behaviors: Python 3.0a5 (r30a5:62856, May 10 2008, 10:34:28) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def f(x): ... if x > 5: raise StopIteration ... >>> [x for x in range(100) if not f(x)] Traceback (most recent call last): File "", line 1, in File "", line 1, in File "", line 2, in f StopIteration >>> list(x for x in range(100) if not f(x)) [0, 1, 2, 3, 4, 5] One might object that the behavior of the list comprehension is identical to that of a for-loop: >>> r = [] >>> for x in range(100): ... if not f(x): ... r.append(x) ... Traceback (most recent call last): File "", line 2, in File "", line 2, in f StopIteration However, it can be argued that in Python 3 list comprehensions should be thought of as "syntatic sugar" for ``list(generator expression)`` not a for-loop with an accumulator. (This seems to be the motivation for no longer "leaking" variables from list comprehensions into their enclosing namespace.) One interesting question that this raises (for me at least) is whether the for-loop should also behave like a generator expression. Of course, the behavior of the generator expression can already be simulated by writing: >>> r = [] >>> for x in range(100): ... try: ... if f(x): ... r.append(x) ... except StopIteration: ... break ... >>> r [0, 1, 2, 3, 4, 5] This raises the question, do we need both a ``break`` statement and ``raise StopIteration``? Can the former just be made into syntatic sugar for the later? ---------- components: Interpreter Core messages: 69496 nosy: carlj severity: normal status: open title: Possible inconsistency in behavior of list comprehensions vs. generator expressions type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 10 15:59:54 2008 From: report at bugs.python.org (Jens Diemer) Date: Thu, 10 Jul 2008 13:59:54 +0000 Subject: [New-bugs-announce] [issue3332] DocTest and dict sort. In-Reply-To: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za> Message-ID: <1215698394.53.0.241298622742.issue3332@psf.upfronthosting.co.za> New submission from Jens Diemer : The doctest doesn't work good, if a function returns a dict. Here a simple example: def test(d): """ This works: >>> test({"A":1, "B":2, "C":3}) {'A': 1, 'C': 3, 'B': 2} This failed, because of different dict sort: >>> test({"A":1, "B":2, "C":3}) {'A': 1, 'B': 2, 'C': 3} The Error messages: Failed example: test({"A":1, "B":2, "C":3}) Expected: {'A': 1, 'B': 2, 'C': 3} Got: {'A': 1, 'C': 3, 'B': 2} """ return d The problem is IMHO that doctest.py [1] OutputChecker.check_output() does compare the repr() of the dict and not the real dict as data. One solution: Use eval() to convert the string repr. of the dict into the real dict: ... #---------- try: if eval(got) == eval(want): return True except: pass #*pfeif* kein schoener stil, aber pragmatisch #--------- # We didn't find any match; return false. return False German discuss can be found here: http://www.python-forum.de/topic-15321.html [1] http://svn.python.org/view/python/trunk/Lib/doctest.py?view=markup ---------- components: Extension Modules messages: 69501 nosy: jedie severity: normal status: open title: DocTest and dict sort. type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 10 17:06:25 2008 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Jul 2008 15:06:25 +0000 Subject: [New-bugs-announce] [issue3333] Need -3 warning for exec statement becoming a function Message-ID: <1215702385.26.0.978692514818.issue3333@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: rhettinger priority: high severity: normal status: open title: Need -3 warning for exec statement becoming a function versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 10 18:55:13 2008 From: report at bugs.python.org (Christian Theune) Date: Thu, 10 Jul 2008 16:55:13 +0000 Subject: [New-bugs-announce] [issue3334] 2to3 looses indentation on import fix In-Reply-To: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za> Message-ID: <1215708913.27.0.554899314818.issue3334@psf.upfronthosting.co.za> New submission from Christian Theune : I got this output from 2to3: (This is from setuptools egg_info.py) - import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe) +from . import bdist_egg; bdist_egg.write_safety_flag(cmd.egg_info, safe) ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 69510 nosy: collinwinter, ctheune severity: normal status: open title: 2to3 looses indentation on import fix versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 10 20:21:49 2008 From: report at bugs.python.org (Justin Harper) Date: Thu, 10 Jul 2008 18:21:49 +0000 Subject: [New-bugs-announce] [issue3335] subprocess lib - opening same command fails In-Reply-To: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za> Message-ID: <1215714109.54.0.694073882859.issue3335@psf.upfronthosting.co.za> New submission from Justin Harper : When I make the same shell call a second time, a weird error occurs. It appears that the system is caching the call and then returning the same object the second time, which causes a problem because the stream is at EOF and there is no way to seek on this sort of file object. Code: fout = subprocess.Popen("owplaces -silent -multi", shell=True, stdout=subprocess.PIPE).stdout self.output = fout.read() if self.output != []: for line in self.output: print line fout.close() Error: Traceback (most recent call last): File "./saveSettings.py", line 30, in next_page func() File "./saveSettings.py", line 62, in save_startup fout = subprocess.Popen("owplaces -silent -multi", shell=True, stdout=subprocess.PIPE).stdout File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line 61, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/opt/app/g++lib6/python-2.4/lib/python2.4/warnings.py", line 82, in warn_explicit for item in filters: TypeError: an integer is required The first time the code works time. The second (and subsequent times) the cryptic error msg is displayed. Python 2.4.5 running on a Solaris machine. ---------- components: Library (Lib) messages: 69514 nosy: gtg944q severity: normal status: open title: subprocess lib - opening same command fails versions: Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 10 21:39:49 2008 From: report at bugs.python.org (ryanboesch) Date: Thu, 10 Jul 2008 19:39:49 +0000 Subject: [New-bugs-announce] [issue3336] datetime weekday() function In-Reply-To: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za> Message-ID: <1215718789.31.0.810628437344.issue3336@psf.upfronthosting.co.za> New submission from ryanboesch : Leap year ignored each century (2100, 2200, 2300, etc.) except 2000 for the weekday() function. This code reproduces the error: import datetime datetime.date(2100,2,29).weekday() Error message: ValueError: day is out of range for the month Also, this causes the weekday to be 1 day off from March 1st, 2100 to February 28th 2200 and 2 days off... ---------- messages: 69517 nosy: ryanboesch severity: normal status: open title: datetime weekday() function type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 03:51:44 2008 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Jul 2008 01:51:44 +0000 Subject: [New-bugs-announce] [issue3337] Fixer for dbm is failing In-Reply-To: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za> Message-ID: <1215741104.01.0.138500186451.issue3337@psf.upfronthosting.co.za> New submission from Brett Cannon : The fixer for dbm to dbm.ndbm fails test_fixers.Test_imports . ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 69526 nosy: brett.cannon, collinwinter priority: critical severity: normal status: open title: Fixer for dbm is failing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 06:54:22 2008 From: report at bugs.python.org (Darryl Dixon) Date: Fri, 11 Jul 2008 04:54:22 +0000 Subject: [New-bugs-announce] [issue3338] cPickle segfault with deep recursion In-Reply-To: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za> Message-ID: <1215752062.17.0.76482457949.issue3338@psf.upfronthosting.co.za> New submission from Darryl Dixon : In at least Python 2.4, using cPickle.Pickler to try and pickle a nested chain of objects more than about 2590 objects deep causes the Python interpreter to segfault. This doesn't seem to happen when using the pure Python pickle module. It is not memory related (witness that the pure Python module can achieve depths much greater than this just fine), and does not seem to be directly related to system architecture (happens on both i386 and on x86_64 (32bit and 64bit)). Sample interpreter session to replicate: >>> # Let's cause cPickle to segfault: >>> from cPickle import Pickler as cPickler >>> class rec: ... child = None ... def __init__(self, counter): ... if counter > 0: ... self.child = rec(counter-1) ... >>> import sys >>> sys.setrecursionlimit(10000) >>> mychain = rec(2600) >>> from cStringIO import StringIO >>> stream = StringIO() >>> p = cPickler(stream, 1) >>> res = p.dump(mychain) Segmentation fault And now the same steps again using the pure Python Pickler: >>> import sys >>> from pickle import Pickler as pPickler >>> from cStringIO import StringIO >>> class rec: ... child = None ... def __init__(self, counter): ... if counter > 0: ... self.child = rec(counter-1) ... >>> sys.setrecursionlimit(20000) >>> mychain = rec(2600) >>> stream = StringIO() >>> p = pPickler(stream, 1) >>> p.dump(mychain) >>> len(stream.getvalue()) 48676 >>> ---------- components: Library (Lib) messages: 69532 nosy: esrever_otua severity: normal status: open title: cPickle segfault with deep recursion type: crash versions: Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 09:52:35 2008 From: report at bugs.python.org (Henk Punt) Date: Fri, 11 Jul 2008 07:52:35 +0000 Subject: [New-bugs-announce] [issue3339] dummy_thread LockType.acquire() always returns None, should be True or False In-Reply-To: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za> Message-ID: <1215762755.01.0.797304698673.issue3339@psf.upfronthosting.co.za> New submission from Henk Punt : Class LockType always seems to be returning None if waitflag is not specified. If you look up the documentation for the non dummy lock in lib ref 15.3.1 , none of the possible results should be ?None?, in fact it would always return True, except when non-block is specified And another thread is already holding the lock then it would return False >From the docs on acquire(): Acquire a lock, blocking or non-blocking. When invoked without arguments, block until the lock is unlocked, then set it to locked, and return true. When invoked with the blocking argument set to true, do the same thing as when called without arguments, and return true. When invoked with the blocking argument set to false, do not block. If a call without an argument would block, return false immediately; otherwise, do the same thing as when called without arguments, and return true. ---------- components: Library (Lib) messages: 69539 nosy: toymachine severity: normal status: open title: dummy_thread LockType.acquire() always returns None, should be True or False type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 12:46:00 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 11 Jul 2008 10:46:00 +0000 Subject: [New-bugs-announce] [issue3340] optparse print_usage(), .. methods are not documented In-Reply-To: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za> Message-ID: <1215773160.32.0.150230480074.issue3340@psf.upfronthosting.co.za> New submission from anatoly techtonik : optparse API documentation is incomplete. It doesn't mention at least some useful functions such as print_usage(), get_usage(), get/print_version() present in optparse.py docstrings. ---------- assignee: georg.brandl components: Documentation messages: 69543 nosy: georg.brandl, techtonik severity: normal status: open title: optparse print_usage(),.. methods are not documented versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 13:10:09 2008 From: report at bugs.python.org (anatoly techtonik) Date: Fri, 11 Jul 2008 11:10:09 +0000 Subject: [New-bugs-announce] [issue3341] "Suggest a change" link In-Reply-To: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za> Message-ID: <1215774609.12.0.768814080421.issue3341@psf.upfronthosting.co.za> New submission from anatoly techtonik : It would be convenient to have "Suggest a change" link in the bottom of documentation pages to allow people propose fixes and additions. This can be a simple feedback form with an optional "patch" field that submits mail to a list or simply adds documentation comment. More complex approach would be construct patch right in the browser. Then add it for review into "documentation queue". "documentation queue" is a part of documentation system to automatically submit patches after review (and optionally incrementally-recompile existing output formats). In case of page comments review status can be displayed in place together with comments and patches. The whole edit/review process may require single sign on system described in issue #2837 ---------- assignee: georg.brandl components: Documentation messages: 69544 nosy: georg.brandl, techtonik severity: normal status: open title: "Suggest a change" link _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 14:03:12 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 11 Jul 2008 12:03:12 +0000 Subject: [New-bugs-announce] [issue3342] Tracebacks are not properly indented In-Reply-To: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za> Message-ID: <1215777792.78.0.290652492508.issue3342@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : r62555 has the unfortunate effect that source lines are no more indented in tracebacks, as in: Traceback (most recent call last): File "", line 1, in File "C:\python\trunk\lib\re.py", line 150, in sub return _compile(pattern, 0).sub(repl, string, count) File "C:\python\trunk\lib\re.py", line 276, in filter return sre_parse.expand_template(template, match) File "c:\python\trunk\lib\sre_parse.py", line 793, in expand_template raise error, "unmatched group" sre_constants.error: unmatched group And IMO, test_traceback.test_traceback_indentation() tests the wrong behaviour :-( I join a tentative patch to correct the problem. ---------- files: traceback.patch keywords: patch messages: 69546 nosy: amaury.forgeotdarc severity: normal status: open title: Tracebacks are not properly indented Added file: http://bugs.python.org/file10877/traceback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 11 14:20:49 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 11 Jul 2008 12:20:49 +0000 Subject: [New-bugs-announce] [issue3343] Py_DisplaySourceLine is not documented In-Reply-To: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za> Message-ID: <1215778849.22.0.645711118374.issue3343@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : This new function is not documented at all. And I find the error handling not consistent: when filename is NULL, -1 is returned, but no exception is set. IMO the return code should be as follow: - return 1 if a line was printed - return 0 if the line cannot be found - return -1 in case of error (when calling PyFile_WriteString); an exception is set. ---------- components: Interpreter Core messages: 69548 nosy: amaury.forgeotdarc severity: normal status: open title: Py_DisplaySourceLine is not documented type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 12 00:41:53 2008 From: report at bugs.python.org (Tal Einat) Date: Fri, 11 Jul 2008 22:41:53 +0000 Subject: [New-bugs-announce] [issue3344] IDLE - use enumerate instead of zip(count(), ...) In-Reply-To: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za> Message-ID: <1215816113.04.0.292496585151.issue3344@psf.upfronthosting.co.za> New submission from Tal Einat : Just minor code cleanup. Only one instance of zip(count(), ...) in EditorWindow.py, where I also changed 'file' to 'file_name' to avoid overriding the built-in 'file' class. ---------- files: IDLE_EditorWindow_minor.patch keywords: patch messages: 69571 nosy: kbk, taleinat severity: normal status: open title: IDLE - use enumerate instead of zip(count(), ...) Added file: http://bugs.python.org/file10878/IDLE_EditorWindow_minor.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 12 01:30:06 2008 From: report at bugs.python.org (Miki Tebeka) Date: Fri, 11 Jul 2008 23:30:06 +0000 Subject: [New-bugs-announce] [issue3345] Patch for CGIHTTPServer.is_cgi function documentation In-Reply-To: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za> Message-ID: <1215819006.82.0.818103685798.issue3345@psf.upfronthosting.co.za> New submission from Miki Tebeka : The current documentation is wrong and does not specify the fact that this functions sets "cgi_info" (maybe also rename the function?) ---------- assignee: georg.brandl components: Documentation files: CGIHTTPServer.py.diff keywords: patch messages: 69574 nosy: georg.brandl, tebeka severity: normal status: open title: Patch for CGIHTTPServer.is_cgi function documentation versions: Python 2.6 Added file: http://bugs.python.org/file10879/CGIHTTPServer.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 12 12:24:51 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sat, 12 Jul 2008 10:24:51 +0000 Subject: [New-bugs-announce] [issue3346] test_ossaudiodev fails In-Reply-To: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za> Message-ID: <1215858291.72.0.125159107057.issue3346@psf.upfronthosting.co.za> New submission from Ismail Donmez : This is a rather new regression: test_ossaudiodev test test_ossaudiodev failed -- Traceback (most recent call last): File "/home/cartman/Sources/py3k/Lib/test/test_ossaudiodev.py", line 146, in test_playback self.play_sound_file(*sound_info) File "/home/cartman/Sources/py3k/Lib/test/test_ossaudiodev.py", line 66, in play_sound_file setattr(dsp, attr, 42) AttributeError: 'ossaudiodev.oss_audio_device' object has no attribute 'closed' ---------- components: Tests messages: 69582 nosy: cartman severity: normal status: open title: test_ossaudiodev fails versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 12 15:46:17 2008 From: report at bugs.python.org (Matt Giuca) Date: Sat, 12 Jul 2008 13:46:17 +0000 Subject: [New-bugs-announce] [issue3347] urllib.robotparser doesn't work in Py3k In-Reply-To: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za> Message-ID: <1215870377.1.0.267386206374.issue3347@psf.upfronthosting.co.za> New submission from Matt Giuca : urllib.robotparser is broken in Python 3.0, due to a bytes object appearing where a str is expected. Example: >>> import urllib.robotparser >>> r = urllib.robotparser.RobotFileParser('http://www.python.org/robots.txt') >>> r.read() TypeError: expected an object with the buffer interface This is because the variable f in RobotFileParser.read is opened by urlopen as a binary file, so f.read() returns a bytes object. I've included a patch, which checks if it's a bytes, and if so, decodes it with 'utf-8'. A more thorough fix might figure out what the charset of the document is (in f.headers['Content-Type']), but at least this works, and will be sufficient in almost all cases. Also there are no test cases for urllib.robotparser. Patch (robotparser.py.patch) is for branch /branches/py3k, revision 64891. Commit log: Lib/urllib/robotparser.py: Fixed robotparser for Python 3.0. urlopen returns bytes objects where str expected. Decode the bytes using UTF-8. ---------- components: Library (Lib) files: robotparser.py.patch keywords: patch messages: 69586 nosy: mgiuca severity: normal status: open title: urllib.robotparser doesn't work in Py3k type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10885/robotparser.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 12 18:19:28 2008 From: report at bugs.python.org (Matt Giuca) Date: Sat, 12 Jul 2008 16:19:28 +0000 Subject: [New-bugs-announce] [issue3348] Cannot start wsgiref simple server in Py3k In-Reply-To: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za> Message-ID: <1215879568.13.0.955436276561.issue3348@psf.upfronthosting.co.za> New submission from Matt Giuca : The wsgiref "simple server" module has a demo server, which fails to start in Python 3.0 for a bunch of reasons. To verify this, just go into the Lib/wsgiref directory, and run: python3.0 ./simple_server.py (which launches the demo server). This opens your web browser and points it at the server, and you get the following error: ValueError: need more than 1 value to unpack I fixed a number of issues which simply killed the server: * In get_environ, it did not iterate over the headers mapping properly at all (was expecting a sequence of strings, it actually is a mapping). I think the email.message.Message class changed. Fixed. * In demo_app, it calls sort on the output of dict.items() - a list in Python 2, but an iterator in Python 3, so it fails. Fixed (using "sorted"). Unfortunately, the final issue is a bit harder to fix. It seems when I run the demo server, it opens a binary stream, but handlers.py sends strings to be written, giving the error TypeError: send() argument 1 must be bytes or read-only buffer, not str However in the test case, it opens a text stream, so handlers.py works fine. The following *HACK* fixes it so the demo server works, but breaks the test suite (it is NOT included in the attached patch): --- Lib/wsgiref/handlers.py (revision 64895) +++ Lib/wsgiref/handlers.py (working copy) @@ -382,8 +382,8 @@ self.environ.update(self.base_env) def _write(self,data): - self.stdout.write(data) - self._write = self.stdout.write + self.stdout.write(data.encode('utf-8')) + #self._write = self.stdout.write I can't figure out right away what to do about this, but the best solution would be to get the demo server to open the socket in text mode. In any case, the patch is attached for branch /branches/py3k, revision 64895. Commit log: * Lib/wsgiref/simple_server.py: Fixed two fatal errors which prevent the demo server from running (broken due to Python 3.0). Note: Demo server may still not run due to an issue between strings and bytes. ---------- components: Library (Lib) files: simple_server.py.patch keywords: patch messages: 69587 nosy: mgiuca severity: normal status: open title: Cannot start wsgiref simple server in Py3k type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10886/simple_server.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 12 18:40:22 2008 From: report at bugs.python.org (anatoly techtonik) Date: Sat, 12 Jul 2008 16:40:22 +0000 Subject: [New-bugs-announce] [issue3349] search for 'patch' produces roundup error In-Reply-To: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za> Message-ID: <1215880822.27.0.821032673893.issue3349@psf.upfronthosting.co.za> New submission from anatoly techtonik : If you'll try to search 'patch' word in this bugtracker, you will likely to get the error saved in attached file. ---------- files: bugs.python.org.txt messages: 69588 nosy: techtonik severity: normal status: open title: search for 'patch' produces roundup error Added file: http://bugs.python.org/file10887/bugs.python.org.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 13 20:20:42 2008 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 13 Jul 2008 18:20:42 +0000 Subject: [New-bugs-announce] [issue3350] multiprocessing adds built-in types to the global copyreg.dispatch_table In-Reply-To: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za> Message-ID: <1215973242.49.0.0824567359746.issue3350@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti : The multiprocessing module modifies the global copyreg.dispatch_table to extend pickling to several built-in types (mostly callable types). In my humble opinion, this is unacceptable for a standard library module. Here is an example of a behaviour change made by multiprocessing: >>> import pickle >>> pickle.dumps(str.isalpha) Traceback (most recent call last): ... _pickle.PicklingError: Can't pickle : attribute lookup builtins.method_descriptor failed >>> import multiprocessing.util >>> pickle.dumps(str.isalpha) b'\x80\x03cbuiltins\ngetattr\nq\x00cbuiltins\nstr\nq\x01X\x07\x00\x00\x00isalphaq\x02\x86q\x03Rq\x04.' There was some discussion in issue 558238 about allowing methods to be pickled. However, no consensus was reached. In addition, there is a bug in the method pickling support added by multiprocessing in Python 3.0: Python 2.6b1+ (trunk:64899:64900, Jul 13 2008, 13:33:02) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing.util, pickle >>> class A(object): ... def foo(self): pass ... >>> pickle.dumps(A().foo, 2) '\x80\x02c__builtin__\ngetattr\nq\x00c__main__\nA\nq\x01)\x81q\x02}q\x03bU\x03fooq\x04\x86q\x05Rq\x06.' >>> pickle.dumps(A.foo, 2) '\x80\x02c__builtin__\ngetattr\nq\x00c__main__\nA\nq\x01U\x03fooq\x02\x86q\x03Rq\x04.' Python 3.0b1+ (py3k:64876M, Jul 11 2008, 12:20:51) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing.util, pickle >>> class A(object): ... def foo(self): pass ... >>> pickle.dumps(A().foo, 2) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle : it's not found as builtins.method >>> pickle.dumps(A.foo, 2) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle : it's not found as __main__.foo A better solution for the interprocess communication needs of multiprocessing would be to define custom subclass of Pickler with extended support for built-in types. If needed, I am willing to extend the _pickle module in Python 3.0 to support modification to its "dispatch table", like the undocumented dispatch_table attribute in pickle.Pickler. ---------- components: Library (Lib) messages: 69615 nosy: alexandre.vassalotti priority: normal severity: normal status: open title: multiprocessing adds built-in types to the global copyreg.dispatch_table type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 14 05:07:33 2008 From: report at bugs.python.org (yiyuan) Date: Mon, 14 Jul 2008 03:07:33 +0000 Subject: [New-bugs-announce] [issue3351] Python crashed In-Reply-To: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za> Message-ID: <1216004853.72.0.816849271152.issue3351@psf.upfronthosting.co.za> New submission from yiyuan : Hi, I'm new here and I'm not sure whether this should be reported here. OS: CentOS 2.6.9-67.0.15.EL Memory: 512M Python Version: 2.5.1 The crash happened after our web program writen with python running for many days (maybe 20 days). Here are the logs I found in /var/log/messages Jul 14 04:30:38 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000002 Jul 14 04:30:38 kernel: printing eip: Jul 14 04:30:38 kernel: 00000002 Jul 14 04:30:38 kernel: *pde = 0c223067 Jul 14 04:30:38 kernel: Oops: 0000 [#1] Jul 14 04:30:38 kernel: Modules linked in: ipt_state ipt_TOS iptable_mangle ip_conntrack_ftp ip_conntrack_irc ip_conntrack ipt_REJECT ipt_LOG ipt_limit iptable_filter ipt_multiport ip_tables autofs4 sunrpc loop dm_mirror dm_mod ohci_hcd ehci_hcd k8_edac edac_mc snd_atiixp snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tg3 floppy ext3 jbd sata_sil libata sd_mod scsi_mod Jul 14 04:30:38 kernel: CPU: 0 Jul 14 04:30:38 kernel: EIP: 0060:[<00000002>] Not tainted VLI Jul 14 04:30:38 kernel: EFLAGS: 00010202 (2.6.9-67.0.15.EL) Jul 14 04:30:38 kernel: EIP is at 0x2 Jul 14 04:30:38 kernel: eax: c11bf760 ebx: c11bf760 ecx: c11bf760 edx: 00000002 Jul 14 04:30:38 kernel: esi: 00000000 edi: 0000c000 ebp: c5a2e1a8 esp: c7198ecc Jul 14 04:30:38 kernel: ds: 007b es: 007b ss: 0068 Jul 14 04:30:38 kernel: Process python (pid: 16598, threadinfo=c7198000 task=c8cccbd0) Jul 14 04:30:38 kernel: Stack: c01514ee c015ab59 0dfbb067 00080000 1ec5e000 c0411074 1ec5e000 1ecde000 Jul 14 04:30:38 kernel: d3a2e1f0 c0411074 c015ac29 00080000 00000000 1ec5e000 d3a2e1f0 1ecde000 Jul 14 04:30:38 kernel: c0411074 c015ac88 00080000 00000000 c7198f7c 1ec5e000 cd708b4c 1edac000 Jul 14 04:30:38 kernel: Call Trace: Jul 14 04:30:38 kernel: [] set_page_dirty+0x2c/0x41 Jul 14 04:30:38 kernel: [] zap_pte_range+0x191/0x21f Jul 14 04:30:38 kernel: [] zap_pmd_range+0x42/0x65 Jul 14 04:30:38 kernel: [] unmap_page_range+0x3c/0x5f Jul 14 04:30:38 kernel: [] unmap_vmas+0xf1/0x1df Jul 14 04:30:38 kernel: [] unmap_region+0x61/0xc6 Jul 14 04:30:38 kernel: [] do_munmap+0x144/0x1b1 Jul 14 04:30:38 kernel: [] sys_munmap+0x51/0x68 Jul 14 04:30:38 kernel: [] syscall_call+0x7/0xb Jul 14 04:30:38 kernel: Code: Bad EIP value. Jul 14 04:30:38 kernel: <0>Fatal exception: panic in 5 seconds Jul 14 04:30:38 kernel: bad: scheduling while atomic! Jul 14 04:30:38 kernel: [] schedule+0x2d/0x606 Jul 14 04:30:38 kernel: [] schedule_timeout+0x158/0x17c Jul 14 04:30:38 kernel: [] process_timeout+0x0/0x13 Jul 14 04:30:38 kernel: [] printk+0xe/0x11 Jul 14 04:30:38 kernel: [] die+0x21a/0x22b Jul 14 04:30:38 kernel: [] do_page_fault+0x380/0x4dc Jul 14 04:30:38 kernel: [] buffered_rmqueue+0x1c4/0x1e7 Jul 14 04:30:38 kernel: [] __alloc_pages+0xb4/0x2a6 Jul 14 04:30:38 kernel: [] do_page_fault+0x0/0x4dc Jul 14 04:30:38 kernel: [] error_code+0x2f/0x38 Jul 14 04:30:38 kernel: [] set_page_dirty+0x2c/0x41 Jul 14 04:30:38 kernel: [] zap_pte_range+0x191/0x21f Jul 14 04:30:38 kernel: [] zap_pmd_range+0x42/0x65 Jul 14 04:30:38 kernel: [] unmap_page_range+0x3c/0x5f Jul 14 04:30:38 kernel: [] unmap_vmas+0xf1/0x1df Jul 14 04:30:38 kernel: [] unmap_region+0x61/0xc6 Jul 14 04:30:38 kernel: [] do_munmap+0x144/0x1b1 Jul 14 04:30:38 kernel: [] sys_munmap+0x51/0x68 Jul 14 04:30:38 kernel: [] syscall_call+0x7/0xb What caused this problem? Run out of memory? Please tell me what I can do. Regards YiYuan ---------- components: Interpreter Core messages: 69640 nosy: yiyuan severity: normal status: open title: Python crashed type: crash versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 14 11:57:56 2008 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Jul 2008 09:57:56 +0000 Subject: [New-bugs-announce] [issue3352] Deficiencies in multiprocessing/threading API In-Reply-To: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za> Message-ID: <1216029476.59.0.254562018699.issue3352@psf.upfronthosting.co.za> New submission from Nick Coghlan : The "PEP 8 compliant" API for multiprocessing and threading needs to be cleaned up before release as per the thread on python-dev. The release manager gave approval for this change during that discussion [1]. Changes needed: - remove Py3k warnings from the threading module (old API is going to be kept around even in Py3k) - change get_name/set_name into a "name" property - change is_daemon/set_daemon into a "daemon" property (Note that changing "is_alive" to be a property is not on that list - that can be a fairly expensive thing to check for the multiprocessing library. I also left out active_count(), as I think the underscore adds clarity in that case) [1] http://mail.python.org/pipermail/python-dev/2008-June/080285.html ---------- components: Library (Lib) messages: 69647 nosy: ncoghlan priority: release blocker severity: normal status: open title: Deficiencies in multiprocessing/threading API type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 14 13:33:16 2008 From: report at bugs.python.org (Fredrik Lundh) Date: Mon, 14 Jul 2008 11:33:16 +0000 Subject: [New-bugs-announce] [issue3353] make built-in tokenizer available via Python C API In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za> Message-ID: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za> New submission from Fredrik Lundh : CPython provides a Python-level API to the parser, but not to the tokenizer itself. Somewhat annoyingly, it does provide a nice C API, but that's not properly exposed for external modules. To fix this, the tokenizer.h file should be moved from the Parser directory to the Include directory, and the (semi-public) functions that already available must be flagged with PyAPI_FUNC, as shown below. The PyAPI_FUNC fix should be non-intrusive enough to go into 2.6 and 3.0; moving stuff around is perhaps better left for a later release (which could also include a Python binding). Index: tokenizer.h =================================================================== --- tokenizer.h (revision 514) +++ tokenizer.h (working copy) @@ -54,10 +54,10 @@ const char* str; }; -extern struct tok_state *PyTokenizer_FromString(const char *); -extern struct tok_state *PyTokenizer_FromFile(FILE *, char *, char *); -extern void PyTokenizer_Free(struct tok_state *); -extern int PyTokenizer_Get(struct tok_state *, char **, char **); +PyAPI_FUNC(struct tok_state *) PyTokenizer_FromString(const char *); +PyAPI_FUNC(struct tok_state *) PyTokenizer_FromFile(FILE *, char *, char *); +PyAPI_FUNC(void) PyTokenizer_Free(struct tok_state *); +PyAPI_FUNC(int) PyTokenizer_Get(struct tok_state *, char **, char **); #ifdef __cplusplus } ---------- components: Interpreter Core messages: 69650 nosy: effbot severity: normal status: open title: make built-in tokenizer available via Python C API type: feature request versions: Python 2.6, Python 2.7, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 14 14:54:23 2008 From: report at bugs.python.org (Christoph Zwerschke) Date: Mon, 14 Jul 2008 12:54:23 +0000 Subject: [New-bugs-announce] [issue3354] sort(reverse=None) prints misleading error message In-Reply-To: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za> Message-ID: <1216040063.73.0.634067891199.issue3354@psf.upfronthosting.co.za> New submission from Christoph Zwerschke : When you sort a list with list.sort() or sorted(list), and set the reverse parameter to None, then you get the following misleading error message: TypeError: an integer is required I would expect a more proper error message for the reverse parameter, such as "reverse must be a boolean", and maybe reverse=None also accepted as default value, i.e. False. ---------- components: Interpreter Core messages: 69651 nosy: cito severity: normal status: open title: sort(reverse=None) prints misleading error message type: behavior versions: Python 2.4, Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 14 21:31:42 2008 From: report at bugs.python.org (Kumar McMillan) Date: Mon, 14 Jul 2008 19:31:42 +0000 Subject: [New-bugs-announce] [issue3355] Display bug in :show-inheritance: for class with standard docstring In-Reply-To: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za> Message-ID: <1216063902.37.0.436580561453.issue3355@psf.upfronthosting.co.za> New submission from Kumar McMillan : Using Sphinx 0.4.1 I noticed a slight display bug in rendering :show-inheritance: for a class with a PEP 8 / PEP 257 style docstring. i.e. multi-line docstrings are recommended by the PEPs to look like: class Foo(SomeFoo): """Return a foobang Optional plotz says to frobnicate the bizbaz first. """ Using Sphinx autodoc extension, the default skin, and... .. autoclass:: path.to.Foo :show-inheritance: ...will show a link to bases but immediately after it (no line break) is the first line of the doc. This is confusing to read. However, changing the docstring of the class to add a break like: class Foo(SomeFoo): """ Return a foobang Optional plotz says to frobnicate the bizbaz first. """ fixes the problem. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 69660 nosy: georg.brandl, kumar303 severity: normal status: open title: Display bug in :show-inheritance: for class with standard docstring type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 14 23:15:29 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Jul 2008 21:15:29 +0000 Subject: [New-bugs-announce] [issue3356] some tests fail in debug mode (test_distutils, test_set) In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za> Message-ID: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za> New submission from Antoine Pitrou : With the latest py3k, some tests fail when run in debug mode: - test_distutils fails with the following message: FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_distutils.py", line 17, in test_main() File "Lib/test/test_distutils.py", line 13, in test_main test.support.run_unittest(distutils.tests.test_suite()) File "/home/antoine/py3k/pristine/Lib/test/support.py", line 717, in run_unittest _run_suite(suite) File "/home/antoine/py3k/pristine/Lib/test/support.py", line 700, in _run_suite raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "/home/antoine/py3k/pristine/Lib/distutils/tests/test_build_ext.py", line 48, in test_build_ext import xx AttributeError: mro - test_set crashes with the following message: ./python Lib/test/test_set.py test_add (__main__.TestSet) ... ok test_and (__main__.TestSet) ... ok test_badcmp (__main__.TestSet) ... ok test_c_api (__main__.TestSet) ... Fatal Python error: Objects/setobject.c:2429 object at 0xb797ce04 has negative ref count -1 Abandon ---------- components: Tests messages: 69661 nosy: pitrou severity: normal status: open title: some tests fail in debug mode (test_distutils, test_set) type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 01:37:51 2008 From: report at bugs.python.org (Chester) Date: Mon, 14 Jul 2008 23:37:51 +0000 Subject: [New-bugs-announce] [issue3357] A bug in the __doc__ string of the sys module In-Reply-To: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za> Message-ID: <1216078670.93.0.80327541443.issue3357@psf.upfronthosting.co.za> New submission from Chester : This relates to Python 3.x. Do this please: import sys; print(sys.__doc__) Please fix the following line of text in that __doc__ file of the sys module: stdin -- standard input file object; used by raw_input() and input() This line of text should just be stdin -- standard input file object; used by input() because raw_input() does not exist anymore in Python 3.x. ---------- assignee: georg.brandl components: Documentation messages: 69668 nosy: cheDu, georg.brandl severity: normal status: open title: A bug in the __doc__ string of the sys module versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 06:12:29 2008 From: report at bugs.python.org (Nick Edds) Date: Tue, 15 Jul 2008 04:12:29 +0000 Subject: [New-bugs-announce] [issue3358] 2to3 Iterative Wildcard Matching In-Reply-To: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za> Message-ID: <1216095149.85.0.174459482366.issue3358@psf.upfronthosting.co.za> New submission from Nick Edds : Here is an iterative replacement to _recursive_matches for Wildcard Patterns. It's not really much faster now, although I think there is some room to improve it. It's doesn't seem like the most elegant solution, but it works. It passes all of the tests, although I had to rewrite one because it was generating the same matches but in a different order. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: iterative.diff keywords: patch messages: 69672 nosy: collinwinter, nedds severity: normal status: open title: 2to3 Iterative Wildcard Matching Added file: http://bugs.python.org/file10896/iterative.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 07:21:49 2008 From: report at bugs.python.org (anatoly techtonik) Date: Tue, 15 Jul 2008 05:21:49 +0000 Subject: [New-bugs-announce] [issue3359] add 'rbU' mode to open() In-Reply-To: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za> Message-ID: <1216099309.77.0.222118246424.issue3359@psf.upfronthosting.co.za> New submission from anatoly techtonik : 'rU' universal newline support is useless, because read lines end with '\n' regardless of actual line end in the source file. Applications that care about line ends still open file in binary mode and gather the stats manually. So, to make this mode useful - the 'rbU' should be addded. Otherwise it doesn't worth complication both in C code and in documentation. ---------- components: Library (Lib) messages: 69673 nosy: techtonik severity: normal status: open title: add 'rbU' mode to open() versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 12:45:38 2008 From: report at bugs.python.org (Richard B. Kreckel) Date: Tue, 15 Jul 2008 10:45:38 +0000 Subject: [New-bugs-announce] [issue3360] Inconsistent type-deduction of decimal floating-point In-Reply-To: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za> Message-ID: <1216118738.54.0.735219671466.issue3360@psf.upfronthosting.co.za> New submission from Richard B. Kreckel : When constructing a floating-point value, literals are apparently sometimes interpreted as octal integral types, although they contain exponent marker or/and decimal point. The presence of exponent marker or/and decimal point should suffice to identify it as floating-point. Example: >>> x = 02120246124e0 >>> x = 02120246124.0 >>> x = 021202461241e0 ValueError: invalid literal for long() with base 8: '021202461241e0' >>> x = 021202461241.0 ValueError: invalid literal for long() with base 8: '021202461241.0' I am using Python 2.5.1 from openSuSE 10.3. ---------- components: Interpreter Core messages: 69677 nosy: richyk severity: normal status: open title: Inconsistent type-deduction of decimal floating-point versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 13:54:55 2008 From: report at bugs.python.org (Wolfgang Langner) Date: Tue, 15 Jul 2008 11:54:55 +0000 Subject: [New-bugs-announce] [issue3361] pypi issue tracker link (python.org) In-Reply-To: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za> Message-ID: <1216122895.94.0.048597402598.issue3361@psf.upfronthosting.co.za> New submission from Wolfgang Langner : Some links still point to the sourceforge bug tracker. (one from http://pypi.python.org/pypi bug reports). Check if there are others and let them point to the new bug tracker. ---------- components: None messages: 69680 nosy: tds333 severity: normal status: open title: pypi issue tracker link (python.org) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 16:22:30 2008 From: report at bugs.python.org (cfr) Date: Tue, 15 Jul 2008 14:22:30 +0000 Subject: [New-bugs-announce] [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za> Message-ID: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za> New submission from cfr : Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys, locale >>> locale.getpreferredencoding() Bus error Sample crash report excerpt follows (plenty more available on request!). Note that the version of python given in the crash report is *not* the same as the version of python actually in use. I have never had an alpha version of python installed. The current version is the standard version of 2.5.2 available as a dmg download from python.org i.e. the universal framework build for 10.4. OS Version: 10.4.11 (Build 8S165) Report Version: 4 Command: Python Path: /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python Parent: bash [27154] Version: 2.5a0 (2.5alpha0) PID: 4692 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 com.apple.CoreFoundation 0x907beac0 CFStringGetCStringPtr + 408 1 _locale.so 0x000f1cd8 PyLocale_getdefaultlocale + 328 (_localemodule.c:435) 2 org.python.python 0x002b393c PyEval_EvalFrameEx + 17036 (ceval.c:3557) 3 org.python.python 0x002b5e50 PyEval_EvalCodeEx + 2096 (ceval.c:2836) 4 org.python.python 0x002b3f48 PyEval_EvalFrameEx + 18584 (ceval.c:3669) 5 org.python.python 0x002b5e50 PyEval_EvalCodeEx + 2096 (ceval.c:2836) 6 org.python.python 0x002b5ff0 PyEval_EvalCode + 48 (ceval.c:500) 7 org.python.python 0x002dbb24 PyRun_InteractiveOneFlags + 772 (pythonrun.c:1274) 8 org.python.python 0x002dbd30 PyRun_InteractiveLoopFlags + 288 (pythonrun.c:725) 9 org.python.python 0x002dc3f0 PyRun_AnyFileExFlags + 176 (pythonrun.c:693) 10 org.python.python 0x002eba9c Py_Main + 3052 (main.c:523) 11 org.python.python 0x000019bc 0x1000 + 2492 12 org.python.python 0x000016c0 0x1000 + 1728 Thread 0 crashed with PPC Thread State 64: srr0: 0x00000000907beac0 srr1: 0x000000000000d030 vrsave: 0x0000000000000000 cr: 0x84244224 xer: 0x0000000020000004 lr: 0x00000000907be930 ctr: 0x00000000907be928 r0: 0x00000000a07bb678 r1: 0x00000000bfffd3a0 r2: 0x00000000a07bb278 r3: 0x0000000000000000 r4: 0x0000000000000000 r5: 0x00000000bfffd2e0 r6: 0x0000000000000005 r7: 0x0000000000000007 r8: 0x0000000000702333 r9: 0x000000000000001c r10: 0x0000000090bb4bb8 r11: 0x00000000000f33d8 r12: 0x00000000907be928 r13: 0x0000000000058b24 r14: 0x0000000000071e40 r15: 0x000000000006aa20 r16: 0x0000000000000000 r17: 0x0000000000000001 r18: 0x00000000000732a8 r19: 0x0000000000619410 r20: 0x0000000000000000 r21: 0x000000000006a9b0 r22: 0x0000000000000000 r23: 0x0000000000058b39 r24: 0x00000000000f1b90 r25: 0x00000000006001d0 r26: 0x000000000007e300 r27: 0x0000000000000000 r28: 0x0000000000000000 r29: 0x00000000a07bbb6c r30: 0x0000000000000000 r31: 0x00000000907be930 Binary Images Description: 0x1000 - 0x1fff org.python.python 2.5a0 (2.5alpha0) /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 0xa2000 - 0xd9fff readline.so /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/readline.so 0xf0000 - 0xf2fff _locale.so /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_locale.so 0x205000 - 0x323fff org.python.python 2.5a0 (2.5) /Library/Frameworks/Python.framework/Versions/2.5/Python 0x705000 - 0x74afff libncurses.5.dylib /Library/Frameworks/Python.framework/Versions/2.5/lib/libncurses.5.dylib 0x7de000 - 0x7e1fff operator.so /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/operator.so 0x8fe00000 - 0x8fe52fff dyld 46.16 /usr/lib/dyld 0x90000000 - 0x901bcfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90214000 - 0x90219fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x907bb000 - 0x90895fff com.apple.CoreFoundation 6.4.11 (368.35) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x908e0000 - 0x909e2fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x90a3c000 - 0x90ac0fff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90aea000 - 0x90b5afff com.apple.framework.IOKit 1.4 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x90b70000 - 0x90b82fff libauto.dylib /usr/lib/libauto.dylib 0x90b89000 - 0x90e60fff com.apple.CoreServices.CarbonCore 681.17 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x91111000 - 0x9111ffff libz.1.dylib /usr/lib/libz.1.dylib 0x91122000 - 0x912ddfff com.apple.security 4.6 (29770) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x913dc000 - 0x913e5fff com.apple.DiskArbitration 2.1.2 /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x913ec000 - 0x913f4fff libbsm.dylib /usr/lib/libbsm.dylib 0x913f8000 - 0x91420fff com.apple.SystemConfiguration 1.8.3 /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x91433000 - 0x9143efff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib 0x945e4000 - 0x94604fff libmx.A.dylib /usr/lib/libmx.A.dylib I have got as far as I can tracking this issue down but would be happy to provide further information if somebody would give me (a pointer to) instructions or a hint. ---------- messages: 69683 nosy: cfr severity: normal status: open title: locale.getpreferredencoding() gives bus error on Mac OS X 10.4.11 PPC type: crash versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 16:36:51 2008 From: report at bugs.python.org (cfr) Date: Tue, 15 Jul 2008 14:36:51 +0000 Subject: [New-bugs-announce] [issue3363] python version incorrectly reported in crash reports on Mac OS X 10.4.11 PPC In-Reply-To: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za> Message-ID: <1216132611.85.0.270586001312.issue3363@psf.upfronthosting.co.za> New submission from cfr : Although the active version of python on my machine is 2.5.2 and I have never had an alpha version installed, crash reports for python report the version as "2.5a0 (2.5alpha0)". Version details: active version of python is from the current python.org dmg download for Mac OS X 10.4 i.e. the universal framework build. When starting python, I get: Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. but in crash reports, I get: Command: Python Path: /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python Parent: bash [27154] Version: 2.5a0 (2.5alpha0) and python is given as version 2.5a0 in the binary image listing which follows. Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC I think I did have 2.5.1 installed prior to installing 2.5.2 and I also have two older versions of python installed - 2.4 (also the python.org build) and 2.3 (as pre-installed by Apple) - but I never installed 2.5.0 or any version/candidate in the 2.5 line prior to 2.5.1. I'm not sure what further information might be helpful but would be happy to provide it on request. ---------- components: None messages: 69686 nosy: cfr severity: normal status: open title: python version incorrectly reported in crash reports on Mac OS X 10.4.11 PPC type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 17:23:58 2008 From: report at bugs.python.org (Chester) Date: Tue, 15 Jul 2008 15:23:58 +0000 Subject: [New-bugs-announce] [issue3364] An ortographical typo in Zen of Python text In-Reply-To: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za> Message-ID: <1216135438.83.0.733910076537.issue3364@psf.upfronthosting.co.za> New submission from Chester : I hope I chose the correct component type for this issue report. Anyway, if you do import this in the Python 3.x interactive interpreter, you get the Zen of Python by Tim Peters. This text has a line which has an ortographical typo in it. Please look at this line of text from the Zen of Python: There should be one-- and preferably only one --obvious way to do it. Now this line has the typo I am talking about, and the typo is the lack of a space before the first dash (actually before the double-hyphen) and the space after the second dash (or double-hyphen). Please note that the dash punctuation mark is by ortographical rules separated from the words, so there are two spaces separating a dash from the surrounding words. By writing the dashes in the way that are in the above sentence from the Zen of Python, we don't achieve any effect as sometimes ortographical rules can be broken to create some special effect in the sentence (like in a line that uses the asteriskes to emphasize the word 'right' with writing it as *right*), but here in the above line it is clearly a normal sentence, not needing any special effect, which is also incorrect from this point of view. So please fix the above line like this: There should be one -- and preferably only one -- obvious way to do it. Consider the fact that the last sentence is written correctly and that the dash in it is separated from the surrounding words as the ortographic rules demand. So having one line of text with an incorrectly used dash and some other line with the correctly used dash, makes the whole text either inconsistent or just bad. Okay, it isn't *really* bad but it's incorrect and it needs a little fix. And it's not too much trouble to add two missing spaces in that line of text. I think that ortography is our friend in the Python world. ;) ---------- assignee: georg.brandl components: Documentation messages: 69688 nosy: cheDu, georg.brandl severity: normal status: open title: An ortographical typo in Zen of Python text versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 18:13:45 2008 From: report at bugs.python.org (TanaT) Date: Tue, 15 Jul 2008 16:13:45 +0000 Subject: [New-bugs-announce] [issue3365] in module math, PI value seems to be wrong after digit 17th In-Reply-To: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za> Message-ID: <1216138425.08.0.91328396117.issue3365@psf.upfronthosting.co.za> New submission from TanaT : Hello, This is my first Issue creation (I looked for "PI" in issue tracker and found nothing): Please forgive any mistake. Here is the point : I typed the following commands : >>> import math >>> print '%1.26f' % math.pi 3.14159265358979311599796347 In fact, PI value is 3,14159265358979323846264338327950288... ^ I don't know if PI value is computed in Python : If it is, this issue is probably already dead ! But if PI is just saved in math library, there could be an improvement. ---------- components: None messages: 69693 nosy: TanaT severity: normal status: open title: in module math, PI value seems to be wrong after digit 17th type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 19:37:54 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Jul 2008 17:37:54 +0000 Subject: [New-bugs-announce] [issue3366] Add gamma and error functions to math module In-Reply-To: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za> Message-ID: <1216143474.22.0.677620310024.issue3366@psf.upfronthosting.co.za> New submission from Terry J. Reedy : >From Py3000 list: in C99 standard math library, but need code when not yet in particular implementation. Dickinson: open and assign to me Stutzbach: I suggest using the versions from newlib's libm. They contain extensive comments explaining the math and have a generous license, e.g.,: http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/newlib/libm/math/s_erf.c?rev=1.1.1.1&cvsroot=src ---------- assignee: marketdickinson components: Library (Lib) messages: 69698 nosy: marketdickinson, tjreedy severity: normal status: open title: Add gamma and error functions to math module type: feature request versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 22:21:04 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 15 Jul 2008 20:21:04 +0000 Subject: [New-bugs-announce] [issue3367] Uninitialized value read in parsetok.c In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za> Message-ID: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : If a PyTokenizer_FromString() is called with an empty string, the tokenizer's line_start member never gets initialized. Later, it is compared with the token pointer 'a' in parsetok.c:193 and that behavior can result in undefined behavior. Found using Rational Purify for windows. A patch is provided. ---------- files: tmp1.patch keywords: easy, patch, patch messages: 69714 nosy: krisvale severity: normal status: open title: Uninitialized value read in parsetok.c type: crash versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file10898/tmp1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 23:18:36 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 15 Jul 2008 21:18:36 +0000 Subject: [New-bugs-announce] [issue3368] Memory leak in import.c In-Reply-To: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za> Message-ID: <1216156715.63.0.327674060431.issue3368@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : Failure to deallocate a buffer returned by PyArg_ParseTuple. Patch is attached. Found using purify while running the testsuite. ---------- components: Interpreter Core files: tmp3.patch keywords: easy, patch, patch messages: 69719 nosy: krisvale severity: normal status: open title: Memory leak in import.c type: resource usage versions: Python 3.0 Added file: http://bugs.python.org/file10900/tmp3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 15 23:42:26 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 15 Jul 2008 21:42:26 +0000 Subject: [New-bugs-announce] [issue3369] memory leak in floatobject.c In-Reply-To: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za> Message-ID: <1216158146.44.0.605906648697.issue3369@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : When a nan or inf is generated in PyFloat_FromString(), a temporary buffer may be left behind. Patch attached. Found using Purify ---------- components: Interpreter Core files: tmp4.patch keywords: easy, patch, patch messages: 69721 nosy: krisvale severity: normal status: open title: memory leak in floatobject.c versions: Python 3.0 Added file: http://bugs.python.org/file10901/tmp4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 00:20:35 2008 From: report at bugs.python.org (Matt McCredie) Date: Tue, 15 Jul 2008 22:20:35 +0000 Subject: [New-bugs-announce] [issue3370] importing with_statement causes exec to raise syntax error on block that doesn't end with a newline In-Reply-To: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za> Message-ID: <1216160435.89.0.00837821764809.issue3370@psf.upfronthosting.co.za> New submission from Matt McCredie : The following session demonstrates the issue: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> exec "def foo():\n return 0" # no ending newline works fine >>> foo() 0 >>> exec "def foo():\n return 1\n" # with an ending newline works fine >>> foo() 1 >>> from __future__ import with_statement >>> exec "def foo():\n return 2\n" # with an ending newline works fine >>> foo() 2 >>> exec "def foo():\n return 3" # without an ending new line... breaks Traceback (most recent call last): File "", line 1, in File "", line 2 return 3 ^ Possibly related to http://bugs.python.org/issue1184112, and/or http://bugs.python.org/issue501622? ---------- components: Interpreter Core messages: 69723 nosy: mccredie severity: normal status: open title: importing with_statement causes exec to raise syntax error on block that doesn't end with a newline versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 02:43:21 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 16 Jul 2008 00:43:21 +0000 Subject: [New-bugs-announce] [issue3371] 2to3 fails in 3.0 In-Reply-To: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za> Message-ID: <1216169000.89.0.760925627097.issue3371@psf.upfronthosting.co.za> New submission from Benjamin Peterson : I'm disabling lib2to3 in the trunk because it fails just for Python 2.6. (Python 2.5 and 3.0 are fine.) ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 69739 nosy: benjamin.peterson, collinwinter priority: deferred blocker severity: normal status: open title: 2to3 fails in 3.0 versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 03:38:52 2008 From: report at bugs.python.org (Niall O'Higgins) Date: Wed, 16 Jul 2008 01:38:52 +0000 Subject: [New-bugs-announce] [issue3372] socket.setsockopt() is broken for multicast TTL and Loop options In-Reply-To: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za> Message-ID: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za> New submission from Niall O'Higgins : socket.setsockopt() sets an optlen of '4' in the setsockopt system call for options IP_MULTICAST_TTL and IP_MULTICAST_LOOP. On OpenBSD, this causes the kernel to hit an error condition and set errno 22 when these options are set: socket.error: (22, 'Invalid argument') Yielded by e.g. socket.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 1) According to both FreeBSD and OpenBSD manual pages (see e.g. http://www.freebsd.org/cgi/man.cgi?query=ip&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html), these fields are in fact both 8 bit unsigned, and the manuals suggest the following: u_char ttl; /* range: 0 to 255, default = 1 */ setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl)); While '4' (sizeof int) is correct for many options, special casing is needed in Modules/socketmodule.c. The following diff fixes the issue for me on OpenBSD: @@ -1716,12 +1719,8 @@ sock_setsockopt(PySocketSockObject *s, PyObject *args) if (PyArg_ParseTuple(args, "iii:setsockopt", &level, &optname, &flag)) { - buflen = sizeof flag; - /* Multi cast options take shorter arguments */ - if (optname == IP_MULTICAST_TTL - || optname == IP_MULTICAST_LOOP) - buflen = sizeof(u_char); buf = (char *) &flag; + buflen = sizeof flag; } else { PyErr_Clear(); ---------- components: Library (Lib) messages: 69741 nosy: niallo severity: normal status: open title: socket.setsockopt() is broken for multicast TTL and Loop options type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 06:01:53 2008 From: report at bugs.python.org (Darryl Dixon) Date: Wed, 16 Jul 2008 04:01:53 +0000 Subject: [New-bugs-announce] [issue3373] sys recursion limit a lot shorter on trunk? In-Reply-To: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za> Message-ID: <1216180913.45.0.197012518683.issue3373@psf.upfronthosting.co.za> New submission from Darryl Dixon : The system recursion limit seems to be wildly different in its behaviour on 2.6/trunk versus, for example, 2.5 or 2.4, EG: On Python 2.4: Python 2.4.3 (#1, Dec 11 2006, 11:38:52) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class rec(object): ... child = None ... def __init__(self, counter): ... if counter > 0: ... self.child = rec(counter-1) ... >>> mychain = rec(998) >>> On Python 2.6/trunk: Python 2.6b1+ (trunk:64998, Jul 16 2008, 15:50:22) [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class rec(object): ... child = None ... def __init__(self, counter): ... if counter > 0: ... self.child = rec(counter-1) ... >>> mychain = rec(249) Traceback (most recent call last): File "", line 1, in File "", line 5, in __init__ [...snip...] File "", line 5, in __init__ RuntimeError: maximum recursion depth exceeded >>> In both cases sys.getrecursionlimit() shows 1000. Is this behaviour intentional? It looks a lot like a regression of some sort. It appears to be effectively 4x shorter when creating the nested object graph. ---------- components: Interpreter Core messages: 69758 nosy: esrever_otua severity: normal status: open title: sys recursion limit a lot shorter on trunk? type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 14:21:36 2008 From: report at bugs.python.org (Dan Uznanski) Date: Wed, 16 Jul 2008 12:21:36 +0000 Subject: [New-bugs-announce] [issue3374] Bisect upgrades: key/cmp/reverse, parameterized handedness In-Reply-To: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za> Message-ID: <1216210896.71.0.891255870146.issue3374@psf.upfronthosting.co.za> New submission from Dan Uznanski : Attached find a unified diff that upgrades the bisect module in two important ways: 1. bisect and friends now understand cmp, key, and reverse, the same way that list.sort does. 2. bisect and insort now have parameterized handedness: instead of using two different functions depending on whether you want new items to show up before or after existing ones, bisect and insort now take a flag called 'right' which can change the handedness on the fly. Currently this code fails two existing regression tests: test_backcompatibility, because bisect is no longer the same as bisect_right; and test_non_sequence, because insort now raises AttributeError instead of TypeError when called on an int. Still to do, in order of priority as perceived by me: 1. A C version of the code needs to be written. 2. The error handling should be worked over by somebody with more knowledge than I - the regression tests assume that particular failures (len-only, get-only, and non-sequence) will happen with one of TypeError or AttributeError when in reality they may raise the other. 3. The tests for new functionality should be made more exhaustive. 4. The in-module documentation probably needs cleaning; the rst documentation needs my name added to it (a good deal of the existing writing is still Fred L Drake's, so I won't replace) and needs to have the "section 3.6.4" part linked to Mutable Sequence Types; I couldn't find an actual example of that linkage. 5. The godawful conditions in bisect should probably get cleaned up. ---------- components: Library (Lib) files: bisect-2.7.diff keywords: patch messages: 69773 nosy: dan.uznanski severity: normal status: open title: Bisect upgrades: key/cmp/reverse, parameterized handedness versions: Python 2.7 Added file: http://bugs.python.org/file10904/bisect-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 14:57:16 2008 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 16 Jul 2008 12:57:16 +0000 Subject: [New-bugs-announce] [issue3375] _multiprocessing.so build problems In-Reply-To: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za> Message-ID: <1216213036.27.0.498692237494.issue3375@psf.upfronthosting.co.za> New submission from Barry A. Warsaw : _multiprocessing.so has build problems on both OS X 10.5 and Ubuntu Linux 8.04. It's very strange though because there are no apparent errors in compilation, however when the build process tries to import the module, that fails and it gets moved to _multiprocessing_failed.so. Interestingly enough, a subsequent 'make' succeeds, as does just renaming the lib back to _multiprocessing.so. Sorry, I have no more clues than that, but see also but 3088. ---------- components: Build messages: 69777 nosy: barry priority: release blocker severity: normal status: open title: _multiprocessing.so build problems versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 15:27:39 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 16 Jul 2008 13:27:39 +0000 Subject: [New-bugs-announce] [issue3376] Use Python 3 lexer for 3.0 docs Message-ID: <1216214859.34.0.300378511478.issue3376@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: georg.brandl components: Documentation, Documentation tools (Sphinx) nosy: georg.brandl priority: low severity: normal status: open title: Use Python 3 lexer for 3.0 docs versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 15:44:27 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 16 Jul 2008 13:44:27 +0000 Subject: [New-bugs-announce] [issue3377] Invalid child node access in ast.c In-Reply-To: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za> Message-ID: <1216215867.69.0.0669187139493.issue3377@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : Purify complained about reading uninitialized memory in ast.c:752 of two bytes which corresponds to the type field. Looking into this, line 750 increments i without checking that there are in fact this many children. If you add the line: assert(i < NCH(n)); after line 750 you get an assertion failure when you run test_keywordonlyarg in the testsuite ---------- components: Interpreter Core messages: 69787 nosy: krisvale severity: normal status: open title: Invalid child node access in ast.c type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 16:07:12 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 16 Jul 2008 14:07:12 +0000 Subject: [New-bugs-announce] [issue3378] Memory leak in pythonrun.c In-Reply-To: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za> Message-ID: <1216217232.24.0.010900807633.issue3378@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : In some cases, an error string generated by parsetok.c is not cleared by err_input(). A patch is provided. ---------- components: Interpreter Core files: tmp5.patch keywords: patch, patch messages: 69788 nosy: krisvale severity: normal status: open title: Memory leak in pythonrun.c type: resource usage versions: Python 3.0 Added file: http://bugs.python.org/file10905/tmp5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 17:13:22 2008 From: report at bugs.python.org (=?utf-8?q?J._Pablo_Fern=C3=A1ndez?=) Date: Wed, 16 Jul 2008 15:13:22 +0000 Subject: [New-bugs-announce] [issue3379] Option to not-exit on test In-Reply-To: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za> Message-ID: <1216221202.34.0.503221708594.issue3379@psf.upfronthosting.co.za> New submission from J. Pablo Fern?ndez : Added an option, called exit, that when set to false, will make the tests not exit at the end. This is useful when you are doing Lisp-like development having a REPL (interpreter/prompt) opened in Emacs and running the tests over and over on it. Currently, the tests will exit the interpreter, causing the in-Emacs interpreter to close as well. It is by default set to false, so the default behavior is still the same. When set to true the default behavior shouldn't change much because at the end of the tests you are going to exit anyway. The only difference is that no exit code will be provided. There's actually something else, because the Python test suite hangs in a test case when this is set to true, but this should be of no concern, as default is false. ---------- components: Library (Lib) files: add_avoid_exit_option.diff keywords: patch messages: 69791 nosy: pupeno severity: normal status: open title: Option to not-exit on test type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file10906/add_avoid_exit_option.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 18:20:56 2008 From: report at bugs.python.org (John Williams) Date: Wed, 16 Jul 2008 16:20:56 +0000 Subject: [New-bugs-announce] [issue3380] documentation for ElementTree is unusable In-Reply-To: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za> Message-ID: <1216225256.86.0.640649586019.issue3380@psf.upfronthosting.co.za> New submission from John Williams : The documentation for the xml.etree.ElementTree package (http://www.python.org/doc/2.5/lib/module-xml.etree.ElementTree.html) does not include the Element type (http://effbot.org/zone/element.htm), making it impossible to use this package without referring to external documentation. ---------- assignee: georg.brandl components: Documentation messages: 69796 nosy: georg.brandl, jrw at pobox.com severity: normal status: open title: documentation for ElementTree is unusable type: feature request versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 19:37:37 2008 From: report at bugs.python.org (Trent Mick) Date: Wed, 16 Jul 2008 17:37:37 +0000 Subject: [New-bugs-announce] [issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997 In-Reply-To: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za> Message-ID: <1216229857.74.0.0779741633434.issue3381@psf.upfronthosting.co.za> New submission from Trent Mick : Configuring with "--enable-universalsdk" fails on Mac OS X 10.4/x86 because of a change in r63997. This in the python trunk (i.e. the 2.6 tree). The failure looks like this: ---------------------------- $ ./configure --enable-framework --enable-universalsdk ... checking for log1p... no checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t) See `config.log' for more details. ---------------------------- And the appropriate details in config.log are: ---------------------------- ... configure:21540: checking size of wchar_t configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk conftest.c >&5 /usr/bin/ld: -syslibroot: multiply specified collect2: ld returned 1 exit status /usr/bin/ld: -syslibroot: multiply specified collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or directory) configure:21878: $? = 1 configure: program exited with status 1 configure: failed program was: ... ---------------------------- The command being run: gcc -o conftest -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk conftest.c is "$ac_link". Here is a dump of relevant variables at that point in "configure": ------------------ LDFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk " CFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g -O2" CPPFLAGS is "" CC is "gcc" ac_link is "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5" ------------------ The problem is that r63997 (http://mail.python.org/pipermail/python-checkins/2008-June/070612.html) added this line to "configure.in" for Mac OS X: CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}" That results in the failure above: "ld" complaining about -isysroot/-syslibroot being specified twice on the command line. Ronald, What was the "build issue on OSX 10.4" that the was meant to be fixed. Can it be fixed without that "configure" change to "CFLAGS"? ---------- components: Build messages: 69805 nosy: ronaldoussoren, trentm severity: normal status: open title: `./configure --enable-framework --enable-universalsdk` fails because of change in r63997 versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 20:28:15 2008 From: report at bugs.python.org (Eric Smith) Date: Wed, 16 Jul 2008 18:28:15 +0000 Subject: [New-bugs-announce] [issue3382] Make '%F' and float.__format__('F') convert results to upper case. In-Reply-To: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za> Message-ID: <1216232895.09.0.0435300563375.issue3382@psf.upfronthosting.co.za> New submission from Eric Smith : See http://mail.python.org/pipermail/python-dev/2008-July/081242.html for the discussion. Basically, 'F' did the same as 'f' because it was assumed that neither would ever produce an exponent. But they do, for numbers greater than about 1e50. Also, 'F' should produce 'NAN' for cases where 'f' produces 'nan'. ---------- assignee: eric.smith components: Interpreter Core keywords: easy messages: 69811 nosy: eric.smith severity: normal status: open title: Make '%F' and float.__format__('F') convert results to upper case. type: feature request versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 20:31:53 2008 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 16 Jul 2008 18:31:53 +0000 Subject: [New-bugs-announce] [issue3383] ctypes.util fails to find libc in some environments In-Reply-To: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za> Message-ID: <1216233113.79.0.266532127913.issue3383@psf.upfronthosting.co.za> New submission from Jean-Paul Calderone : ctypes.util assumes several things of its environment which sometimes don't hold: * It depends on objdump being in $PATH. If it isn't, it will fail to read the SONAME from a library, even if it has determined the path to it. * If it uses ldconfig (which, unlike objdumb, it assumes it knows the full path to and doesn't rely on $PATH to find), it fails to interpret the results because the regular expression it applies doesn't define any groups. The attached patch is what I used to work around these issues in one particular environment. I don't claim the fixes to be general, and the patch includes no unit tests. ---------- assignee: theller components: ctypes files: ctypes-util.patch keywords: patch messages: 69814 nosy: exarkun, theller severity: normal status: open title: ctypes.util fails to find libc in some environments versions: Python 2.5 Added file: http://bugs.python.org/file10910/ctypes-util.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 20:31:55 2008 From: report at bugs.python.org (Joshua Kugler) Date: Wed, 16 Jul 2008 18:31:55 +0000 Subject: [New-bugs-announce] [issue3384] Documentation for re.findall and re.finditer lacks "ordering" information In-Reply-To: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za> Message-ID: <1216233115.47.0.391774668688.issue3384@psf.upfronthosting.co.za> New submission from Joshua Kugler : According to a discussion on comp.lang.python, re.findall and re.finditer scan strings from left to right, and returns them in the order it found them. It would be nice to note that in documentation. ---------- assignee: georg.brandl components: Documentation messages: 69815 nosy: georg.brandl, jkugler severity: normal status: open title: Documentation for re.findall and re.finditer lacks "ordering" information type: feature request versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 21:01:37 2008 From: report at bugs.python.org (Jesse Noller) Date: Wed, 16 Jul 2008 19:01:37 +0000 Subject: [New-bugs-announce] [issue3385] cPickle to pickle conversion in py3k missing methods In-Reply-To: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za> Message-ID: <1216234897.3.0.336444541402.issue3385@psf.upfronthosting.co.za> New submission from Jesse Noller : I was attempting the patch for issue3125 to py3k, and in it Amaury defines a new ForkingPickler: from pickle import Pickler class ForkingPickler(Pickler): dispatch = Pickler.dispatch.copy() This is also related to issue3350 I suspect. However, using the pickle.Pickler module under py3k, there is no dispatch() method on the class: Trunk: Python 2.6b1+ (trunk:65015M, Jul 16 2008, 10:15:51) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> dir(pickle.Pickler) ['_BATCHSIZE', '__doc__', '__init__', '__module__', '_batch_appends', '_batch_setitems', 'clear_memo', 'dispatch', 'dump', 'get', 'memoize', 'persistent_id', 'put', 'save', 'save_bool', 'save_dict', 'save_empty_tuple', 'save_float', 'save_global', 'save_inst', 'save_int', 'save_list', 'save_long', 'save_none', 'save_pers', 'save_reduce', 'save_string', 'save_tuple', 'save_unicode'] >>> py3k: Python 3.0b1+ (py3k:65011M, Jul 16 2008, 11:50:11) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> dir(Pickler) ['__class__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'bin', 'clear_memo', 'dump', 'fast', 'memo', 'persistent_id'] I think the fix for 3125 resolves your complaint in 3350, but is the lack of the dispatch method intentional? ---------- assignee: alexandre.vassalotti components: Extension Modules messages: 69816 nosy: alexandre.vassalotti, jnoller severity: normal status: open title: cPickle to pickle conversion in py3k missing methods versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 16 23:10:53 2008 From: report at bugs.python.org (Philip Jenvey) Date: Wed, 16 Jul 2008 21:10:53 +0000 Subject: [New-bugs-announce] [issue3386] distutils.sysconfig.get_python_lib prefix argument broken In-Reply-To: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za> Message-ID: <1216242653.79.0.3968685363.issue3386@psf.upfronthosting.co.za> New submission from Philip Jenvey : get_python_lib supports an optional prefix argument: If 'prefix' is supplied, use it instead of sys.prefix or sys.exec_prefix -- i.e., ignore 'plat_specific'. However the NT and OS2 platforms don't use the prefix argument when specified. This problem was brought up a while ago here: http://mail.python.org/pipermail/distutils-sig/2002-November/003099.html Andrew (the OS2 maintainer) claimed in the thread that fixing this would break OS2, but I don't see how. All callers of get_python_lib in the stdlib don't specify a prefix anyway. Anyone calling it with a prefix and expecting it not to be used is broken. ---------- components: Distutils files: get_python_lib-r65033.diff keywords: patch messages: 69836 nosy: pjenvey severity: normal status: open title: distutils.sysconfig.get_python_lib prefix argument broken type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10917/get_python_lib-r65033.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 00:59:42 2008 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 16 Jul 2008 22:59:42 +0000 Subject: [New-bugs-announce] [issue3387] undefined array passed to CryptGenRandomBytes In-Reply-To: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za> Message-ID: <1216249182.9.0.569778250674.issue3387@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : The CryptGenRandomBytes uses whatever data is already in the buffer as seed for the output. So, the buffer is effectively an in/out buffer. Now, since we are generating random data anyway, the fact that we are using an undefined seed for the data shouldn't matter. However, this does create a bunch of false positives for analysis tools such as Purify, that track the copying and usage of uninitialized data. An easy patch is to clear the buffer before submitting it to CryptGenRandomBytes, and is attached. ---------- components: Interpreter Core files: tmp6.patch keywords: easy, patch, patch messages: 69853 nosy: krisvale severity: normal status: open title: undefined array passed to CryptGenRandomBytes versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10919/tmp6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 01:10:45 2008 From: report at bugs.python.org (Florian Mayer) Date: Wed, 16 Jul 2008 23:10:45 +0000 Subject: [New-bugs-announce] [issue3388] With keyword not mentioned in Input Output tutorial In-Reply-To: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za> Message-ID: <1216249845.47.0.203384807378.issue3388@psf.upfronthosting.co.za> New submission from Florian Mayer : I think that the Python 3.0 Tutorial should show the reader that the with keyword is an excellent way of reading data from a file and closing it afterwards, even if exceptions occur. ---------- assignee: georg.brandl components: Documentation files: with_tutorial.patch keywords: patch messages: 69854 nosy: georg.brandl, segfaulthunter severity: normal status: open title: With keyword not mentioned in Input Output tutorial versions: Python 3.0 Added file: http://bugs.python.org/file10920/with_tutorial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 01:38:49 2008 From: report at bugs.python.org (Philip Jenvey) Date: Wed, 16 Jul 2008 23:38:49 +0000 Subject: [New-bugs-announce] [issue3389] [PATCH] Allow custom logging Handlers in logging config files In-Reply-To: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za> Message-ID: <1216251529.63.0.522616011962.issue3389@psf.upfronthosting.co.za> New submission from Philip Jenvey : Python 2.5 added support for specifying a custom logging Formatter class in logging configuration files. Handler classes can also be specified, but your choice is limited to classes that live in the logging module. A current workaround this is to manually add your custom Handler class to the logging module prior to loading the logging config file, but then you're no longer driving logging configuration purely from a config file (which is the entire point). This is particularly important for apps that are driven entirely from a config file that also includes logging information (such as Pylons applications) The following patch will cause Handler classes to be resolved just like Formatter classes if the check for the Handler class in the logging module fails. FYI this patch has been used in Paste (in particular for Pylons apps) for over a year so I consider it stable ---------- components: Library (Lib) files: logging-custom-Handler_r65033.diff keywords: patch messages: 69858 nosy: pjenvey, vsajip severity: normal status: open title: [PATCH] Allow custom logging Handlers in logging config files type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10921/logging-custom-Handler_r65033.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 09:41:41 2008 From: report at bugs.python.org (engelbert gruber) Date: Thu, 17 Jul 2008 07:41:41 +0000 Subject: [New-bugs-announce] [issue3390] [PATCH] replace last has_key in unittest by in operator In-Reply-To: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za> Message-ID: <1216280501.05.0.916682798552.issue3390@psf.upfronthosting.co.za> New submission from engelbert gruber : take the line from python-3 ---------- components: Library (Lib) files: lib_unittest-r65058 messages: 69877 nosy: grubert severity: normal status: open title: [PATCH] replace last has_key in unittest by in operator type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10925/lib_unittest-r65058 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 11:51:55 2008 From: report at bugs.python.org (Robert Schuppenies) Date: Thu, 17 Jul 2008 09:51:55 +0000 Subject: [New-bugs-announce] [issue3391] Idle uses old showwarning signature In-Reply-To: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za> Message-ID: <1216288315.21.0.418563087868.issue3391@psf.upfronthosting.co.za> New submission from Robert Schuppenies : Idle does not use the 'line' argument for its showwarning function. This results in the DeprecationWarning "functions overriding warnings.showwarning() must support the 'line' argument", or, when called from within Idle "TypeError: idle_formatwarning_subproc() takes exactly 4 arguments (5 given)". The error can be reproduced from within Idle as well as demonstrated with verify.py. The attached patch applies the behavior of the default warnings implementation. ---------- components: IDLE files: idle.patch keywords: patch messages: 69879 nosy: brett.cannon, schuppenies priority: normal severity: normal status: open title: Idle uses old showwarning signature type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10926/idle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 13:25:40 2008 From: report at bugs.python.org (=?utf-8?q?Mattias_Engdeg=C3=A5rd?=) Date: Thu, 17 Jul 2008 11:25:40 +0000 Subject: [New-bugs-announce] [issue3392] subprocess fails in select when descriptors are large In-Reply-To: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za> Message-ID: <1216293940.59.0.136491841956.issue3392@psf.upfronthosting.co.za> New submission from Mattias Engdeg?rd : If the stdin/out file descriptors are too large to be used with select(), subprocess will fail in .communicate(). Example: # raise the fd limit to something like 2048 before running this import subprocess somefiles = [open("/etc/passwd") for i in xrange(2000)] print subprocess.Popen(["date"], stdout=subprocess.PIPE).communicate() The solution would be to use select.poll() in subprocess instead. ---------- components: Library (Lib) messages: 69880 nosy: yorick severity: normal status: open title: subprocess fails in select when descriptors are large versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 19:02:48 2008 From: report at bugs.python.org (Trent Mick) Date: Thu, 17 Jul 2008 17:02:48 +0000 Subject: [New-bugs-announce] [issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955 In-Reply-To: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za> Message-ID: <1216314168.41.0.164548516306.issue3393@psf.upfronthosting.co.za> New submission from Trent Mick : http://svn.python.org/view?rev=63955&view=rev "MacOS X: Enable 4-way universal builds ..." This revision made the following change to Mac/Makefile.in: http://svn.python.org/view/python/trunk/Mac/Makefile.in?rev=63955&view=diff&r1=63955&r2=63954&p1=python/trunk/Mac/Makefile.in&p2=/python/trunk/Mac/Makefile.in The last hunk (part of the "installmacsubtree" target) and a bit of the preceding hunk uses `arch` with arguments: --------------------------------- install_BuildApplet: - $(RUNSHARED) $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \ + $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \ --destroot "$(DESTDIR)" \ - --python $(INSTALLED_PYTHONAPP) \ + --python=$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)`test -f "$(DESTDIR)$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)-32" && echo "-32"` \ --output "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app" \ $(srcdir)/scripts/BuildApplet.py @@ -225,7 +279,7 @@ done - $(RUNSHARED) $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST) + $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST) $(RUNSHARED) $(BUILDPYTHON) -Wi -tt $(compileall) -d $(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST) $(RUNSHARED) $(BUILDPYTHON) -O -Wi -tt $(compileall) -d $(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST) --------------------------------- That form of calling `arch` is only supported on Mac OS X 10.5 (Leopard), I believe. ---------------------------------- $ sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S2167 $ man arch | cat ARCH(1) BSD General Commands Manual ARCH(1) NAME arch -- print architecture type SYNOPSIS arch DESCRIPTION The arch command displays the machine's architecture type. SEE ALSO machine(1) Mac OS August 20, 1997 Mac OS ---------------------------------- Here is the current man page for arch (I had to look to try to see what Ronald was trying to do with the Makefile change) :) http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/arch.1.html I don't fully understand why the "arch -ppc -i386" is necessary for "$(BUILDPYTHON)". I'm not sure what the easiest solution to this would be... or if supporting "make frameworkinstallframework" (which eventually calls this target) on Mac OS X <10.5 is considered important enough. Perhaps a new RUNARCH=@RUNARCH@ could be added to Mac/Makefile.in with the associated configure support to have that be blank unless `--with-universal-archs=all` was specified? ---------- components: Build messages: 69890 nosy: ronaldoussoren, trentm severity: normal status: open title: `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955 type: compile error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 21:01:33 2008 From: report at bugs.python.org (Stephen Warren) Date: Thu, 17 Jul 2008 19:01:33 +0000 Subject: [New-bugs-announce] [issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix In-Reply-To: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za> Message-ID: <1216321293.73.0.655472661841.issue3394@psf.upfronthosting.co.za> New submission from Stephen Warren : Run the following Python script, on Unix/Linux: ========== import zipfile z = zipfile.ZipFile('zipbad.zip', 'w') z.writestr('filebad.txt', 'Some content') z.close() z = zipfile.ZipFile('zipgood.zip', 'w') zi = zipfile.ZipInfo('filegood.txt') zi.external_attr = 0660 << 16L z.writestr(zi, 'Some content') z.close() ========== Like this: python testzip.py && unzip zipbad.zip && unzip zipgood.zip && ls -l file*.txt You'll see: ---------- 1 swarren swarren 12 2008-07-17 12:54 filebad.txt -rw-rw---- 1 swarren swarren 12 1980-01-01 00:00 filegood.txt Note that filebad.txt is extracted with mode 000. The WAR (used for filegood.txt) is to pass writestr a ZipInfo class with external_attr pre-initialized. However, writestr should perform this assignment itself, to be consistent with write. I haven't checked, but there's probably a bunch of other stuff in write that writestr should do too. ---------- components: Extension Modules messages: 69898 nosy: swarren severity: normal status: open title: zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 22:29:07 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Jul 2008 20:29:07 +0000 Subject: [New-bugs-announce] [issue3395] typo in test_multiprocessing.py: should _debugInfo be _debug_info ? In-Reply-To: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za> Message-ID: <1216326547.53.0.561012238896.issue3395@psf.upfronthosting.co.za> New submission from Mark Dickinson : In _TestZZZNumberOfObjects in test_multiprocessing.py, at around line 1040 (this is r65075 on the trunk), there's a line: print self.manager._debugInfo() Should this be print self.manager._debug_info() ? While running test_multiprocessing directly (./python.exe Lib/test/test_multiprocessing) I got the following traceback: Macintosh-3:trunk dickinsm$ ./python.exe Lib/test/test_multiprocessing.py test_array (__main__.WithProcessesTestArray) ... ok test_getobj_getlock_obj (__main__.WithProcessesTestArray) ... ok ... [snip lots of passing tests] ... test_rawvalue (__main__.WithManagerTestValue) ... ok test_value (__main__.WithManagerTestValue) ... ok test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ... ERROR ====================================================================== ERROR: test_number_of_objects (__main__.WithManagerTestZZZNumberOfObjects) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_multiprocessing.py", line 1040, in test_number_of_objects print self.manager._debugInfo() AttributeError: 'SyncManager' object has no attribute '_debugInfo' ---------------------------------------------------------------------- Ran 121 tests in 10.446s FAILED (errors=1) [53431 refs] ---------- assignee: jnoller keywords: easy messages: 69904 nosy: jnoller, marketdickinson severity: normal status: open title: typo in test_multiprocessing.py: should _debugInfo be _debug_info ? versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 22:42:09 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 17 Jul 2008 20:42:09 +0000 Subject: [New-bugs-announce] [issue3396] rlcompleter can't autocomplete members of callable objects In-Reply-To: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za> Message-ID: <1216327329.3.0.446547765597.issue3396@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is a regression caused by #449227. When typing e.g. "int." and then pressing tab, none of the int members is proposed. It worked until just before r64664. ---------- components: Library (Lib) messages: 69905 nosy: facundobatista, pitrou priority: normal severity: normal status: open title: rlcompleter can't autocomplete members of callable objects type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 23:31:19 2008 From: report at bugs.python.org (Barry Alan Scott) Date: Thu, 17 Jul 2008 21:31:19 +0000 Subject: [New-bugs-announce] [issue3397] Mac 3.0 build cannot find cachersrc.py In-Reply-To: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za> Message-ID: <1216330279.07.0.869556013571.issue3397@psf.upfronthosting.co.za> New submission from Barry Alan Scott : $ sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S165 ./configure --enable-framework make ... make install Creating directory /Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools DYLD_FRAMEWORK_PATH=/Users/barry/Work/Python-3.0b1: ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac /Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools ../python.exe: can't open file './scripts/cachersrc.py': [Errno 2] No such file or directory make[1]: *** [installmacsubtree] Error 2 make: *** [frameworkinstallmaclib] Error 2 ---------- components: Build messages: 69909 nosy: barry-scott severity: normal status: open title: Mac 3.0 build cannot find cachersrc.py type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 17 23:52:22 2008 From: report at bugs.python.org (Barry Alan Scott) Date: Thu, 17 Jul 2008 21:52:22 +0000 Subject: [New-bugs-announce] [issue3398] mac build 3.0 no MacOS module In-Reply-To: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za> Message-ID: <1216331542.61.0.235815305559.issue3398@psf.upfronthosting.co.za> New submission from Barry Alan Scott : $ sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S165 ./configure --enable-framework make ... make install ... DYLD_FRAMEWORK_PATH=/Users/barry/Work/Python-3.0b1: ../python.exe ./scripts/BuildApplet.py \ --destroot "" \ --python /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python \ --output "/Applications/Python 3.0/Build Applet.app" \ ./scripts/BuildApplet.py Traceback (most recent call last): File "./scripts/BuildApplet.py", line 14, in import MacOS ImportError: No module named MacOS make[1]: *** [install_BuildApplet] Error 1 make: *** [frameworkinstallapps] Error 2 ---------- components: Build messages: 69910 nosy: barry-scott severity: normal status: open title: mac build 3.0 no MacOS module type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 00:22:25 2008 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 17 Jul 2008 22:22:25 +0000 Subject: [New-bugs-announce] [issue3399] Memory corruption in multiprocessing module, OS X 10.5.4 In-Reply-To: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za> Message-ID: <1216333345.76.0.451426062448.issue3399@psf.upfronthosting.co.za> New submission from Mark Dickinson : As of revision 65077 of the trunk, I'm getting errors in test_multiprocessing that seem to point to memory corruption in object allocation/deallocation. The failures are intermittent, and of a similar nature to the errors I was seeing previously, outlined in issue 3088. The platform is OS X 10.5.4 (not a fresh install---it was an upgrade from OS X 10.4, in case this makes any difference), running on a MacBook Pro. I'm running a freshly checked out debug build of the trunk. Here's what I did: (1) make a fresh svn+ssh checkout of the trunk (2) ./configure --with-pydebug && make (3) ./python.exe Lib/test/test_multiprocessing.py (4) repeat step (3) until something nasty happens. The results vary from run to run, and 80-90% of the runs of test_multiprocessing pass. Here are 3 of the failures I've seen, occurring on three separate runs of test_multiprocessing. Failure 1: test_notify_all (__main__.WithManagerTestCondition) ... Assertion failed: (pool->ref.count > 0), function PyObject_Free, file Objects/obmalloc.c, line 1100. Failure 2: test_imap_unordered (__main__.WithManagerTestPool) ... python.exe(32381,0xb0513000) malloc: *** error for object 0xdbdbdbdb: pointer being reallocated was not allocated *** set a breakpoint in malloc_error_break to debug python.exe(32381,0xb0513000) malloc: *** error for object 0xdbdbdbdb: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug Fatal Python error: UNREF invalid object ERROR Failure 3: test_imap_unordered (__main__.WithManagerTestPool) ... Fatal Python error: UNREF invalid object ERROR I have very little (i.e. no) experience of debugging this kind of failure, and little understanding of how the multiprocessing module works. But I can and will follow instructions and suggestions about how to debug this. Stupid question: it appears from reading the comments in that file that obmalloc.c is (intentionally) not thread-safe. Could this have anything to do with the failures above? ---------- assignee: jnoller components: Extension Modules messages: 69917 nosy: jnoller, marketdickinson severity: normal status: open title: Memory corruption in multiprocessing module, OS X 10.5.4 type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 00:24:17 2008 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Jul 2008 22:24:17 +0000 Subject: [New-bugs-announce] [issue3400] dis module: undocumented new bytecodes In-Reply-To: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za> Message-ID: <1216333457.94.0.303934316374.issue3400@psf.upfronthosting.co.za> New submission from Terry J. Reedy : dis / Python Bytecode Instructions is missing UNPACK_EX STORE_LOCALS LOAD_BUILD_CLASS MAKE_BYTES which appear in dis.opname (3.0 version). Suggestion: After entry for UNPACK_SEQUENCE(count), add UNPACK_EX(bytepair) Used for starred assignment. Similar to UNPACK_SEQUENCE except 1) the lo and hi bytes of the argument are the number of unstarred targets before and after the starred target and 2) the values between the first lo and last hi are collected into a list for the starred target. I deduced this because *a,b; a,*b; *a,b,c; a,*b,c; and a,b,*c as targets produce byte pairs of 0,1; 1,0; 0,2; 1,1; and 2,0 (arguments 256, 1, 512, 257, and 2). The other three are new since 2.5 but do not make much sense to me. I will ask on pydev for clarification. I do not have 2.6 to check its version of .opname to determine which of these belong there too. ---------- assignee: georg.brandl components: Documentation messages: 69918 nosy: georg.brandl, tjreedy severity: normal status: open title: dis module: undocumented new bytecodes versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 01:53:34 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 17 Jul 2008 23:53:34 +0000 Subject: [New-bugs-announce] [issue3401] wsgiref can't handle unicode environments In-Reply-To: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za> Message-ID: <1216338814.66.0.0698084133409.issue3401@psf.upfronthosting.co.za> New submission from Benjamin Peterson : The following errors pop up on the Windows trunk build bot because the LIB environmental variable is unicode not str. This causes the validation to fail. Re-running test 'test_wsgiref' in verbose mode testAbstractMethods (test.test_wsgiref.HandlerTests) ... ok testBasicErrorOutput (test.test_wsgiref.HandlerTests) ... ok testCGIEnviron (test.test_wsgiref.HandlerTests) ... ok testContentLength (test.test_wsgiref.HandlerTests) ... ok testEnviron (test.test_wsgiref.HandlerTests) ... ERROR testErrorAfterOutput (test.test_wsgiref.HandlerTests) ... ok testHeaderFormats (test.test_wsgiref.HandlerTests) ... ok testScheme (test.test_wsgiref.HandlerTests) ... ok testExtras (test.test_wsgiref.HeaderTests) ... ok testMappingInterface (test.test_wsgiref.HeaderTests) ... ok testRequireList (test.test_wsgiref.HeaderTests) ... ok test_plain_hello (test.test_wsgiref.IntegrationTests) ... ok test_simple_validation_error (test.test_wsgiref.IntegrationTests) ... FAIL test_validated_hello (test.test_wsgiref.IntegrationTests) ... FAIL testAppURIs (test.test_wsgiref.UtilityTests) ... ok testCrossDefaults (test.test_wsgiref.UtilityTests) ... ok testDefaults (test.test_wsgiref.UtilityTests) ... ok testFileWrapper (test.test_wsgiref.UtilityTests) ... ok testGuessScheme (test.test_wsgiref.UtilityTests) ... ok testHopByHop (test.test_wsgiref.UtilityTests) ... ok testNormalizedShifts (test.test_wsgiref.UtilityTests) ... ok testReqURIs (test.test_wsgiref.UtilityTests) ... ok testSimpleShifts (test.test_wsgiref.UtilityTests) ... ok ====================================================================== ERROR: testEnviron (test.test_wsgiref.HandlerTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py", line 437, in testEnviron self.checkOSEnviron(h) File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py", line 429, in checkOSEnviron self.assertEqual(env[k],v) KeyError: 'AUTH_TYPE' ====================================================================== FAIL: test_simple_validation_error (test.test_wsgiref.IntegrationTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py", line 157, in test_simple_validation_error "AssertionError: Headers (('Content-Type', 'text/plain')) must" AssertionError: "AssertionError: Environmental variable LIB is not a string: (value: u'C:\\\\Program Files\\\\Microsoft Visual Studio 9.0\\\\VC\\\\LIB;C:\\\\Program Files\\\\Microsoft SDKs\\\\Windows\\\\v6.0A\\\\lib;c:\\\\program files\\\\microsoft visual studio .NET 2003\\\\vc7\\\\atlmfc\\\\lib;c:\\\\program files\\\\microsoft visual studio .NET 2003\\\\vc7\\\\lib;c:\\\\program files\\\\microsoft visual studio .NET 2003\\\\vc7\\\\PlatformSDK\\\\lib;C:\\\\Program Files\\\\Microsoft Visual Studio .NET 2003\\\\SDK\\\\v1.1\\\\Lib\\\\')" != "AssertionError: Headers (('Content-Type', 'text/plain')) must be of type list: " ====================================================================== FAIL: test_validated_hello (test.test_wsgiref.IntegrationTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py", line 145, in test_validated_hello self.check_hello(out, has_length=False) File "E:\cygwin\home\db3l\buildarea\trunk.bolen-windows\build\lib\test\test_wsgiref.py", line 134, in check_hello "\r\n" AssertionError: 'HTTP/1.0 500 Dude, this is whack!\r\nDate: Thu, 17 Jul 2008 22:45:20 GMT\r\nServer: WSGIServer/0.1 Python/2.6b1+\r\nContent-Type: text/plain\r\nContent-Length: 59\r\n\r\nA server error occurred. Please contact the administrator.' != 'HTTP/1.0 200 OK\r\nServer: WSGIServer/0.1 Python/2.6b1+\r\nContent-Type: text/plain\r\nDate: Mon, 05 Jun 2006 18:49:54 GMT\r\n\r\nHello, world!' ---------- messages: 69929 nosy: benjamin.peterson severity: normal status: open title: wsgiref can't handle unicode environments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 03:56:33 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 18 Jul 2008 01:56:33 +0000 Subject: [New-bugs-announce] [issue3402] test_nis is hanging on Solaris In-Reply-To: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za> Message-ID: <1216346193.57.0.216784355152.issue3402@psf.upfronthosting.co.za> New submission from Benjamin Peterson : The 3.0 Solaris buildbot keeps hanging on test_nis. ---------- components: Tests messages: 69931 nosy: benjamin.peterson priority: deferred blocker severity: normal status: open title: test_nis is hanging on Solaris type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 10:41:36 2008 From: report at bugs.python.org (SukkoPera) Date: Fri, 18 Jul 2008 08:41:36 +0000 Subject: [New-bugs-announce] [issue3403] Unexpected default arguments behaviour In-Reply-To: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za> Message-ID: <1216370496.76.0.890911123017.issue3403@psf.upfronthosting.co.za> New submission from SukkoPera : I have just encountered a Python behaviour I wouldn't expect. Take the following code: ------------------------------------------------------------------------ class Parent: a = 1 def m (self, param = a): print "param = %d" % param class Child (Parent): a = 2 p = Parent () p.m () c = Child () c.m () ------------------------------------------------------------------------ I would expect to receive the following output: param = 1 param = 2 But actually I get: param = 1 param = 1 Is this the correct behaviour, and then why, or is it a bug? For reference, I am using Python 2.5.1 on GNU/Linux. There has been a short discussion about this at http://groups.google.it/group/comp.lang.python/browse_thread/thread/9f740eea131e7ef2/56fd4e120a069a1d#56fd4e120a069a1d. ---------- components: None messages: 69943 nosy: SukkoPera severity: normal status: open title: Unexpected default arguments behaviour type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 12:40:27 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 18 Jul 2008 10:40:27 +0000 Subject: [New-bugs-announce] [issue3404] wrong precision in float formatting In-Reply-To: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za> Message-ID: <1216377626.86.0.147099766494.issue3404@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : This seems to be wrong: >>> "{0:.2}".format(1.2345) '1.2' The same happens for format specifiers "g" and "n", but not for "f": >>> "{0:.2f}".format(1.2345) '1.23' With empty format specifier it can even get really wrong: >>> "{0:.1}".format(1.2345) '1.0' ---------- components: Interpreter Core messages: 69947 nosy: hagen severity: normal status: open title: wrong precision in float formatting type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 14:52:46 2008 From: report at bugs.python.org (Guilherme Polo) Date: Fri, 18 Jul 2008 12:52:46 +0000 Subject: [New-bugs-announce] [issue3405] Add support for the new data option supported by event generate (Tk 8.5) In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za> Message-ID: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za> New submission from Guilherme Polo : Follows a patch that adds support for the new data option supported event generate. It allows virtual events to pass a tcl object. This patch is only intended to correctly support tcl objects, trying to pass other objects (like a dict) will result in None being returned. If you want to correctly pass and receive a dict, make it an attribute of the tcl object being passed. E.g.: import Tkinter def handle_it(event): print event.data.something root = Tkinter.Tk() root.something = {1: 2} root.after(1, lambda: root.event_generate('<>', data=root)) root.bind('<>', handle_it) root.mainloop() ---------- components: Tkinter files: event_generate__data.diff keywords: patch messages: 69951 nosy: gpolo severity: normal status: open title: Add support for the new data option supported by event generate (Tk 8.5) versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10934/event_generate__data.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 15:02:51 2008 From: report at bugs.python.org (WoLpH) Date: Fri, 18 Jul 2008 13:02:51 +0000 Subject: [New-bugs-announce] [issue3406] LocaleTextCalendar and LocaleHTMLCalendar break without a locale In-Reply-To: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za> Message-ID: <1216386171.9.0.435364597231.issue3406@psf.upfronthosting.co.za> New submission from WoLpH : Steps to reproduce: >>> import calendar >>> calendar.LocaleHTMLCalendar() Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/calendar.py", line 540, in __init__ locale = locale.getdefaultlocale() AttributeError: 'NoneType' object has no attribute 'getdefaultlocale' The same goes for LocaleTextCalendar, the problem is caused by this code which obviously would never work: if locale is None: locale = locale.getdefaultlocale() The fix should be quite easy, rename the local variable and it will work again :) ---------- components: Extension Modules messages: 69952 nosy: WoLpH severity: normal status: open title: LocaleTextCalendar and LocaleHTMLCalendar break without a locale type: crash versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 20:47:54 2008 From: report at bugs.python.org (Jean Brouwers) Date: Fri, 18 Jul 2008 18:47:54 +0000 Subject: [New-bugs-announce] [issue3407] test_urllib2_localnet fails on MacOS X 10.4.11 (Intel) In-Reply-To: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za> Message-ID: <1216406874.33.0.238022254592.issue3407@psf.upfronthosting.co.za> New submission from Jean Brouwers : The test_urllib2_localnet fails on MacOS X 10.4.11 (Intel) with Python 2.6b2 (and 3.0b2), see below. The same test also failed for Python 2.6b1 but was not reported as a test failure. % ./python.exe Python 2.6b2 (r26b2:65082, Jul 18 2008, 09:00:40) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> % ./python.exe Lib/test/test_urllib2_localnet.py test_proxy_qop_auth_int_works_or_throws_urlerror (__main__.ProxyAuthTests) ... ok test_proxy_qop_auth_works (__main__.ProxyAuthTests) ... ok test_proxy_with_bad_password_raises_httperror (__main__.ProxyAuthTests) ... ok test_proxy_with_no_password_raises_httperror (__main__.ProxyAuthTests) ... ok ---------------------------------------------------------------------- Ran 4 tests in 4.233s OK test_200 (__main__.TestUrlopen) ... ok test_200_with_parameters (__main__.TestUrlopen) ... ok test_404 (__main__.TestUrlopen) ... ok test_bad_address (__main__.TestUrlopen) ... FAIL test_basic (__main__.TestUrlopen) ... ok test_geturl (__main__.TestUrlopen) ... ok test_info (__main__.TestUrlopen) ... ok test_redirection (__main__.TestUrlopen) ... ok test_sending_headers (__main__.TestUrlopen) ... ok ====================================================================== FAIL: test_bad_address (__main__.TestUrlopen) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_urllib2_localnet.py", line 477, in test_bad_address urllib2.urlopen, "http://www.python.invalid./") AssertionError: IOError not raised ---------------------------------------------------------------------- Ran 9 tests in 9.486s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_urllib2_localnet.py", line 491, in test_main() File "Lib/test/test_urllib2_localnet.py", line 488, in test_main test_support.run_unittest(TestUrlopen) File ".../Python-2.6b2/Lib/test/test_support.py", line 731, in run_unittest _run_suite(suite) File ".../Python-2.6b2/Lib/test/test_support.py", line 714, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_urllib2_localnet.py", line 477, in test_bad_address urllib2.urlopen, "http://www.python.invalid./") AssertionError: IOError not raised ---------- components: Tests messages: 69971 nosy: MrJean1 severity: normal status: open title: test_urllib2_localnet fails on MacOS X 10.4.11 (Intel) type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 20:53:38 2008 From: report at bugs.python.org (vizcayno) Date: Fri, 18 Jul 2008 18:53:38 +0000 Subject: [New-bugs-announce] [issue3408] urllib incomplete and urllib2 does not exist In-Reply-To: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za> Message-ID: <1216407218.4.0.726593337894.issue3408@psf.upfronthosting.co.za> New submission from vizcayno : I am under Win XP sp 3: After importing urllib it only shows a few objects when using dir() urllib2 module does not exist. .python Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> dir(urllib) ['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__pa th__'] >>> import urllib2 Traceback (most recent call last): File "", line 1, in ImportError: No module named urllib2 >>> ---------- components: Windows messages: 69974 nosy: vizcayno severity: normal status: open title: urllib incomplete and urllib2 does not exist versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 21:45:25 2008 From: report at bugs.python.org (Uwe Hoffmann) Date: Fri, 18 Jul 2008 19:45:25 +0000 Subject: [New-bugs-announce] [issue3409] ElementPath.Path.findall problem with unicode input In-Reply-To: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za> Message-ID: <1216410325.02.0.112420594064.issue3409@psf.upfronthosting.co.za> New submission from Uwe Hoffmann : if you call Element.findall(u".......") some silent errors can occure because of the isinstance(....,type("")) check. I'm not sure if it is even allowed to call findall with a unicode parameter. The attached diff solves *my* problem. ---------- components: Library (Lib), Unicode files: ElementPath.diff keywords: patch messages: 69986 nosy: qual severity: normal status: open title: ElementPath.Path.findall problem with unicode input type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file10940/ElementPath.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 21:49:55 2008 From: report at bugs.python.org (Felipe Portella) Date: Fri, 18 Jul 2008 19:49:55 +0000 Subject: [New-bugs-announce] [issue3410] platform.version() don't work as expected in Vista in portuguese In-Reply-To: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za> Message-ID: <1216410595.08.0.936182141358.issue3410@psf.upfronthosting.co.za> New submission from Felipe Portella : Using Vista in Portuguese platform.version is returning "32bits" instead of "6.0.6001". This is because in file platform.py line 379 thee regular expression try to search for the word "Version" in english, while in Portuguese the command ver will return "Vers?o". To solve this issue simple change: 'Version ([\d.]+))') for '\S+ ([\d.]+))') ---------- components: Library (Lib) messages: 69987 nosy: portella severity: normal status: open title: platform.version() don't work as expected in Vista in portuguese type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 22:09:21 2008 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Fri, 18 Jul 2008 20:09:21 +0000 Subject: [New-bugs-announce] [issue3411] str.format() on negative floats In-Reply-To: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za> Message-ID: <1216411761.22.0.510174949199.issue3411@psf.upfronthosting.co.za> New submission from Hagen F?rstenau : This happens with an empty type field in the format specification: >>> "{0:1}".format(-1.23) '.0-1.23' With type "g" it's ok: >>> "{0:1g}".format(-1.23) '-1.23' ---------- components: Library (Lib) messages: 69988 nosy: hagen severity: normal status: open title: str.format() on negative floats versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 18 23:36:09 2008 From: report at bugs.python.org (Florian Mayer) Date: Fri, 18 Jul 2008 21:36:09 +0000 Subject: [New-bugs-announce] [issue3412] Fraction and Decimal in the Tutorial In-Reply-To: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za> Message-ID: <1216416969.62.0.493735551433.issue3412@psf.upfronthosting.co.za> New submission from Florian Mayer : I think that when floating point number limitations are mentioned we should also tell that there are alternatives for processing numbers with decimal extensions. I wrote a text that introduces the Decimal and the Fraction type to the reader. ---------- assignee: georg.brandl components: Documentation files: floating messages: 69992 nosy: georg.brandl, segfaulthunter severity: normal status: open title: Fraction and Decimal in the Tutorial versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10941/floating _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 04:48:34 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Sat, 19 Jul 2008 02:48:34 +0000 Subject: [New-bugs-announce] [issue3413] typo in Mac/Makefile.in breaks installing IDLE In-Reply-To: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za> Message-ID: <1216435714.49.0.10489106373.issue3413@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : There's a slight typo in Mac/Makefile.in, where DESDIR was used instead of DESTDIR. This patch fixes it: --- /tmp/Makefile.in 2008-07-18 19:42:29.000000000 -0700 +++ Mac/Makefile.in 2008-07-18 19:42:33.000000000 -0700 @@ -216,7 +216,7 @@ test -d "$(DESTDIR)$(PYTHONAPPSDIR)" || mkdir -p "$(DESTDIR)$(PYTHONAPPSDIR)" -test -d "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app" && rm -r "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app" cp -PR IDLE/IDLE.app "$(DESTDIR)$(PYTHONAPPSDIR)" - ln -sf $(INSTALLED_PYTHONAPP) "$(DESDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python" + ln -sf $(INSTALLED_PYTHONAPP) "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app/Contents/MacOS/Python" touch "$(DESTDIR)$(PYTHONAPPSDIR)/IDLE.app" $(INSTALLED_PYTHONAPP): install_Python ---------- components: Build messages: 70001 nosy: erickt severity: normal status: open title: typo in Mac/Makefile.in breaks installing IDLE versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 06:07:32 2008 From: report at bugs.python.org (Erick Tryzelaar) Date: Sat, 19 Jul 2008 04:07:32 +0000 Subject: [New-bugs-announce] [issue3414] frameworkinstall doesn't create Python.app, which breaks python In-Reply-To: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za> Message-ID: <1216440452.24.0.507220813764.issue3414@psf.upfronthosting.co.za> New submission from Erick Tryzelaar : Hello again! It looks like doing "make frameworkinstall maninstall" isn't creating "Python.framework/Versions/3.0/Resources/Python.app", so when I try to run python it errors out with: "python3.0: execv: /opt/local/Library/Frameworks/Python.framework/Versions/3.0/Resources/Py thon.app/Contents/MacOS/Python: No such file or directory". In order to get that file created, I need to manually run "cd Mac && make install_Python". This patch fixes it, but I'm not sure if this is the proper fix: --- Mac/Makefile.in.old 2008-07-18 20:59:44.000000000 -0700 +++ Mac/Makefile.in 2008-07-18 20:57:44.000000000 -0700 @@ -46,7 +46,7 @@ compileall=$(srcdir)/../Lib/compileall.py installapps: install_PythonLauncher install_IDLE checkapplepython install_pythonw \ - install_versionedtools + install_versionedtools install_Python installapps4way: install_Python4way install_BuildApplet install_PythonLauncher install_IDLE install_pythonw4way install_versionedtools ---------- components: Build messages: 70004 nosy: erickt severity: normal status: open title: frameworkinstall doesn't create Python.app, which breaks python type: behavior versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 07:32:35 2008 From: report at bugs.python.org (Nir) Date: Sat, 19 Jul 2008 05:32:35 +0000 Subject: [New-bugs-announce] [issue3415] Interpreter error when running a script under debugger control In-Reply-To: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za> Message-ID: <1216445555.64.0.192664487066.issue3415@psf.upfronthosting.co.za> New submission from Nir : Interpreter error results in erroneous exception when running a script under debugger control. Full repro description: On Windows System, try to run idle.py under the inspection of pdb.py. Note that you must set a breakpoint somewhere otherwise pdb will not trace the script and the issue will not surface. You should get the bad exception in line 295 of multicall.py Python complains that a local variable has been used before being declared while in effect it has been a couple of lines before that point. Nir ---------- components: Interpreter Core messages: 70005 nosy: nirai severity: normal status: open title: Interpreter error when running a script under debugger control type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 13:57:13 2008 From: report at bugs.python.org (Yu Xin) Date: Sat, 19 Jul 2008 11:57:13 +0000 Subject: [New-bugs-announce] [issue3416] Wrong inherit in PickleHTMLBuilder In-Reply-To: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za> Message-ID: <1216468633.06.0.823893160306.issue3416@psf.upfronthosting.co.za> New submission from Yu Xin : I use sphinx-0.4.1. When I make pickle, I saw the error message: Traceback (most recent call last): File "/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/__init__.py", line 135, in main app.builder.build_update() File "/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py", line 202, in build_update 'out of date' % len(to_build)) File "/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py", line 241, in build self.write(docnames, updated_docnames, method) File "/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py", line 277, in write self.write_doc(docname, doctree) File "/is/app/grows/lib/python2.5/site-packages/Sphinx-0.4.1-py2.5.egg/sphinx/builder.py", line 459, in write_doc self.handle_page(docname, ctx, event_arg=doctree) TypeError: handle_page() got an unexpected keyword argument 'event_arg'. I inspect the class in sphinx/builder.py. handle_page in StandaloneHTMLBuilder is defined as "def ndle_page(self, pagename, addctx, templatename='page.html', outfilename=None, event_arg=None): but handle_page in PickleHTMLBuilder is defined as "def handle_page(self, pagename, ctx, templatename='page.html', outfilename=None):" the last param event_arg is missing. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70015 nosy: georg.brandl, is severity: normal status: open title: Wrong inherit in PickleHTMLBuilder type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 15:51:59 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 19 Jul 2008 13:51:59 +0000 Subject: [New-bugs-announce] [issue3417] make the fix_dict fixer explicit In-Reply-To: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za> Message-ID: <1216475519.86.0.701774626864.issue3417@psf.upfronthosting.co.za> New submission from Benjamin Peterson : Can we make the part of fix_dict that converts d.items/values/keys to list(d.items) explicit? Most of the time, it's fine if the method returns a view and can be a bit of a performance hit to convert it to a list. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 70031 nosy: benjamin.peterson, collinwinter severity: normal status: open title: make the fix_dict fixer explicit type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 16:02:50 2008 From: report at bugs.python.org (mgogoulos) Date: Sat, 19 Jul 2008 14:02:50 +0000 Subject: [New-bugs-announce] [issue3418] heavy resource usage with string functions In-Reply-To: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za> Message-ID: <1216476170.57.0.358582553384.issue3418@psf.upfronthosting.co.za> New submission from mgogoulos : Not sure if this is a bug, however the following string functions when called with very big numbers as the padding arguments consume great system resources. My estimation is that it would help to exist a limit on what can be specified as width. Check (center, ljust, rjust, zfill) eg. import string string.center('..', 2147483647) Tested on python versions: 2.5.1 and 2.5.2 ---------- components: Library (Lib) messages: 70034 nosy: mgogoulos severity: normal status: open title: heavy resource usage with string functions type: resource usage versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 19 22:00:42 2008 From: report at bugs.python.org (Ismail Donmez) Date: Sat, 19 Jul 2008 20:00:42 +0000 Subject: [New-bugs-announce] [issue3419] multiprocessing module is racy In-Reply-To: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za> Message-ID: <1216497642.64.0.851465570204.issue3419@psf.upfronthosting.co.za> New submission from Ismail Donmez : Tested on MacOSX 10.5.4, running test_multiprocessing in a tight loop : [~/Sources/py3k]> while true;do ./python ./Lib/test/regrtest.py test_multiprocessing;done test_multiprocessing 1 test OK. test_multiprocessing 1 test OK. test_multiprocessing 1 test OK. test_multiprocessing Process Process-48: Traceback (most recent call last): File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 720, in _callmethod conn = self._tls.connection AttributeError: 'ForkAwareLocal' object has no attribute 'connection' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", line 232, in _bootstrap self.run() File "/Users/cartman/Sources/py3k/Lib/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py", line 601, in f cond.acquire() File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 949, in acquire return self._callmethod('acquire', (blocking,)) File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 724, in _callmethod self._connect() File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 711, in _connect conn = self._Client(self._token.address, authkey=self._authkey) File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", line 133, in Client c = SocketClient(address) File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", line 254, in SocketClient s.connect(address) socket.error: [Errno 61] Connection refused Exception in thread Thread-58: Traceback (most recent call last): File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 720, in _callmethod conn = self._tls.connection AttributeError: 'ForkAwareLocal' object has no attribute 'connection' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/cartman/Sources/py3k/Lib/threading.py", line 492, in _bootstrap_inner self.run() File "/Users/cartman/Sources/py3k/Lib/threading.py", line 447, in run self._target(*self._args, **self._kwargs) File "/Users/cartman/Sources/py3k/Lib/test/test_multiprocessing.py", line 601, in f cond.acquire() File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 949, in acquire return self._callmethod('acquire', (blocking,)) File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 724, in _callmethod self._connect() File "/Users/cartman/Sources/py3k/Lib/multiprocessing/managers.py", line 711, in _connect conn = self._Client(self._token.address, authkey=self._authkey) File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", line 133, in Client c = SocketClient(address) File "/Users/cartman/Sources/py3k/Lib/multiprocessing/connection.py", line 254, in SocketClient s.connect(address) socket.error: [Errno 61] Connection refused ---------- components: Tests messages: 70053 nosy: cartman severity: normal status: open title: multiprocessing module is racy versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 20 10:07:07 2008 From: report at bugs.python.org (Barry Alan Scott) Date: Sun, 20 Jul 2008 08:07:07 +0000 Subject: [New-bugs-announce] [issue3420] 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2 In-Reply-To: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za> Message-ID: <1216541227.58.0.862613379472.issue3420@psf.upfronthosting.co.za> New submission from Barry Alan Scott : $ sw_vers ProductName: Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S165 $ python3.0 Python 3.0b2 (r30b2:65080, Jul 20 2008, 08:46:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> $ /Library/Frameworks/Python.framework//Versions/3.0/bin/2to3 a.py Traceback (most recent call last): File "/Library/Frameworks/Python.framework//Versions/3.0/bin/2to3", line 5, in sys.exit(refactor.main("lib2to3/fixes")) File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py", line 81, in main rt = RefactoringTool(fixer_dir, options) File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py", line 160, in __init__ self.pre_order, self.post_order = self.get_fixers() File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py", line 182, in get_fixers fix_names = get_all_fix_names(self.fixer_dir) File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib2to3/refactor.py", line 95, in get_all_fix_names names = os.listdir(fixer_dir) OSError: [Errno 2] No such file or directory: 'lib2to3/fixes' ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 70065 nosy: barry-scott, collinwinter severity: normal status: open title: 2to3 fails to run on Mac OS X 10.4 PPC 3.0b2 type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 21 00:36:53 2008 From: report at bugs.python.org (Georg Brandl) Date: Sun, 20 Jul 2008 22:36:53 +0000 Subject: [New-bugs-announce] [issue3421] Test failure in test_math::testSum In-Reply-To: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za> Message-ID: <1216593413.69.0.163323698649.issue3421@psf.upfronthosting.co.za> New submission from Georg Brandl : In Py3k, but not in trunk: ====================================================================== FAIL: testSum (test.test_math.MathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 769, in testSum self.assertEqual(math.sum(vals), s) OverflowError: math range error During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 772, in testSum "for math.sum(%.100r)" % (i, s, vals)) AssertionError: test 13 failed: got OverflowError, expected 1.7976931348623157e+308 for math.sum([1.7976931348623157e+308, 9.979201547673598e+291]) System info: linux x86, glibc 2.8 ---------- assignee: marketdickinson components: Extension Modules, Tests messages: 70094 nosy: georg.brandl, marketdickinson severity: normal status: open title: Test failure in test_math::testSum versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 21 01:08:35 2008 From: report at bugs.python.org (Pauli Virtanen) Date: Sun, 20 Jul 2008 23:08:35 +0000 Subject: [New-bugs-announce] [issue3422] sphinx.doc.autodoc: Hook for changing argspec In-Reply-To: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za> Message-ID: <1216595315.74.0.23412143047.issue3422@psf.upfronthosting.co.za> New submission from Pauli Virtanen : It would be useful if the autodoc-process-docstring event from sphinx.ext.autodoc allowed to change the argspec of the function being documented. Some other hook for changing the function signature would also do. We are using Sphinx for generating a reference guide for Numpy, where many of the functions are from extension modules for which inspect.getargspec does not work. Instead, the function signature is contained within the object's docstring. Right now I'm simply monkeypatching sphinx.ext.autodoc.format_signature, but a cleaner approach would be better. It seems that this would be fairly easy to implement in generate_rst. Perhaps a .signature attribute to the Options passed to the hook would be an acceptable solution? I can write a patch doing this, if someone doesn't do this faster. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70096 nosy: georg.brandl, pv severity: normal status: open title: sphinx.doc.autodoc: Hook for changing argspec type: feature request versions: 3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 02:40:42 2008 From: report at bugs.python.org (Greg Hazel) Date: Tue, 22 Jul 2008 00:40:42 +0000 Subject: [New-bugs-announce] [issue3423] DeprecationWarning message applies to wrong context with exec() In-Reply-To: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za> Message-ID: <1216687242.26.0.837867299264.issue3423@psf.upfronthosting.co.za> New submission from Greg Hazel : exec()ing a line which causes a DeprecationWarning causes the warning to quote the file exec() occurs in instead of the string. Demonstration of the issue: http://codepad.org/aMTYQgN5 ---------- components: None messages: 70129 nosy: ghazel severity: normal status: open title: DeprecationWarning message applies to wrong context with exec() versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 11:30:39 2008 From: report at bugs.python.org (=?utf-8?q?Ilpo_Nyyss=C3=B6nen?=) Date: Tue, 22 Jul 2008 09:30:39 +0000 Subject: [New-bugs-announce] [issue3424] imghdr test order makes it slow In-Reply-To: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za> Message-ID: <1216719039.65.0.915247754712.issue3424@psf.upfronthosting.co.za> New submission from Ilpo Nyyss?nen : The order of tests in imghdr makes it slow in common cases. Even without any statistics it is quite easy to see that jpeg is the most common format. In imghdr only bmp and png are after it. Also, should png really be the last one? Nearly all digital cameras produce jpegs and handling such images is one big use case for this module. Changing the test order should be easy and have big effect in common use cases. ---------- components: Library (Lib) messages: 70142 nosy: biny severity: normal status: open title: imghdr test order makes it slow type: performance versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 15:56:33 2008 From: report at bugs.python.org (Oskar Andersson) Date: Tue, 22 Jul 2008 13:56:33 +0000 Subject: [New-bugs-announce] [issue3425] posixmodule.c always using res = utime(path, NULL) In-Reply-To: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za> Message-ID: <1216734993.32.0.611530331004.issue3425@psf.upfronthosting.co.za> New submission from Oskar Andersson : I'm porting, embedding and extending Python in a very limited environment. This environment does not have utime.h and have not defined the following function: int utime(const char *, const struct utimbuf *); Although the function called utimes, defined in sys/time.h exist. int utimes(const char *path, const struct timeval times[2]); In the method, in posixmodule.c: static PyObject * posix_utime(PyObject *self, PyObject *args); usage of these methods are used. If a time is specified in args, a define determines which of the two methods to use, utime or utimes depending if these exist or not. If Py_None is sent instead utime is always used, the solution to solve this is to use #ifdef with HAVE_UTIMES. Line number 2835 in http://svn.python.org/projects/python/trunk/Modules/posixmodule.c I have not checked if this is solved in future versions. ---------- components: Extension Modules messages: 70147 nosy: oskar86 severity: normal status: open title: posixmodule.c always using res = utime(path, NULL) type: compile error versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 16:32:13 2008 From: report at bugs.python.org (=?utf-8?q?Christian_H=C3=A4ggstr=C3=B6m?=) Date: Tue, 22 Jul 2008 14:32:13 +0000 Subject: [New-bugs-announce] [issue3426] os.path.abspath with unicode argument should call os.getcwdu In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za> Message-ID: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za> New submission from Christian H?ggstr?m : If current working directory contains non-ascii characters, calling os.path.abspath(u".") will result in an error. I expect it to call the underlying os.getcwdu() in this case. >>> import os >>> os.path.abspath(u".") Traceback (most recent call last): File "", line 1, in File "/home/packages/python-2.5.1/x86-linux/lib/python2.5/posixpath.py", line 403, in abspath path = join(os.getcwd(), path) File "/home/packages/python-2.5.1/x86-linux/lib/python2.5/posixpath.py", line 65, in join path += '/' + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 29: ordinal not in range(128) It works if I do it manually, using os.getcwdu(): >>> os.path.join(os.getcwdu(), u".") u'/disk1/chn_local/work/test/sk\xe4rg\xe5rds\xf6-latin1/.' ---------- components: Unicode messages: 70148 nosy: saturn_mimas severity: normal status: open title: os.path.abspath with unicode argument should call os.getcwdu type: behavior versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 19:05:35 2008 From: report at bugs.python.org (ThomasH) Date: Tue, 22 Jul 2008 17:05:35 +0000 Subject: [New-bugs-announce] [issue3427] urllib documentation: urlopen().info() return type In-Reply-To: <1216746335.31.0.451776222673.issue3427@psf.upfronthosting.co.za> Message-ID: <1216746335.31.0.451776222673.issue3427@psf.upfronthosting.co.za> New submission from ThomasH : http://docs.python.org/lib/module-urllib.html The page says that the return type of urlopen().info() is a mimetools.Message object, which is not quite true; it is a httplib.HTTPMessage object, which is a class derived from mimetools.Message, but with additional features. The httplib.HTTPMessage class is not documented at all, for which I will file a separate bug. ---------- assignee: georg.brandl components: Documentation messages: 70154 nosy: ThomasH, georg.brandl severity: normal status: open title: urllib documentation: urlopen().info() return type type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 19:09:01 2008 From: report at bugs.python.org (ThomasH) Date: Tue, 22 Jul 2008 17:09:01 +0000 Subject: [New-bugs-announce] [issue3428] httplib.HTTPMessage undocumented In-Reply-To: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za> Message-ID: <1216746541.05.0.162492292768.issue3428@psf.upfronthosting.co.za> New submission from ThomasH : The httplib.HTTPMessage class needs documentation; it is missing from the package documentation entirely. Instances of this class are e.g. returned by the urllib.urlopen().info() method. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70155 nosy: ThomasH, georg.brandl severity: normal status: open title: httplib.HTTPMessage undocumented versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 19:17:09 2008 From: report at bugs.python.org (ThomasH) Date: Tue, 22 Jul 2008 17:17:09 +0000 Subject: [New-bugs-announce] [issue3429] urllib.urlopen() return type In-Reply-To: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za> Message-ID: <1216747029.56.0.0682740128013.issue3429@psf.upfronthosting.co.za> New submission from ThomasH : The file-like object returned by urllib.urlopen() should be documented like a proper class. The textual description under the urlopen() method is less approachable and breaks the usual format of a class documentation. Maybe the return type should be changed to be a httplib.HTTPResponse object (but that's a separate issue). ---------- assignee: georg.brandl components: Documentation messages: 70156 nosy: ThomasH, georg.brandl severity: normal status: open title: urllib.urlopen() return type type: feature request versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 22 19:31:20 2008 From: report at bugs.python.org (ThomasH) Date: Tue, 22 Jul 2008 17:31:20 +0000 Subject: [New-bugs-announce] [issue3430] httplib.HTTPResponse documentations inconsistent In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za> Message-ID: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za> New submission from ThomasH : The library reference documentation of httplib.HTTPResponse does not match up with the online help documentation, or with the dir() information of a particular instance. E.g. the list of public features in the library reference (http://docs.python.org/lib/httpresponse-objects.html) is: - read - getheader - getheaders - msg - version - status - reason >From the online documentation (with 'help(httplib.HTTPResponse)'): - begin - close - getheader - getheaders - isclosed - read And from a class instance (via 'dir(httpResponseInstance)'): - 'begin', - 'chunk_left', - 'chunked', - 'close', - 'debuglevel', - 'fp', - 'getheader', - 'getheaders', - 'isclosed', - 'length', - 'msg', - 'read', - 'reason', - 'status', - 'strict', - 'version', - 'will_close' ---------- assignee: georg.brandl components: Documentation messages: 70158 nosy: ThomasH, georg.brandl severity: normal status: open title: httplib.HTTPResponse documentations inconsistent versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 23 17:48:19 2008 From: report at bugs.python.org (Georg Brandl) Date: Wed, 23 Jul 2008 15:48:19 +0000 Subject: [New-bugs-announce] [issue3431] multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle In-Reply-To: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za> Message-ID: <1216828098.95.0.494752132051.issue3431@psf.upfronthosting.co.za> New submission from Georg Brandl : multiprocessing's new ForkingPickler uses Pickler's dispatch attribute which is only present in the Python version, not the C one. As a result, a straightforward merge isn't possible. ---------- assignee: jnoller components: Library (Lib) messages: 70176 nosy: alexandre.vassalotti, georg.brandl, jnoller severity: normal status: open title: multiprocessing uses Pickler.dispatch which isn't in 3.0 _pickle versions: Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 04:42:54 2008 From: report at bugs.python.org (Robin Dunn) Date: Thu, 24 Jul 2008 02:42:54 +0000 Subject: [New-bugs-announce] [issue3432] Mac, 2.6 framework install error In-Reply-To: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za> Message-ID: <1216867374.16.0.0480249561855.issue3432@psf.upfronthosting.co.za> New submission from Robin Dunn : OSX Leopard (10.5.4) Python-2.6b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd Mac && make installmacsubtree DESTDIR="" Creating directory /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools DYLD_FRAMEWORK_PATH=/projects/Python-2.6b2: arch -ppc -i386 ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools Traceback (most recent call last): File "./scripts/cachersrc.py", line 7, in import macresource File "/projects/Python-2.6b2/Lib/plat-mac/macresource.py", line 6, in from Carbon import Res File "/projects/Python-2.6b2/Lib/plat-mac/Carbon/Res.py", line 4, in from _Res import * ImportError: No module named _Res make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 Since by this time in the install process the _Res module has already been installed I was able to work around this issue by hacking the generated Mac/Makefile and setting RUNSHARED to nothing. The same problem happens in Mac/IDLE/Makefile as well. ---------- components: Macintosh messages: 70189 nosy: robind severity: normal status: open title: Mac, 2.6 framework install error type: compile error versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 04:43:30 2008 From: report at bugs.python.org (Robin Dunn) Date: Thu, 24 Jul 2008 02:43:30 +0000 Subject: [New-bugs-announce] [issue3433] Mac, 3.0 framework install error with fink cp In-Reply-To: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za> Message-ID: <1216867410.47.0.735334999055.issue3433@psf.upfronthosting.co.za> New submission from Robin Dunn : OSX Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd PythonLauncher && make install DESTDIR= test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0" test -d "/Applications/Python 3.0/Python Launcher.app" && rm -r "/Applications/Python 3.0/Python Launcher.app" cp -r "Python Launcher.app" "/Applications/Python 3.0" touch "/Applications/Python 3.0/Python Launcher.app" test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0" test -d "/Applications/Python 3.0/IDLE.app" && rm -r "/Applications/Python 3.0/IDLE.app" make[1]: [install_IDLE] Error 1 (ignored) cp -PR IDLE/IDLE.app "/Applications/Python 3.0" cp: Warning: the meaning of `-P' will change in the future to conform to POSIX. Use `--parents' for the old meaning, and `--no-dereference' for the new one. ln -sf /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python "/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python" ln: creating symbolic link `/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python' to `/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python': No such file or directory make[1]: *** [install_IDLE] Error 1 make: *** [frameworkinstallapps] Error 2 It looks like this is due to fink's cp being found first on the PATH. Temporarily disabling /sw/bin/cp so /bin/cp would be found first then the install finished. ---------- components: Macintosh messages: 70190 nosy: robind severity: normal status: open title: Mac, 3.0 framework install error with fink cp type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 04:45:34 2008 From: report at bugs.python.org (Robin Dunn) Date: Thu, 24 Jul 2008 02:45:34 +0000 Subject: [New-bugs-announce] [issue3434] Mac, 3.0 framework install, Python.app not created In-Reply-To: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za> Message-ID: <1216867534.32.0.650772799481.issue3434@psf.upfronthosting.co.za> New submission from Robin Dunn : OS X Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app is not created by the install step, but it is needed for running python3.0: $ python3.0 python3.0: execv: /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python: No such file or directory ---------- components: Macintosh messages: 70191 nosy: robind severity: normal status: open title: Mac, 3.0 framework install, Python.app not created type: compile error versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 12:39:01 2008 From: report at bugs.python.org (Gustavo Narea) Date: Thu, 24 Jul 2008 10:39:01 +0000 Subject: [New-bugs-announce] [issue3435] trace.py tries to get coverage data from non Python files In-Reply-To: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za> Message-ID: <1216895941.29.0.346900095215.issue3435@psf.upfronthosting.co.za> New submission from Gustavo Narea : trace.py tries to get coverage information from non Python files, which raises a SyntaxError because the file doesn't contain valid Python code. I've attached a path that fixes this problem in Python 2.5. ---------- components: Library (Lib) files: trace.diff keywords: patch messages: 70197 nosy: Gustavo severity: normal status: open title: trace.py tries to get coverage data from non Python files type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file10964/trace.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 17:30:36 2008 From: report at bugs.python.org (Andrii V. Mishkovskyi) Date: Thu, 24 Jul 2008 15:30:36 +0000 Subject: [New-bugs-announce] [issue3436] csv.DictReader inconsistency In-Reply-To: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za> Message-ID: <1216913436.18.0.507506716118.issue3436@psf.upfronthosting.co.za> New submission from Andrii V. Mishkovskyi : I had to use csv module recently and ran into a "problem" with DictReader. I had to get headers of CSV file and only after that iterate throgh each row. But AFAIU there is no way to do it, other then subclassing. So, basically, right now we have this: Python 3.0b2+ (unknown, Jul 24 2008, 12:15:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import csv >>> r = csv.DictReader(open('test.csv')) >>> r.fieldnames >>> next(r) {'baz': '13', 'foo': '42', 'bar': '27'} >>> r.fieldnames ['foo', 'bar', 'baz'] I think it would be much more useful, if DictReader got 'fieldnames' on calling __init__ method, so this would look like this: >>> r = csv.DictReader(open('test.csv')) >>> r.fieldnames ['foo', 'bar', 'baz'] The easy way to do this is to subclass csv.DictReader. The hard way to do this is to apply the patches I'm attaching. :) These patches also remove redundant check for self.fieldnames being None for each next()/__next__() call ---------- files: py3k.csv.py.diff keywords: patch messages: 70207 nosy: mishok13 severity: normal status: open title: csv.DictReader inconsistency versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10965/py3k.csv.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 17:50:26 2008 From: report at bugs.python.org (mARK) Date: Thu, 24 Jul 2008 15:50:26 +0000 Subject: [New-bugs-announce] [issue3437] robotparser.py missing one line In-Reply-To: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za> Message-ID: <1216914625.92.0.56196072599.issue3437@psf.upfronthosting.co.za> New submission from mARK : RobotFileParser.parse() contains the lines elif line[0] == "disallow": if state != 0: entry.rulelines.append(RuleLine(line[1], False)) state = 2 elif line[0] == "allow": if state != 0: entry.rulelines.append(RuleLine(line[1], True)) with no 'state = 2' in the 'allow' part. This causes different behaviour depending on whether the file ends with 'allow' or 'disallow', or an empty line. Those lines were taken from revision 65118. My Python 2.5 sources are similar. I have not checked others. ---------- components: Library (Lib) messages: 70209 nosy: mbloore severity: normal status: open title: robotparser.py missing one line type: behavior versions: Python 2.5, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 17:59:00 2008 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 24 Jul 2008 15:59:00 +0000 Subject: [New-bugs-announce] [issue3438] PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement In-Reply-To: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za> Message-ID: <1216915140.34.0.387873405525.issue3438@psf.upfronthosting.co.za> New submission from Guilherme Polo : Yesterday I read at a maillist about IDLE being able to use the "with" statement in python 2.5 without needing to explicitly doing "from __future__ import with_statement", then today I started tracing the origin of this. It starts at the use of the InteractiveInterpreter from the code module (so this report affects any custom shells based on it), which uses the codeop module to compile lines. The Compile class of the codeop module, innocently compiles the passed source with a PyCF_DONT_IMPLY_DEDENT flag by default (I'm not going to enter in the other details done by Compile). This flag is then converted to PyPARSE_DONT_IMPLY_DEDENT (defined at parsetok.py with a value of 0x0002) by a PARSER_FLAGS macro at pythonrun.c. Later on the function parsertok at Parser/parsetok.c is called and it performs this check "if (flags & PyPARSE_WITH_IS_KEYWORD)", but PyPARSE_WITH_IS_KEYWORD right now has a value of 0x0003, so this check ends up working for both PyPARSE_WITH_IS_KEYWORD and PyPARSE_DONT_IMPLY_DEDENT, causing the with_statement to be enabled if the PyCF_DONT_IMPLY_DEDENT flag is passed to the compile builtin. To test this, start the interpreter (python 2.5) and: >>> a = compile('with open("something") as x: pass\n', '-', 'single', 0x200) >>> import __future__ >>> a = compile('with open("something") as x: pass\n', '-', 'single', __future__.with_statement.compiler_flag) Notice how it works in both cases. The patch added is deadly (!) simple (make clean is needed). ---------- components: Interpreter Core files: new_PyPARSE_WITH_IS_KEYWORD.diff keywords: patch messages: 70210 nosy: gpolo severity: normal status: open title: PyCF_DONT_IMPLY_DEDENT can be used to activate the with statement versions: Python 2.5 Added file: http://bugs.python.org/file10968/new_PyPARSE_WITH_IS_KEYWORD.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 19:20:44 2008 From: report at bugs.python.org (Fredrik Johansson) Date: Thu, 24 Jul 2008 17:20:44 +0000 Subject: [New-bugs-announce] [issue3439] math.frexp and obtaining the bit size of a large integer In-Reply-To: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> Message-ID: <1216920044.56.0.218954878238.issue3439@psf.upfronthosting.co.za> New submission from Fredrik Johansson : Python 3.0b2 (r30b2:65106, Jul 18 2008, 18:44:17) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> math.frexp(10**100) (0.5714936956411375, 333) >>> math.frexp(10**1000) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C double >>> (Same behavior in Python 2.5.2, and presumably 2.6 although I haven't checked the latter.) I think it should be easy to make frexp work for large integers by calling PyLong_AsScaledDouble and adding the exponents. It would be logical to fix this since math.log(n) already works for large integers. My reason for requesting this change is that math.frexp is the fastest way I know of to accurately count the number of bits in a Python integer (it is more robust than math.log(n,2) and makes it easy to verify that the computed size is exact) and this is something I need to do a lot. Actually, it would be even more useful to have a standard function to directly obtain the bit size of an integer. If I'm not mistaken, PyLong_NumBits does precisely this, and would just have to be wrapped. Aside from my own needs (which don't reflect those of the Python community), there is at least one place in the standard library where this would be useful: decimal.py contains an inefficient implementation (_nbits) that could removed. ---------- components: Library (Lib) messages: 70216 nosy: fredrikj severity: normal status: open title: math.frexp and obtaining the bit size of a large integer type: feature request versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 24 22:58:55 2008 From: report at bugs.python.org (Lenard Lindstrom) Date: Thu, 24 Jul 2008 20:58:55 +0000 Subject: [New-bugs-announce] [issue3440] Starting Python as a subprocess fails when subprocess.Popen has env argument In-Reply-To: <1216933135.87.0.837899480676.issue3440@psf.upfronthosting.co.za> Message-ID: <1216933135.87.0.837899480676.issue3440@psf.upfronthosting.co.za> New submission from Lenard Lindstrom : Python 2.6b2 (r26b2:65106, Jul 18 2008, 18:22:27) [MSC v.1500 32 bit (Intel)] on win32 Windows XP Professional, SP 2 Library class subprocess.Popen When subprocess.Popen is used to start the python interpreter as a subprocess with a custom environment, env is set to a mapping, the subprocess terminates with the following pop-up error dialog: "The application failed to initialize properly (0xc0150004). Click on OK to terminate the application." The attached fail.py program reproduces the bug. It should print "ABCDE" if successful. It does for Pythons 2.4 and 2.5. The reason is that Python 2.6 on Windows requires the environment variable SystemRoot, which it cannot find. This is demonstrated by modifying fail.py to include SystemRoot in the environment. This works: import sys import os import subprocess command = ('''%s -c "import os; print os.environ['YAHOO']"''' % sys.executable) env = {"YAHOO": "ABCDE", "SystemRoot": os.environ["SystemRoot"]} subprocess.Popen(command, env=env).wait() ---------- components: Library (Lib), Windows files: fail.py messages: 70225 nosy: kermode severity: normal status: open title: Starting Python as a subprocess fails when subprocess.Popen has env argument type: crash versions: Python 2.6 Added file: http://bugs.python.org/file10970/fail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 06:09:07 2008 From: report at bugs.python.org (Richard Jones) Date: Fri, 25 Jul 2008 04:09:07 +0000 Subject: [New-bugs-announce] [issue3441] Regression in "module as a script" command-line option In-Reply-To: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za> Message-ID: <1216958947.84.0.328980880705.issue3441@psf.upfronthosting.co.za> New submission from Richard Jones : The Python 2.5 "-m" command-line option allowed execution of a package directly, by invoking the __init__.py module. Python 2.6 no longer allows this. This is a quite unfortunate regression, and I would urge the decision to hobble it to be reconsidered. ---------- messages: 70240 nosy: richard severity: normal status: open title: Regression in "module as a script" command-line option versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 13:38:07 2008 From: report at bugs.python.org (Pavel Strashkin) Date: Fri, 25 Jul 2008 11:38:07 +0000 Subject: [New-bugs-announce] [issue3442] wsgiref.validate.InputWrapper.readline does not accept optional "length" argument In-Reply-To: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za> Message-ID: <1216985887.33.0.844888743388.issue3442@psf.upfronthosting.co.za> New submission from Pavel Strashkin : All file/stream-like objects in Python have "readline" method with optional "length" argument, but wsgiref.validate.InputWrapper doest not have. Some 3rd party modules/packages use this argument. As result there is exception: : readline() takes exactly 1 argument (2 given) I think wsgiref.validate.InputWrapper.readline must be implemented same to wsgiref.validate.InputWrapper.read: def readline(self, *args, **kwargs): v = self.input.readline(*args, **kwargs) assert_(type(v) is type("")) return v ---------- components: Library (Lib) messages: 70248 nosy: xaka severity: normal status: open title: wsgiref.validate.InputWrapper.readline does not accept optional "length" argument versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 14:55:50 2008 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 25 Jul 2008 12:55:50 +0000 Subject: [New-bugs-announce] [issue3443] crash on badly initialised AttributeError In-Reply-To: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za> Message-ID: <1216990549.95.0.558600790355.issue3443@psf.upfronthosting.co.za> New submission from Stefan Behnel : I get a reproducible crash under Linux when running the test cases of lxml's trunk in Py3b2. As usual with these things, it's not reproducible when running the crashing test by itself, only when it hits the test during the usual test run (which makes it look like somethings's leaking between tests here). Here is what gdb gives me so far. ---------------------- [...] test_namespace_lookup (lxml.tests.test_classlookup.ClassLookupTestCase) ... ok test_parser_based_lookup (lxml.tests.test_classlookup.ClassLookupTestCase) ... ok Doctest: test_css_select.txt ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210656576 (LWP 938)] 0x080f3b89 in BaseException_str (self=0x8d747d4) at Objects/exceptions.c:88 88 switch (PyTuple_GET_SIZE(self->args)) { (gdb) pyo self object : AttributeError type : AttributeError refcount: 10 address : 0x8d747d4 $1 = void (gdb) print self->args $2 = (PyObject *) 0x0 (gdb) bt #0 0x080f3b89 in BaseException_str (self=0x8d747d4) at Objects/exceptions.c:88 #1 0x0805b158 in PyObject_Str (v=0x8d747d4) at Objects/object.c:414 #2 0x0807951a in unicode_new (type=0x81523a0, args=0x8de77ac, kwds=0x0) at Objects/unicodeobject.c:9247 #3 0x0806068d in type_call (type=0x81523a0, args=0x8de77ac, kwds=0x0) at Objects/typeobject.c:636 #4 0x080d83a9 in PyObject_Call (func=0x81523a0, arg=0x8de77ac, kw=0x0) at Objects/abstract.c:2178 #5 0x0808de50 in PyEval_EvalFrameEx (f=0x8e2d07c, throwflag=0) at Python/ceval.c:3606 #6 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2bf14, throwflag=0) at Python/ceval.c:3481 #7 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2cef4, throwflag=0) at Python/ceval.c:3481 #8 0x0808fccd in PyEval_EvalFrameEx (f=0x8e2d4ec, throwflag=0) at Python/ceval.c:3481 #9 0x08090f6b in PyEval_EvalCodeEx (co=0x8268458, globals=0xb7b772d4, locals=0x0, args=0x8e2cea4, argcount=3, kws=0x8e2ceb0, kwcount=1, defs=0x826c678, defcount=3, kwdefs=0x0, closure=0x0) at Python/ceval.c:2830 #10 0x0808f63e in PyEval_EvalFrameEx (f=0x8e2cd54, throwflag=0) at Python/ceval.c:3491 #11 0x0808fccd in PyEval_EvalFrameEx (f=0x8dc37a4, throwflag=0) at Python/ceval.c:3481 #12 0x0808fccd in PyEval_EvalFrameEx (f=0x8da1d7c, throwflag=0) at Python/ceval.c:3481 #13 0x08090f6b in PyEval_EvalCodeEx (co=0x84b21d0, globals=0x847d79c, locals=0x0, args=0x8da0dbc, argcount=2, kws=0x8da0dc4, kwcount=2, defs=0x8591b78, defcount=3, kwdefs=0x0, closure=0x0) at Python/ceval.c:2830 #14 0x0808f63e in PyEval_EvalFrameEx (f=0x8da0c64, throwflag=0) at Python/ceval.c:3491 #15 0x0808fccd in PyEval_EvalFrameEx (f=0x8da00ec, throwflag=0) at Python/ceval.c:3481 #16 0x08090f6b in PyEval_EvalCodeEx (co=0xb7b80410, globals=0xb7b75824, locals=0x0, args=0x8d6ee98, argcount=2, kws=0x89e8058, kwcount=0, defs=0x826a518, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:2830 #17 0x080fe855 in function_call (func=0x8267e6c, arg=0x8d6ee8c, kw=0x8ccee84) at Objects/funcobject.c:628 #18 0x080d83a9 in PyObject_Call (func=0x8267e6c, arg=0x8d6ee8c, kw=0x8ccee84) at Objects/abstract.c:2178 #19 0x0808d73f in PyEval_EvalFrameEx (f=0x8d9ff84, throwflag=0) at Python/ceval.c:3694 #20 0x08090f6b in PyEval_EvalCodeEx (co=0xb7b80458, globals=0xb7b75824, locals=0x0, args=0x8d7f078, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2830 [...] (gdb) pyo 0x8268458 object : type : code refcount: 2 address : 0x8268458 $3 = void ---------------------- When I call "pystack", gdb seems to lock up using 100% CPU, so I'm not sure what else I can provide. The crash happening in a non-trivial doctest makes is somewhat tricky to figure out what gets executed here. At least, there is no anticipated AttributeError in the doctest, and it doesn't seem to get raised when I run the test just by itself. ---------- components: Interpreter Core messages: 70253 nosy: scoder severity: normal status: open title: crash on badly initialised AttributeError type: crash versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 16:48:11 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 25 Jul 2008 14:48:11 +0000 Subject: [New-bugs-announce] [issue3444] add warnings for intra-package imports In-Reply-To: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za> Message-ID: <1216997291.25.0.564093390831.issue3444@psf.upfronthosting.co.za> New submission from Benjamin Peterson : Non-absolute or relative imports in 2.6 should give a Py3k warning. ---------- components: Interpreter Core messages: 70254 nosy: benjamin.peterson priority: release blocker severity: normal status: open title: add warnings for intra-package imports type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 17:26:55 2008 From: report at bugs.python.org (Antoine d'Otreppe) Date: Fri, 25 Jul 2008 15:26:55 +0000 Subject: [New-bugs-announce] [issue3445] functools.update_wrapper bug In-Reply-To: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za> Message-ID: <1216999615.48.0.706294847693.issue3445@psf.upfronthosting.co.za> New submission from Antoine d'Otreppe : When trying to do something like "functools.update_wrapper(myWrapper, str.split)" I got this error message: Traceback (most recent call last): File "", line 1, in File "Aspyct.py", line 175, in beforeCall _stickAdvice(function, theAdvice) File "Aspyct.py", line 90, in _stickAdvice functools.update_wrapper(theAdvice, function) File "/usr/lib/python2.5/functools.py", line 33, in update_wrapper setattr(wrapper, attr, getattr(wrapped, attr)) AttributeError: 'method_descriptor' object has no attribute '__module__' ---------- components: Library (Lib) messages: 70256 nosy: Antoine d'Otreppe severity: normal status: open title: functools.update_wrapper bug type: behavior versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 17:59:23 2008 From: report at bugs.python.org (=?utf-8?q?Ignas_Mikalaj=C5=ABnas?=) Date: Fri, 25 Jul 2008 15:59:23 +0000 Subject: [New-bugs-announce] [issue3446] center, ljust and rjust are inconsistent with unicode parameters In-Reply-To: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za> Message-ID: <1217001563.39.0.568934696199.issue3446@psf.upfronthosting.co.za> New submission from Ignas Mikalaj?nas : Not all combinations of unicode/non-unicode parameters work for ljust, center and rjust. Passing a unicode character to them as a parameter when the string is ascii fails with an error. This doctest fails in 3 places. Though I would expect it to be passing. def doctest_strings(): """ >>> uni = u"a" >>> ascii = "a" >>> uni.center(5, ascii) u'aaaaa' >>> uni.center(5, uni) u'aaaaa' >>> ascii.center(5, ascii) 'aaaaa' >>> ascii.center(5, uni) u'aaaaa' >>> uni.ljust(5, ascii) u'aaaaa' >>> uni.ljust(5, uni) u'aaaaa' >>> ascii.ljust(5, ascii) 'aaaaa' >>> ascii.ljust(5, uni) u'aaaaa' >>> uni.rjust(5, ascii) u'aaaaa' >>> uni.rjust(5, uni) u'aaaaa' >>> ascii.rjust(5, ascii) 'aaaaa' >>> ascii.rjust(5, uni) u'aaaaa' """ ---------- components: Library (Lib), Unicode messages: 70258 nosy: ignas severity: normal status: open title: center, ljust and rjust are inconsistent with unicode parameters type: behavior versions: Python 2.4, Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 18:51:15 2008 From: report at bugs.python.org (Alejandro J. Cura) Date: Fri, 25 Jul 2008 16:51:15 +0000 Subject: [New-bugs-announce] [issue3447] itertools.izip_longest docs don't specify default fillvalue In-Reply-To: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za> Message-ID: <1217004675.67.0.084485803306.issue3447@psf.upfronthosting.co.za> New submission from Alejandro J. Cura : izip_longest default fillvalue is None, but the docs don't specify it. I'm attaching a diff that fixes this. ---------- assignee: georg.brandl components: Documentation files: itertools.izip_longest-default-fillvalue.diff keywords: patch messages: 70259 nosy: alecu, georg.brandl severity: normal status: open title: itertools.izip_longest docs don't specify default fillvalue type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10980/itertools.izip_longest-default-fillvalue.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 25 23:06:38 2008 From: report at bugs.python.org (Nick Edds) Date: Fri, 25 Jul 2008 21:06:38 +0000 Subject: [New-bugs-announce] [issue3448] Multi-process 2to3 In-Reply-To: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za> Message-ID: <1217019998.69.0.231122552254.issue3448@psf.upfronthosting.co.za> New submission from Nick Edds : Here is a working, multiprocess version of 2to3 with a few caveats. First, you need to already have the processing module installed for this to work. If we don't want to include processing in some way, I think I can modify this to only import processing and use the Process method if the user wants to run it with more than one process. Also, I know that logger is supposed to be thread safe, so I am correct in assuming that this means it is also multi-process safe? This fix delegates the fixing of files to a designated number of processes, so on a multi-core machine, it is significantly faster. It may be appropriate to add a test suite for it, but I have not yet done so. I've tested it on my dual-core laptop running Ubuntu and a quad-core mac and it appears to be working fine. I don't know if the use of tempfile was the right choice, but it seemed reasonable. Another possibility is to instead using a processing Queue and pass it the output, filename, and input rather than calling write_file. Also, the join timeout I used is completely arbitrary because I don't really have a sense of what a reasonable value for it should be. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: multiProcess.diff keywords: patch messages: 70277 nosy: collinwinter, nedds severity: normal status: open title: Multi-process 2to3 type: performance Added file: http://bugs.python.org/file10985/multiProcess.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 26 00:16:13 2008 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 25 Jul 2008 22:16:13 +0000 Subject: [New-bugs-announce] [issue3449] Update decimal module to version 1.68 of the IBM specification In-Reply-To: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za> Message-ID: <1217024173.73.0.509387399597.issue3449@psf.upfronthosting.co.za> New submission from Mark Dickinson : The IBM General Decimal Arithmetic Specification, on which the decimal module is based, has recently been updated to version 1.68; the testcases from IBM have also been updated. The comments in the decimal module clearly state that the decimal module should be kept in sync with the IBM specification, and that deviation from the spec is considered a bug. So it seems to me that the decimal module should be updated, preferably before 2.6 and 3.0 come out. As far as I can tell the required changes should be minimal: max- magnitude and min-magnitude definitely need changing, and there may be other minor changes necessary to make the new tests pass; I haven't looked properly yet. I'll try to get to this in the next few days. ---------- assignee: marketdickinson components: Library (Lib) messages: 70284 nosy: facundobatista, marketdickinson, rhettinger priority: critical severity: normal status: open title: Update decimal module to version 1.68 of the IBM specification type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 26 13:40:21 2008 From: report at bugs.python.org (Nobody/Anonymous) Date: Sat, 26 Jul 2008 11:40:21 +0000 Subject: [New-bugs-announce] [issue3450] Buy stocks now to make money In-Reply-To: <000601c8ef14$6216e0b0$fdfea37a@San> Message-ID: <000601c8ef14$6216e0b0$fdfea37a@San> New submission from Nobody/Anonymous: Your wife says his bed skills are better than yours http://kwhgs.ca/topnews.html ---------- files: unnamed messages: 70297 nosy: nobody severity: normal status: open title: Buy stocks now to make money Added file: http://bugs.python.org/file10989/unnamed _______________________________________ Python tracker _______________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed URL: From report at bugs.python.org Sun Jul 27 03:11:05 2008 From: report at bugs.python.org (Fredrik Johansson) Date: Sun, 27 Jul 2008 01:11:05 +0000 Subject: [New-bugs-announce] [issue3451] Asymptotically faster divmod and str(long) In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za> Message-ID: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za> New submission from Fredrik Johansson : A few weeks ago, I blogged about taking advantage of Karatsuba multiplication and Newton's method to divide big integers quickly (some of you may have read it, as it was posted to Daily Python-URL among other places): http://fredrik-j.blogspot.com/2008/07/making-division-in-python-faster.html To summarize, this method blows the builtin division out of the water already at ~(2000 digits)/(1000 digits). The primary catch is that the result of the Newton division may be slightly wrong (typically 1 ulp). However, a single extra multiplication and a subtraction at the end allows one to compute a remainder, and since the remainder must satisfy 0 <= r < q, the error is easily corrected. From a quick test, the cost of the extra multiplication seems to move the break-even point with the builtin division up to around 5000/2500 digits. A pure Python implementation of divmod, with error correction based on the remainder, can be found in this file: http://www.dd.chalmers.se/~frejohl/code/libarith/libarith.py (See the function idivmod) Of particular note is that fast divmod gives a fast way to do radix conversion, by recursively splitting the number in half. The function numeral (see same .py file) does this, e.g: >>> from time import clock >>> a = 2**1257787-1 >>> t1=clock(); s1=str(a); t2=clock(); t2-t1 109.08065159119386 >>> t1=clock(); s2=numeral(a); t2=clock(); t2-t1 7.1394886780303182 >>> s1 == s2 True (This recursive algorithm, by the way, is actually faster than str() even with the slow builtin divmod.) Would there be any interest in porting these algorithms to C and using them in the standard Python long implementation? There are likely some problems that I have overlooked. A critical review will be most welcome. ---------- components: Interpreter Core messages: 70309 nosy: fredrikj severity: normal status: open title: Asymptotically faster divmod and str(long) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 27 16:39:39 2008 From: report at bugs.python.org (lregebro) Date: Sun, 27 Jul 2008 14:39:39 +0000 Subject: [New-bugs-announce] [issue3452] subprocess.Popen description unclear. In-Reply-To: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za> Message-ID: <1217169579.5.0.521766841599.issue3452@psf.upfronthosting.co.za> New submission from lregebro : In the documentation of subprocess.Popen the docs say: "args should be a string, or a sequence of program arguments. The program to execute is normally the first item in the args sequence or string, but can be explicitly set by using the executable argument. " The statement that the program to exectute is the "first item in the args sequence or string" indicates that the first item in a string like "ls -l", i.e. the "ls" will be the program. The next paragraph however makes it clear that this is not the case, but by then the damage is done, and you think that passing in "ls -l" will work. Rewording this, perhaps by saying "The program to execute is normally the first item in the args sequence, or the string if a string a given", would make this clear. ---------- assignee: georg.brandl components: Documentation messages: 70321 nosy: georg.brandl, lregebro severity: normal status: open title: subprocess.Popen description unclear. versions: Python 2.5, Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 27 17:14:05 2008 From: report at bugs.python.org (Roger Upole) Date: Sun, 27 Jul 2008 15:14:05 +0000 Subject: [New-bugs-announce] [issue3453] PyType_Ready doesn't ensure that all bases are ready In-Reply-To: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za> Message-ID: <1217171645.31.0.486361917431.issue3453@psf.upfronthosting.co.za> New submission from Roger Upole : If a type's tp_base has not been initialized yet, PyType_Ready calls itself for tp_base. However, it doesn't do the same for members of tp_bases. The inheritance determinations assume that all bases are ready, in particular that tp_mro is not null. ---------- components: Interpreter Core messages: 70322 nosy: rupole severity: normal status: open title: PyType_Ready doesn't ensure that all bases are ready versions: Python 2.4, Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 27 21:58:01 2008 From: report at bugs.python.org (John Firestone) Date: Sun, 27 Jul 2008 19:58:01 +0000 Subject: [New-bugs-announce] [issue3454] __getitem__() doesn't capture all slices if class inherits from list, tuple or str Message-ID: <1217188681.81.0.529319728995.issue3454@psf.upfronthosting.co.za> Changes by John Firestone : ---------- components: Interpreter Core files: getitem_problem.py nosy: johnf severity: normal status: open title: __getitem__() doesn't capture all slices if class inherits from list, tuple or str type: performance versions: Python 2.5 Added file: http://bugs.python.org/file10992/getitem_problem.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 28 02:40:09 2008 From: report at bugs.python.org (=?utf-8?q?=E9=A6=99=E6=A7=9F=E9=85=92?=) Date: Mon, 28 Jul 2008 00:40:09 +0000 Subject: [New-bugs-announce] [issue3455] os.remove()method document error In-Reply-To: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za> Message-ID: <1217205609.34.0.035982890049.issue3455@psf.upfronthosting.co.za> New submission from ??? : in Python 2.5 document, os.remove() explain: On Windows, attempting to remove a file that is in use causes an exception to be raised. but, i run it in IDLE.it deletes my file that in use without any exception. ---------- assignee: georg.brandl components: Documentation messages: 70334 nosy: georg.brandl, zkfarmer severity: normal status: open title: os.remove()method document error type: performance versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 28 09:46:48 2008 From: report at bugs.python.org (Xue Can) Date: Mon, 28 Jul 2008 07:46:48 +0000 Subject: [New-bugs-announce] [issue3456] compile python using MinGW In-Reply-To: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za> Message-ID: <1217231208.12.0.680278518143.issue3456@psf.upfronthosting.co.za> New submission from Xue Can : I hope the official source release can add support for MinGW to compile python under Win32 platform. And layout built files like python in Unix-like paltforms. ---------- components: Build messages: 70338 nosy: xuecan severity: normal status: open title: compile python using MinGW type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 28 14:49:40 2008 From: report at bugs.python.org (Cliff Dyer) Date: Mon, 28 Jul 2008 12:49:40 +0000 Subject: [New-bugs-announce] [issue3457] Release notes for 2.6b2 call it an alpha release In-Reply-To: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za> Message-ID: <1217249380.52.0.254772841824.issue3457@psf.upfronthosting.co.za> New submission from Cliff Dyer : The release notes for python 2.6b2 at http://www.python.org/download/releases/2.6/ identify the release as an alpha release. I'm not sure, but the disclaimer regarding who should use it might need changing too. alpha != beta ---------- assignee: georg.brandl components: Documentation messages: 70345 nosy: georg.brandl, jcd severity: normal status: open title: Release notes for 2.6b2 call it an alpha release type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 28 18:24:27 2008 From: report at bugs.python.org (David Farrar) Date: Mon, 28 Jul 2008 16:24:27 +0000 Subject: [New-bugs-announce] [issue3458] dict.update() optimisation gives unexpected/invalid results when passed a subclass of DictType In-Reply-To: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za> Message-ID: <1217262267.3.0.619120390948.issue3458@psf.upfronthosting.co.za> New submission from David Farrar : Using a python module that expected me to pass a dictionary as a parameter to a function, I found that I was getting unexpected results when using a class which inherits from types.DictType. The module was passing the instance I had supplied as a parameter to update() on a newly created dictionary. I wanted my class to present its methods as items of the dictionary it was pretending to be. Even though I could see that __getattribute__ had been called to get 'keys', keys() was not called and I ended up with an empty dictionary. Trying to find the cause of the problem, I downloaded the python source package and found that in PyDict_Merge (in Objects/dictobject.c, line 1359), there is an optimisation that is run if PyDict_Check determines that the parameter we passed is itself a dictionary. The optimisation takes advantage of the fact that we know how data is stored in the dictionary and accesses whatever it needs directly. I had overridden keys() to provide the result I wanted but this optimisation prevented the code from ever being run, leading to code that seems like it should work failing with no apparent cause. The only way I could find around this was to raise AttributeError in __getattribute__ when getting 'keys', causing dict_update_common to call PyDict_MergeFromSeq2 in place of PyDict_Merge. Should the call to PyDict_Check in PyDict_Merge not be replaced with PyDict_CheckExact ? This would keep the optimisation in place in most cases, where we know that it is safe, still allowing keys() to be overridden as you expect. ---------- components: Interpreter Core files: dictionary.patch keywords: patch messages: 70353 nosy: david severity: normal status: open title: dict.update() optimisation gives unexpected/invalid results when passed a subclass of DictType type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file10997/dictionary.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 28 20:51:27 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jul 2008 18:51:27 +0000 Subject: [New-bugs-announce] [issue3459] optimize bytes.join() In-Reply-To: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za> Message-ID: <1217271087.67.0.340515094657.issue3459@psf.upfronthosting.co.za> New submission from Antoine Pitrou : When the separator is empty and the sequence only contains one non-empty item, it is possible to optimize b"".join([...]) by simply returning the non-empty item. Since b"".join() is the recommended idiom to join large strings together, I think it can be useful. I encountered this when trying to optimize io.BufferedReader. ./python -m timeit -s "l=[b'', b'a' * 10000]" "b''.join(l)" before the patch: 100000 loops, best of 3: 2.35 usec per loop after the patch: 1000000 loops, best of 3: 0.335 usec per loop ---------- components: Interpreter Core files: bytesjoin.patch keywords: patch messages: 70365 nosy: pitrou severity: normal status: open title: optimize bytes.join() type: performance versions: Python 3.0 Added file: http://bugs.python.org/file10999/bytesjoin.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 28 21:04:38 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 28 Jul 2008 19:04:38 +0000 Subject: [New-bugs-announce] [issue3460] PyUnicode_Join could perhaps be simpler In-Reply-To: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za> Message-ID: <1217271878.68.0.784852839744.issue3460@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In py3k, PyUnicode_Join inherits some complexity from the 2.x days. However, it seems some of the precautions taken there may not be needed anymore. Witness the following comment: /* Grrrr. A codec may be invoked to convert str objects to * Unicode, and so it's possible to call back into Python code * during PyUnicode_FromObject(), and so it's possible for a sick * codec to change the size of fseq (if seq is a list). Therefore * we have to keep refetching the size -- can't assume seqlen * is invariant. */ Perhaps it would also allow to preallocate the target buffer all at once (like bytes.join does) rather than resize it incrementally. Marc-Andre, what do you think? ---------- components: Unicode messages: 70367 nosy: lemburg, pitrou priority: normal severity: normal status: open title: PyUnicode_Join could perhaps be simpler type: performance versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 00:08:45 2008 From: report at bugs.python.org (Derek Morr) Date: Mon, 28 Jul 2008 22:08:45 +0000 Subject: [New-bugs-announce] [issue3461] smtplib does not fully support IPv6 in EHLO In-Reply-To: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za> Message-ID: <1217282925.26.0.916204427354.issue3461@psf.upfronthosting.co.za> New submission from Derek Morr : On an IPv6-only machine, smtplib does not send an IPv6 address in the EHLO. It sends "EHLO [0.0.0.0]" instead. For example, on a v6-only network with stateless autoconfiguration enabled (a common configuration), smtplib will show this error. Further, SMTP's __init__() method tries to determine the value of EHLO parameter before the socket is established. But it can't know what value to use before the socket is setup (e.g., should it use a hostname, a v4 address literal, or a v6 address literal). The attached patch moves the self.local_hostname processing into the connect() method, and updates it to use IPv6-aware resolver interfaces. ---------- components: Library (Lib) files: python_smtplib.patch keywords: patch messages: 70372 nosy: dmorr severity: normal status: open title: smtplib does not fully support IPv6 in EHLO type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file11000/python_smtplib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 04:06:35 2008 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 29 Jul 2008 02:06:35 +0000 Subject: [New-bugs-announce] [issue3462] test_builtin fails after test_decimal In-Reply-To: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za> Message-ID: <1217297195.52.0.306735068068.issue3462@psf.upfronthosting.co.za> New submission from Benjamin Peterson : In Py3k: $ ./python Lib/test/regrtest.py test_decimal test_builtin test_decimal test_builtin test test_builtin failed -- Traceback (most recent call last): File "Lib/test/regrtest.py", line 603, in runtest_inner indirect_test() File "/temp/python/py3k/Lib/test/test_builtin.py", line 1252, in test_main run_unittest(*test_classes) File "/temp/python/py3k/Lib/test/support.py", line 717, in run_unittest _run_suite(suite) File "/temp/python/py3k/Lib/test/support.py", line 700, in _run_suite raise TestFailed(err) test.support.TestFailed: Traceback (most recent call last): File "/temp/python/py3k/Lib/test/test_builtin.py", line 390, in test_general_eval self.assertEqual(eval('globals()', g, m), g) AssertionError: {'unittest': , 'random': , 'test_conv_no_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314), (' 314', 314), ('314 ', 314), (' \t\t 314 \t\t ', 314), ('2147483647', 2147483647), (' 1x', ), (' 1 ', 1), (' 1\x02 ', ), ('', ), (' ', ), (' \t\t ', ), ('\u0663\u0661\u0664 ', 314), ('\u0200', )], 'test_conv_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314), (' 314', ), ('314 ', 314), (' \t\t 314 \t\t ', ), ('2147483647', 2147483647), (' 1x', ), (' 1 ', ), (' 1\x02 ', ), ('', ), (' ', ), (' \t\t ', ), ('\u0663\u0661\u0664 ', 314), ('\u0200', )], 'run_with_locale': , 'io': , 'Squares': , 'neg': , '__package__': None, 'collections': , 'TestFailingIter': , 'run_unittest': , '__doc__': None, 'test_main': , 'fractions': , 'StrSquares': , 'warnings': , '__builtins__': {'bytearray': , 'IndexError': , 'all': , 'help': Type help() for interactive help, or help(object) for help about object., 'vars': , 'SyntaxError': , 'UnicodeDecodeError': , 'memoryview': , 'isinstance': , '__build_class__': , 'copyright': Copyright (c) 2001-2008 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved., 'NameError': , 'BytesWarning': , 'dict': , 'IOError': , 'oct': , 'bin': , 'SystemExit': , 'format': , 'repr': , 'sorted': , 'False': False, 'RuntimeWarning': , 'list': , 'iter': , 'Warning': , '__package__': None, 'round': , 'dir': , 'cmp': , 'set': , 'bytes': , 'UnicodeTranslateError': , 'issubclass': , 'EOFError': , 'locals': , 'BufferError': , 'slice': , 'FloatingPointError': , 'sum': , 'getattr': , 'abs': , 'exit': Use exit() or Ctrl-D (i.e. EOF) to exit, 'print': , 'True': True, 'FutureWarning': , 'ImportWarning': , 'None': None, 'hash': , 'ReferenceError': , 'len': , 'credits': Thanks to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands for supporting Python development. See www.python.org for more information., 'frozenset': , '__name__': 'builtins', 'ord': , 'super': , '_': Decimal('NaN123'), 'TypeError': , 'license': Type license() to see the full license text, 'KeyboardInterrupt': , 'UserWarning': , 'filter': , 'range': , 'staticmethod': , 'SystemError': , 'BaseException': , 'pow': , 'RuntimeError': , 'float': , 'MemoryError': , 'StopIteration': , 'globals': , 'divmod': , 'enumerate': , 'Ellipsis': Ellipsis, 'LookupError': , 'open': , 'quit': Use quit() or Ctrl-D (i.e. EOF) to exit, 'UnicodeError': , 'zip': , 'hex': , 'next': , 'ImportError': , 'chr': , 'type': , '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", 'Exception': , 'tuple': , 'reversed': , 'UnicodeEncodeError': , 'input': , 'hasattr': , 'delattr': , 'setattr': , 'SyntaxWarning': , 'compile': , 'ArithmeticError': , 'str': , 'property': , 'GeneratorExit': , 'int': , '__import__': , 'KeyError': , 'PendingDeprecationWarning': , 'EnvironmentError': , 'ascii': , 'id': , 'OSError': , 'DeprecationWarning': , 'min': , 'UnicodeWarning': , 'any': , 'complex': , 'bool': , 'ValueError': , 'NotImplemented': NotImplemented, 'map': , 'exec': , 'max': , 'object': , 'TabError': , 'ZeroDivisionError': , 'eval': , '__debug__': True, 'IndentationError': , 'AssertionError': , 'classmethod': , 'UnboundLocalError': , 'NotImplementedError': , 'AttributeError': , 'OverflowError': }, '__file__': '/temp/python/py3k/Lib/test/test_builtin.py', 'BuiltinTest': , 'TestFailingBool': , 'sys': , 'test': , '__name__': 'test.test_builtin', 'unlink': , 'TESTFN': '@test', 'TestSorted': , 'BitBucket': , 'fcmp': } != {'unittest': , 'random': , 'test_conv_no_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314), (' 314', 314), ('314 ', 314), (' \t\t 314 \t\t ', 314), ('2147483647', 2147483647), (' 1x', ), (' 1 ', 1), (' 1\x02 ', ), ('', ), (' ', ), (' \t\t ', ), ('\u0663\u0661\u0664 ', 314), ('\u0200', )], 'test_conv_sign': [('0', 0), ('1', 1), ('9', 9), ('10', 10), ('99', 99), ('100', 100), ('314', 314), (' 314', ), ('314 ', 314), (' \t\t 314 \t\t ', ), ('2147483647', 2147483647), (' 1x', ), (' 1 ', ), (' 1\x02 ', ), ('', ), (' ', ), (' \t\t ', ), ('\u0663\u0661\u0664 ', 314), ('\u0200', )], 'run_with_locale': , 'io': , 'Squares': , 'neg': , '__package__': None, 'collections': , 'TestFailingIter': , 'run_unittest': , '__doc__': None, 'test_main': , 'fractions': , 'StrSquares': , 'warnings': , '__builtins__': {'bytearray': , 'IndexError': , 'all': , 'help': Type help() for interactive help, or help(object) for help about object., 'vars': , 'SyntaxError': , 'UnicodeDecodeError': , 'memoryview': , 'isinstance': , '__build_class__': , 'copyright': Copyright (c) 2001-2008 Python Software Foundation. All Rights Reserved. Copyright (c) 2000 BeOpen.com. All Rights Reserved. Copyright (c) 1995-2001 Corporation for National Research Initiatives. All Rights Reserved. Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam. All Rights Reserved., 'NameError': , 'BytesWarning': , 'dict': , 'IOError': , 'oct': , 'bin': , 'SystemExit': , 'format': , 'repr': , 'sorted': , 'False': False, 'RuntimeWarning': , 'list': , 'iter': , 'Warning': , '__package__': None, 'round': , 'dir': , 'cmp': , 'set': , 'bytes': , 'UnicodeTranslateError': , 'issubclass': , 'EOFError': , 'locals': , 'BufferError': , 'slice': , 'FloatingPointError': , 'sum': , 'getattr': , 'abs': , 'exit': Use exit() or Ctrl-D (i.e. EOF) to exit, 'print': , 'True': True, 'FutureWarning': , 'ImportWarning': , 'None': None, 'hash': , 'ReferenceError': , 'len': , 'credits': Thanks to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands for supporting Python development. See www.python.org for more information., 'frozenset': , '__name__': 'builtins', 'ord': , 'super': , '_': Decimal('NaN123'), 'TypeError': , 'license': Type license() to see the full license text, 'KeyboardInterrupt': , 'UserWarning': , 'filter': , 'range': , 'staticmethod': , 'SystemError': , 'BaseException': , 'pow': , 'RuntimeError': , 'float': , 'MemoryError': , 'StopIteration': , 'globals': , 'divmod': , 'enumerate': , 'Ellipsis': Ellipsis, 'LookupError': , 'open': , 'quit': Use quit() or Ctrl-D (i.e. EOF) to exit, 'UnicodeError': , 'zip': , 'hex': , 'next': , 'ImportError': , 'chr': , 'type': , '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", 'Exception': , 'tuple': , 'reversed': , 'UnicodeEncodeError': , 'input': , 'hasattr': , 'delattr': , 'setattr': , 'SyntaxWarning': , 'compile': , 'ArithmeticError': , 'str': , 'property': , 'GeneratorExit': , 'int': , '__import__': , 'KeyError': , 'PendingDeprecationWarning': , 'EnvironmentError': , 'ascii': , 'id': , 'OSError': , 'DeprecationWarning': , 'min': , 'UnicodeWarning': , 'any': , 'complex': , 'bool': , 'ValueError': , 'NotImplemented': NotImplemented, 'map': , 'exec': , 'max': , 'object': , 'TabError': , 'ZeroDivisionError': , 'eval': , '__debug__': True, 'IndentationError': , 'AssertionError': , 'classmethod': , 'UnboundLocalError': , 'NotImplementedError': , 'AttributeError': , 'OverflowError': }, '__file__': '/temp/python/py3k/Lib/test/test_builtin.py', 'BuiltinTest': , 'TestFailingBool': , 'sys': , 'test': , '__name__': 'test.test_builtin', 'unlink': , 'TESTFN': '@test', 'TestSorted': , 'BitBucket': , 'fcmp': } During handling of the above exception, another exception occurred: Traceback (most recent call last): File "Lib/test/regrtest.py", line 1197, in main() File "Lib/test/regrtest.py", line 411, in main testdir, huntrleaks) File "Lib/test/regrtest.py", line 570, in runtest testdir, huntrleaks) File "Lib/test/regrtest.py", line 623, in runtest_inner print("test", test, "failed --", msg) File "/temp/python/py3k/Lib/io.py", line 1459, in write b = encoder.encode(s) File "/temp/python/py3k/Lib/encodings/ascii.py", line 22, in encode return codecs.ascii_encode(input, self.errors)[0] UnicodeEncodeError: 'ascii' codec can't encode characters in position 697-699: ordinal not in range(128) ---------- messages: 70374 nosy: benjamin.peterson priority: critical severity: normal status: open title: test_builtin fails after test_decimal versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 04:29:34 2008 From: report at bugs.python.org (mvngu) Date: Tue, 29 Jul 2008 02:29:34 +0000 Subject: [New-bugs-announce] [issue3463] make life.py use more rendering characters In-Reply-To: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za> Message-ID: <1217298574.14.0.239193777363.issue3463@psf.upfronthosting.co.za> New submission from mvngu : Allows life.py to use other characters for rendering (alphanumeric plus punctuation characters), apart from the default asterisk "*". The rendering character can be specified from the command line. ---------- components: Demos and Tools files: life.py.diff keywords: patch messages: 70375 nosy: mvngu severity: normal status: open title: make life.py use more rendering characters type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11001/life.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 08:49:56 2008 From: report at bugs.python.org (nandhakumar) Date: Tue, 29 Jul 2008 06:49:56 +0000 Subject: [New-bugs-announce] [issue3464] Python & NCURSES In-Reply-To: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za> Message-ID: <1217314196.04.0.889704905921.issue3464@psf.upfronthosting.co.za> New submission from nandhakumar : i have installed python 2.4 and ncurses 5.4 in my linux server. Python script is working fine but when i tried using thread function in my script(which also uses ncurses) it gives the following error: Traceback (most recent call last): File "xxxx.py", line 199, in ? curses.wrapper(AnDoRun) File "/usr/local/lib/python2.4/curses/wrapper.py", line 44, in wrapper return func(stdscr, *args, **kwds) File "xxxx.py", line 182, in AnDoRun ando.start() File "xxxx.py", line 136, in start self.proxyManagerThread.start() File "/usr/local/lib/python2.4/threading.py", line 416, in start _start_new_thread(self.__bootstrap, ()) thread.error: can't start new thread help me how can i solve this problem ASAP ---------- components: None messages: 70377 nosy: nandha severity: normal status: open title: Python & NCURSES type: compile error versions: Python 2.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 11:24:53 2008 From: report at bugs.python.org (Piotr Wysocki) Date: Tue, 29 Jul 2008 09:24:53 +0000 Subject: [New-bugs-announce] [issue3465] doctest unable to use '...' for unicode literals In-Reply-To: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za> Message-ID: <1217323493.76.0.249081508484.issue3465@psf.upfronthosting.co.za> New submission from Piotr Wysocki : Might be related to 2811 ---------- components: Library (Lib) files: doctest_problem.py messages: 70382 nosy: wysek severity: normal status: open title: doctest unable to use '...' for unicode literals versions: Python 2.5 Added file: http://bugs.python.org/file11002/doctest_problem.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 16:53:35 2008 From: report at bugs.python.org (=?utf-8?q?Marcelo_Fern=C3=A1ndez?=) Date: Tue, 29 Jul 2008 14:53:35 +0000 Subject: [New-bugs-announce] [issue3466] urllib2 should support HTTPS connections with client keys In-Reply-To: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za> Message-ID: <1217343215.63.0.226404809794.issue3466@psf.upfronthosting.co.za> New submission from Marcelo Fern?ndez : Despite httplib does have support for HTTPS with client keys[1], urllib2 should support them too, because of the added value that urllib2 has, like cookielib automatic handling. [1]: http://code.activestate.com/recipes/117004/ However, I made a workaround: #-*- coding: utf-8 -*- import httplib import urllib2 key_file = None cert_file = None class HTTPSClientAuthConnection(httplib.HTTPSConnection): def __init__(self, host): httplib.HTTPSConnection.__init__(self, host, key_file=key_file, cert_file=cert_file) class HTTPSClientAuthHandler(urllib2.HTTPSHandler): def https_open(self, req): return self.do_open(HTTPSClientAuthConnection, req) Regards, Marcelo ---------- components: Library (Lib) messages: 70397 nosy: marcelo_fernandez severity: normal status: open title: urllib2 should support HTTPS connections with client keys type: feature request _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 29 22:42:59 2008 From: report at bugs.python.org (Eric L. Frederich) Date: Tue, 29 Jul 2008 20:42:59 +0000 Subject: [New-bugs-announce] [issue3467] sqlite3 path is hard coded in setup.py In-Reply-To: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za> Message-ID: <1217364179.14.0.826018983626.issue3467@psf.upfronthosting.co.za> New submission from Eric L. Frederich : In setup.py, the paths that it searches for sqlite in is hard coded in a list sqlite_inc_paths. This should also search any path in either $PATH or $LD_LIBRARY_PATH. This is necessary for non-default installations of sqlite for users without root access, or for those with root access that have multiple versions installed in different locations. ---------- components: Installation messages: 70411 nosy: ericfrederich severity: normal status: open title: sqlite3 path is hard coded in setup.py type: compile error versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 30 02:43:27 2008 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 30 Jul 2008 00:43:27 +0000 Subject: [New-bugs-announce] [issue3468] Satisfy her lovemaking desire In-Reply-To: <94BD5636.5B0F346F@aaiworldmarket.com> Message-ID: <94BD5636.5B0F346F@aaiworldmarket.com> New submission from Guido van Rossum : Give your lady only the very best, find out how here http://www.pinehelp.com/ ---------- messages: 70414 nosy: gvanrossum severity: normal status: open title: Satisfy her lovemaking desire _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 30 10:30:43 2008 From: report at bugs.python.org (=?utf-8?q?Berthold_H=C3=B6llmann?=) Date: Wed, 30 Jul 2008 08:30:43 +0000 Subject: [New-bugs-announce] [issue3469] Umlauts make conf.latex_documents fail In-Reply-To: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za> Message-ID: <1217406643.63.0.573094659018.issue3469@psf.upfronthosting.co.za> New submission from Berthold H?llmann : For a Project of mine I have set latex_documents to something like latex_documents = [ ('index', 'doc.tex', 'Documentation', 'Berthold H?llmann', 'manual'), ] With this processing fails with: LANG=C make latex mkdir -p build/latex build/doctrees sphinx-build -b latex -d build/doctrees -D latex_paper_size=a4 -N source build/latex Sphinx v0.4.2, building latex trying to load pickled env... done building [latex]: all documents updating environment: 0 added, 1 changed, 0 removed reading... index pickling the env... done checking consistency... processing CrossSolverTests.tex... index resolving references... writing... Exception occurred: File "/usr/software/gltools/python/Python-2.5/lib/python2.5/site-packages/Sphinx-0.4.2-py2.5.egg/sphinx/latexwriter.py", line 162, in astext '\\renewcommand{\\indexname}{Index}\n' or '') + \ UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 206: ordinal not in range(128) The full traceback has been saved in /tmp/sphinx-err-l_u8H4.log, if you want to report the issue to the author. Please also report this if it was a user error, so that a better error message can be provided next time. Send reports to sphinx-dev at googlegroups.com. Thanks! make: *** [latex] Error 1 changing ? to \"o does work. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) files: sphinx-err-l_u8H4.log messages: 70419 nosy: georg.brandl, hoel severity: normal status: open title: Umlauts make conf.latex_documents fail type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file11006/sphinx-err-l_u8H4.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 30 12:43:26 2008 From: report at bugs.python.org (Fredrik Johansson) Date: Wed, 30 Jul 2008 10:43:26 +0000 Subject: [New-bugs-announce] [issue3470] Wrong name for getrandbits in docstring and documentation In-Reply-To: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za> Message-ID: <1217414606.28.0.183215077466.issue3470@psf.upfronthosting.co.za> New submission from Fredrik Johansson : The docstring for random.Random mentions a method getrandombits(). Surely this should be getrandbits()? This ghost method is also mentioned in the Library Reference page for the random module. ---------- assignee: georg.brandl components: Documentation, Library (Lib) messages: 70421 nosy: fredrikj, georg.brandl severity: normal status: open title: Wrong name for getrandbits in docstring and documentation versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 30 18:38:34 2008 From: report at bugs.python.org (Armin Rigo) Date: Wed, 30 Jul 2008 16:38:34 +0000 Subject: [New-bugs-announce] [issue3471] PyObject_GetAttr() to get special methods In-Reply-To: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za> Message-ID: <1217435914.82.0.412658814842.issue3471@psf.upfronthosting.co.za> New submission from Armin Rigo : There is a bunch of obscure behavior caused by the use of PyObject_GetAttr() to get special method from objects. This is wrong because special methods should only be looked up in object types, not on the objects themselves (i.e. with PyType_Lookup()). Here is one example caused by the PyObject_GetAttr() found in PyObject_IsInstance(): import abc >>> isinstance(5, abc.ABCMeta) Traceback (most recent call last): File "", line 1, in RuntimeError: maximum recursion depth exceeded while calling a Python object This occurs because it ends up trying to call the unbound method abc.ABCMeta.__instancecheck__(5). But this first requires checking if "5" is indeed an instance of abc.ABCMeta... cycle. Obviously this is just an example; all PyObject_GetAttr() would potentially need to be reviewed. ---------- messages: 70431 nosy: arigo severity: normal status: open title: PyObject_GetAttr() to get special methods _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 30 21:42:24 2008 From: report at bugs.python.org (Jeff Rodman) Date: Wed, 30 Jul 2008 19:42:24 +0000 Subject: [New-bugs-announce] [issue3472] Updates to "Macintosh Library Modules" Section 1.1 In-Reply-To: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za> Message-ID: <1217446944.11.0.813308740394.issue3472@psf.upfronthosting.co.za> New submission from Jeff Rodman : Change current introduction in 1.1 WAS: Mac OS X 10.4 comes with Python 2.3 pre-installed by Apple. However, you are encouraged to install the most recent version of Python from the Python website (http://www.python.org). A ``universal binary'' build of Python 2.5, which runs natively on the Mac's new Intel and legacy PPC CPU's, is available there. IS: Mac OS X 10.5 comes with Python 2.5.1 pre-installed by Apple. If you wish, you are invited to install the most recent version (currently 2.5.2) of Python from the Python website (http://www.python.org). A current "universal binary'' build of Python, which runs natively on the Mac's new Intel and legacy PPC CPU's, is available there. And then, to line: The Apple-provided build of Python is installed in /System/Library/Frameworks/Python.framework and /usr/bin/python, respectively. You should never modify or delete these, as they are Apple-controlled and are used by Apple- or third-party software. ADD: Remember that if you choose to install a newer Python version like this, you will have two different but functional Python installations on your computer, so it will be important that your paths and usages are consistent with what you want to do. ---------- assignee: georg.brandl components: Documentation messages: 70437 nosy: georg.brandl, jrodman severity: normal status: open title: Updates to "Macintosh Library Modules" Section 1.1 versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 03:16:31 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jul 2008 01:16:31 +0000 Subject: [New-bugs-announce] [issue3473] In function call, keyword arguments could follow *args In-Reply-To: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za> Message-ID: <1217466991.08.0.845897736513.issue3473@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : functions with keyword-only arguments have this form: def f(x, *args, y): pass parameters can appear after the *arg, they are required to be passed by keyword. It would be more consistent to allow this function call: f(X, *ARGS, y=Y) This is invalid syntax, *ARGS is required to be at the end of the arguments, together with an eventual **KWARGS. This restriction should be lifted. See the use case in http://mail.python.org/pipermail/python-3000/2008-July/014437.html ---------- assignee: amaury.forgeotdarc messages: 70449 nosy: amaury.forgeotdarc severity: normal status: open title: In function call, keyword arguments could follow *args versions: Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 05:40:55 2008 From: report at bugs.python.org (Brett Cannon) Date: Thu, 31 Jul 2008 03:40:55 +0000 Subject: [New-bugs-announce] [issue3474] Using functools.reduce() does not stop DeprecationWarning when using -3 In-Reply-To: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za> Message-ID: <1217475655.54.0.410069385822.issue3474@psf.upfronthosting.co.za> New submission from Brett Cannon : It turns out that functools.reduce() is simply __builtins__.reduce(). That does not stop the DeprecationWarning from using reduce() from being raised even though the message says to use functools.reduce()! Easiest solution is to create a wrapper for __builtin__.reduce() that silences the warning when called. ---------- assignee: brett.cannon components: Library (Lib) messages: 70484 nosy: brett.cannon priority: critical severity: normal status: open title: Using functools.reduce() does not stop DeprecationWarning when using -3 type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 09:13:10 2008 From: report at bugs.python.org (Matteo Bertini) Date: Thu, 31 Jul 2008 07:13:10 +0000 Subject: [New-bugs-announce] [issue3475] _elementtree.c import can fail silently In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za> Message-ID: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za> New submission from Matteo Bertini : Playing with PyInstaller I have found that the final part of _elementtree.c: Index: Modules/_elementtree.c =================================================================== --- Modules/_elementtree.c (revisione 59540) +++ Modules/_elementtree.c (copia locale) @@ -2780,7 +2780,10 @@ ); - PyRun_String(bootstrap, Py_file_input, g, NULL); + if (PyRun_String(bootstrap, Py_file_input, g, NULL) == NULL) + return; elementpath_obj = PyDict_GetItemString(g, "ElementPath"); execute a bit of python code without checking the return value. That can lead to weird things playing with import hooks, for example an assert like this can fail: Index: Lib/test/test_elemettree.py =================================================================== --- Lib/test/test_elemettree.py (revisione 0) +++ Lib/test/test_elemettree.py (revisione 0) @@ -0,0 +1,21 @@ +#! /usr/bin/env python + +def importHook(*args, **kwargs): + if 'xml.etree' in args: + raise ImportError + else: + return __real__import__(*args, **kwargs) + +import os +import __builtin__ +__real__import__ = __builtin__.__import__ +__builtin__.__import__ = importHook + +try: + import xml.etree.cElementTree as cET +except ImportError: + pass +else: + out = os.popen("python -c 'import xml.etree.cElementTree as cET; print dir(cET)'").read().strip() + assert str(dir(cET)) == out, (str(dir(cET)), out) + ---------- components: XML messages: 70488 nosy: naufraghi severity: normal status: open title: _elementtree.c import can fail silently versions: Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 11:03:12 2008 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 31 Jul 2008 09:03:12 +0000 Subject: [New-bugs-announce] [issue3476] BufferedWriter not thread-safe In-Reply-To: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za> Message-ID: <1217494992.05.0.604288591509.issue3476@psf.upfronthosting.co.za> New submission from Antoine Pitrou : As discovered in #3139, io.BufferedWriter mutates the size of its internal bytearray object. Consequently, invocations of write() from multiple threads can produce exceptions when one thread gets a buffer to the bytearray while the other thread tries to resize it. This especially affects calling print() from multiple threads. A solution is to use a fixed-size (preallocated) bytearray object. Another solution is to get rid of the bytearray approach and replace it with a growing list of immutable bytes objects. Here is the test script provided by Amaury: import sys, io, threading stdout2 = io.open(sys.stdout.fileno(), mode="w") def f(i): for i in range(10): stdout2.write(unicode((x, i)) + '\n') for x in range(10): t = threading.Thread(target=f, args=(x,)) t.start() (with py3k, replace "stdout2.write" with a simple "print") ---------- components: Library (Lib) messages: 70494 nosy: amaury.forgeotdarc, pitrou priority: high severity: normal status: open title: BufferedWriter not thread-safe type: behavior versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 13:37:55 2008 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 31 Jul 2008 11:37:55 +0000 Subject: [New-bugs-announce] [issue3477] grammar productionlist are not properly indented In-Reply-To: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za> Message-ID: <1217504275.9.0.818427276788.issue3477@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc : See http://docs.python.org/dev/reference/expressions.html#id9 the production rule for "argument_list" is not properly indented. It seems that the first line is indented up to the widest name of the list, but subsequent lines only add 6 to the length of the defined name. ---------- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 70498 nosy: amaury.forgeotdarc, georg.brandl severity: normal status: open title: grammar productionlist are not properly indented versions: Python 2.6, Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 16:26:31 2008 From: report at bugs.python.org (Matt Giuca) Date: Thu, 31 Jul 2008 14:26:31 +0000 Subject: [New-bugs-announce] [issue3478] Documentation for struct module is out of date in 3.0 In-Reply-To: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za> Message-ID: <1217514391.83.0.200271369945.issue3478@psf.upfronthosting.co.za> New submission from Matt Giuca : The documentation for the "struct" module still uses the term "string" even though the struct module itself deals entirely in bytes objects in Python 3.0. I propose updating the documentation to reflect the 3.0 terminology. I've attached a patch for the Docs/library/struct.rst file. It mostly renames "string" to "bytes". It also notes that pack for 'c', 's' and 'p' accepts either string or bytes, but unpack spits out a bytes. One important point: If you pass a str to 'c', 's' or 'p', it will get encoded with UTF-8 before being packed. I've described this behaviour in the documentation. I'm not sure if this should be described as the "official" behaviour, or just informatively. I've traced this behaviour to Modules/_struct.c lines 607, 1650 and 1676 (for 'c', 's' and 'p' respectively), which calls _PyUnicode_AsDefaultEncodedString. This is found in Object/unicodeobject.c:1410, which directly calls PyUnicode_EncodeUTF8. Hence the UTF-8 encoding is not system or locale specific - it will always happen. However, perhaps we should loosen the documentation to say "which are encoded using a default encoding scheme". It would be good if the authors of the struct module read over these changes first, to make sure I am describing it correctly. I have also updated Modules/_struct.c's doc strings and exception messages to reflect this new terminology. (I've changed nothing besides the contents of these strings - test case passes, just to be safe). Patch is for /python/branches/py3k/, revision 65324. Commit Log: Docs/library/struct.rst: Updated documentation to Python 3.0 terminology (bytes instead of strings). Added note that packing 'c', 's' or 'p' accepts either str or bytes. Modules/_struct.c: Updated doc strings and exception messages to the same. ---------- assignee: georg.brandl components: Documentation files: struct-doc.patch keywords: patch messages: 70506 nosy: georg.brandl, mgiuca severity: normal status: open title: Documentation for struct module is out of date in 3.0 versions: Python 3.0 Added file: http://bugs.python.org/file11013/struct-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 16:53:45 2008 From: report at bugs.python.org (Ralf Schmitt) Date: Thu, 31 Jul 2008 14:53:45 +0000 Subject: [New-bugs-announce] [issue3479] unichr integer overflow In-Reply-To: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za> Message-ID: <1217516025.33.0.943431479482.issue3479@psf.upfronthosting.co.za> New submission from Ralf Schmitt : unichr(2**32) results in a unicode string containing a 0 byte: {{{ ~/mwlib.hg/tests/ python Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unichr(2**32) u'\x00' >>> unichr(2**32+1) u'\x01' >>> unichr(2**32+2) u'\x02' }}} 2.6 shows the same behaviour. ---------- components: Unicode messages: 70513 nosy: schmir severity: normal status: open title: unichr integer overflow type: behavior versions: Python 2.5, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 31 22:00:05 2008 From: report at bugs.python.org (Nick Edds) Date: Thu, 31 Jul 2008 20:00:05 +0000 Subject: [New-bugs-announce] [issue3480] Fix_imports pattern optimization In-Reply-To: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za> Message-ID: <1217534405.3.0.224427460631.issue3480@psf.upfronthosting.co.za> New submission from Nick Edds : Here is a substantial improvement to the pattern for fix_imports. It significantly reduces the size of the previous pattern and represents it in a more reasonable way. It still passes all of the tests and it also makes 2to3 roughly two to three times as fast based on the results of some basic testing. ---------- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: fix_imports_pattern.diff keywords: patch messages: 70528 nosy: collinwinter, nedds severity: normal status: open title: Fix_imports pattern optimization type: performance Added file: http://bugs.python.org/file11019/fix_imports_pattern.diff _______________________________________ Python tracker _______________________________________