From noreply at sourceforge.net Wed Dec 1 00:03:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 00:03:12 2004 Subject: [ python-Bugs-1076365 ] Whats New for 2.4 "SafeTemplate" patch. Message-ID: Bugs item #1076365, was opened at 2004-11-30 23:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076365&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Whats New for 2.4 "SafeTemplate" patch. Initial Comment: Feel free to assign this back to me if you'd like, I can apply it if it's kosher. The "What's New in 2.4" document shows a demonstration with "SafeTemplate()" used. It should be "Template()", but using the "safe_substitute" method. The text and example are correct except for the use of SafeTemplate instead of Template. Also, I added my name to the string.rsplit() description as the contributor. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076365&group_id=5470 From noreply at sourceforge.net Wed Dec 1 00:45:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 00:45:11 2004 Subject: [ python-Bugs-1076365 ] Whats New for 2.4 "SafeTemplate" patch. Message-ID: Bugs item #1076365, was opened at 2004-11-30 18:03 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076365&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) >Assigned to: A.M. Kuchling (akuchling) Summary: Whats New for 2.4 "SafeTemplate" patch. Initial Comment: Feel free to assign this back to me if you'd like, I can apply it if it's kosher. The "What's New in 2.4" document shows a demonstration with "SafeTemplate()" used. It should be "Template()", but using the "safe_substitute" method. The text and example are correct except for the use of SafeTemplate instead of Template. Also, I added my name to the string.rsplit() description as the contributor. Sean ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-30 18:45 Message: Logged In: YES user_id=12800 Also, Template does not inherit from unicode (it once did, but that was changed). You might also want to add that getservbyport() was added to the socket module. Also, its second argument and that of getservbyname() were made optional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076365&group_id=5470 From noreply at sourceforge.net Wed Dec 1 00:57:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 00:57:19 2004 Subject: [ python-Bugs-1072259 ] re module segfaulting in large regular expression Message-ID: Bugs item #1072259, was opened at 2004-11-23 22:38 Message generated for change (Comment added) made by edemaine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072259&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: re module segfaulting in large regular expression Initial Comment: The attached code worked fine in Python 2.3 and prior, but broke in a recent version of Python 2.4 (I think between the alpha and beta, but I'm not sure). It now causes a Segmentation fault, at least on my Linux boxes (2.4.18 and 2.4.22). For those not looking at the attachment, the code is essentially: import re re.match (...big regular expression..., 'December 20, 1997', re.IGNORECASE) The code works if the re.IGNORECASE flag is omitted. I hope I'm not doing anything stupid in installation... I tried both CVS head and 2.4c1, both with-pyalloc and without-pyalloc. ---------------------------------------------------------------------- >Comment By: Erik Demaine (edemaine) Date: 2004-11-30 18:57 Message: Logged In: YES user_id=265183 FYI, this bug remains in 2.4final, which is a shame to me (but probably just a timing mishap), as it makes 2.4 unusable to me. However, the exact version I attached before does seem to work on on 2.4final on WindowsXP, but still not on Linux. Attached is a version that still fails on 2.4final on all systems I've tried. The only difference is using re.compile(...).match instead of re.match. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-23 22:40 Message: Logged In: YES user_id=265183 An update: The same code crashes (general protection fault) on a vanilla install of 2.4c1 on Windows XP using the MSI installer. So I don't think it's my installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072259&group_id=5470 From noreply at sourceforge.net Wed Dec 1 03:08:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 03:08:56 2004 Subject: [ python-Bugs-569316 ] cgi.py broken with xmlrpclib on Python 2 Message-ID: Bugs item #569316, was opened at 2002-06-15 05:53 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Steve Pike (oztourer) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py broken with xmlrpclib on Python 2 Initial Comment: Given a web application which accepts both normal HTTP requests and XML-RPC requests, it is reasonable for that program to assume it can create a cgi.FieldStorage instance in either case. This works fine in Python 1.5.2 but causes exceptions in Python 2.x.x when using the created FieldStorage. This is due to the content-type header generated by xmlrpclib.py ('text/xml') being unrecognised in cgi.py, as a result of which no FieldStorage.list is created. One solution is to reinstate some code in cgi.py from the 1.5.2 release, at the end of method __init__, after removing the current final two lines: #else: # self.read_single() # SP 2002/6/15: The following code is taken from the Python 1.5.2 version # of cgi.py, as incoming xmlrpclib requests otherwise do not cause 'list' # to be set up correctly. elif self.outerboundary: # we're in an inner part, but the content-type wasn't something we # understood. default to read_single() because the resulting # FieldStorage won't be a mapping (and doesn't need to be). self.read_single() else: # we're in an outer part, but the content-type wasn't something we # understood. we still want the resulting FieldStorage to be a # mapping, so parse it as if it were urlencoded self.read_urlencoded() ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:08 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=569316&group_id=5470 From noreply at sourceforge.net Wed Dec 1 03:13:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 03:13:27 2004 Subject: [ python-Bugs-591104 ] os.tmpfile() can fail on win32 Message-ID: Bugs item #591104, was opened at 2002-08-05 11:23 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Joseph Barillari (jdbarillari) Assigned to: Mark Hammond (mhammond) Summary: os.tmpfile() can fail on win32 Initial Comment: I've discovered what appears to be a bug in Python 2.2.1 on Win32. I'm using the 2.2.1 build that I downloaded from python.org. I'm running Windows 2000. If os.tmpfile() is exceuted when the CWD is a UNC path, the base of which is not writeable by the current user, tmpfile will fail. tempfile.TemporaryFile will work, so I suspect this is a bug in os.tmpfile(). For example: C:\>pwd /cygdrive/c #I use cygwin C:\>bash # I have to use bash; the DOS shell doesn't support UNC paths bash: .bashrc: No such file or directory bash-2.05a$ cd //bopp/jbarilla bash-2.05a$ pwd //bopp/jbarilla bash-2.05a$ python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.tmpfile() <open file '<tmpfile>', mode 'w+' at 0x007762C0> # It works. >>> ^Z If I chmod 555 //bopp/jbarilla (from unix via NFS; incidentally, "chmod 555 ." from cygwin is ineffectual), then tmpfile fails: bash-2.05a$ pwd //bopp/jbarilla bash-2.05a$ python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.tmpfile() Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 13] Permission denied # Oops. # However, tempfile.TemporaryFile works: >>> import tempfile; tempfile.TemporaryFile() <open file 'c:\DOCUME~1\jbarilla\LOCALS~1 \Temp\~1880-0', mode 'w+b' at 0x00779B00> --Joe ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:13 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Jonathan Simms (slyphon) Date: 2002-08-10 03:21 Message: Logged In: YES user_id=404786 Hi, I'm a bit new here, but I'd like to help... This like a cygwin issue. I've been using cygwin as a development environment for about a year, and nothing has driven me more crazy than the consistent problems converting between unc and win32 paths. There's the cygpath utility that you can put to use, it'll convert posix to win32 paths and vice-versa. Also, if you want to use chmod and unix-style permissions with cygwin, you need to make sure that the $CYGWIN variable has been set to include 'ntsec'. related to the cygwin environment variable: http://cygwin.com/cygwin-ug-net/using-cygwinenv.html ...This advice comes with no warranty, and I apologise if I'm mistakenly off-the-mark... Cheers --Jonathan ---------------------------------------------------------------------- Comment By: Joseph Barillari (jdbarillari) Date: 2002-08-06 11:40 Message: Logged In: YES user_id=589825 \quote{BTW, do you really think this has something to do with UNC paths? From what you said it seems to be a matter of having sufficient permission to scribble in the current directory.} Oops. You're right: Z:\>touch a touch: creating `a': Permission denied Z:\>python Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os; os.tmpfile() Traceback (most recent call last): File "<stdin>", line 1, in ? OSError: [Errno 13] Permission denied >>> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-06 00:19 Message: Logged In: YES user_id=31435 Assigned to Mark in case he has another idea, but I think you're out of luck. os.tmpfile() does nothing except call Microsoft's tmpfile() function, and that doesn't allow specifying a directory. If you don't have permission to create a file in the current directory, you lose, and Python's behavior here will change when Microsoft's does. tempfile.TemporaryFile() "simulates" a temp file via other means, and can control which directory it uses. BTW, do you really think this has something to do with UNC paths? From what you said it seems to be a matter of having sufficient permission to scribble in the current directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591104&group_id=5470 From noreply at sourceforge.net Wed Dec 1 03:11:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 03:17:41 2004 Subject: [ python-Bugs-579116 ] pthread_exit missing in thread_pthread.h Message-ID: Bugs item #579116, was opened at 2002-07-09 10:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 Category: Threads Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Michael Pronath (micpro) Assigned to: Nobody/Anonymous (nobody) Summary: pthread_exit missing in thread_pthread.h Initial Comment: I'm using the Python 2.2.1 interpreter for scripting language in a larger program. When I used the threading module to create new threads, my main program did not exit anymore, but hang, because one python thread always remained. It got much better when I inserted a call to pthread_exit into do_PyThread_exit_thread (thread_pthread.h). Patchfile is attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:11 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Valeriy Pogrebitskiy (vpogrebi) Date: 2003-11-06 11:55 Message: Logged In: YES user_id=902722 I'm using Python 2.2.1 (Unix) in a daemon process that starts child threads to handle specific events. I have noticed that occasionally (not all the time) child thread "stays" (in a SLEEPING) status after thread exits. When this happens, that thread never exits until entire process is stopped. I have log files that have output coming from threading module (I have set threading._VERBOSE to 1) that show each thread's start and termination events. In addition, I use Queue module for inter-thread communication (when thread starts execution, it posts "START" message, and when it is about to exit its run() method, it posts "END" event). So, from these logs and from output of "ps -fp <PID> - o 'user,pid,ppid,pgid,time,stime,lwp,s'" I can see that some threads exit (which is indicated by _VERBOSE output and a message in a Queue), but still stay (in a SLEEPING state) in the process. Does this behavior have something to do with the problem described in this report, or is it something different? Is there patch (full instalation package) that fixes this problem (without me having to update source code and recompile the executable)? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 22:08 Message: Logged In: YES user_id=33168 Michael do you still have this problem with 2.2.2 or do you still require this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 From noreply at sourceforge.net Wed Dec 1 03:18:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 03:18:42 2004 Subject: [ python-Bugs-591287 ] makesetup fails: long Setup.local lines Message-ID: Bugs item #591287, was opened at 2002-08-05 17:25 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470 Category: Build Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Sam Tannous (stannous) Assigned to: Nobody/Anonymous (nobody) Summary: makesetup fails: long Setup.local lines Initial Comment: makesetup fails: long Setup.local lines. I've included an attachment that describes the problem. Thanks, Sam Tannous (employees.org) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:18 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 11:29 Message: Logged In: YES user_id=11375 It's not length; it's the '=' symbol. Modules/makesetup compares the line to '*=*', and if it matches, assumes it's a definition, like 'DESTLIB=foo'. That also matches your -DBYTE_ORDER=1234, though, so makesetup just copies the line verbatim into the definition section. I don't see how to fix it, though; shell pattern matching doesn't seem powerful enough to do something like [^ ]*=*. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591287&group_id=5470 From noreply at sourceforge.net Wed Dec 1 03:20:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 03:20:09 2004 Subject: [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8 Message-ID: Bugs item #602627, was opened at 2002-08-30 17:51 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, locals=0x0, args=0x30fd50, argcount=2, kws=0x30fd58, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #13 0x00049f20 in fast_function (func=0x0, pp_stack=0x30fd50, n=3210584, na=2, nk=0) at Python/ceval.c:3161 #14 0x00047de0 in eval_frame (f=0x30fc00) at Python/ceval.c:2024 #15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788, globals=0x30fc00, locals=0x0, args=0x1c0bc8, argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #16 0x00049f20 in fast_function (func=0x0, pp_stack=0x1c0bc8, n=1838028, na=1, nk=0) at Python/ceval.c:3161 #17 0x00047de0 in eval_frame (f=0x1c0a70) at Python/ceval.c:2024 #18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058, globals=0x1c0a70, locals=0x0, args=0x301a6c, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #19 0x000aaa9c in function_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/funcobject.c:374 #20 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #21 0x0009e644 in instancemethod_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/classobject.c:2276 #22 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #23 0x00049fe4 in do_call (func=0x2c5718, pp_stack=0xfe908fd8, na=3, nk=3152480) at Python/ceval.c:3262 #24 0x00047d28 in eval_frame (f=0x1cc5f8) at Python/ceval.c:2027 #25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398, globals=0x1cc5f8, locals=0x0, args=0x2cba54, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #26 0x000aaa9c in function_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374 #27 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684 #28 0x0009e644 in instancemethod_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/classobject.c:2276 #29 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #30 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Python/ceval.c:3049 #31 0x00097d9c in PyInstance_New (klass=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557 #32 0x00095d00 in PyObject_Call (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #33 0x00049fe4 in do_call (func=0x316828, pp_stack=0xfe9094a0, na=2, nk=3029936) at Python/ceval.c:3262 #34 0x00047d28 in eval_frame (f=0x1a3d20) at Python/ceval.c:2027 #35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0, globals=0x1a3d20, locals=0x0, args=0x186414, argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c, defcount=2, closure=0x0) at Python/ceval.c:2585 #36 0x000aaa9c in function_call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/funcobject.c:374 #37 0x00095d00 in PyObject_Call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/abstract.c:1684 #38 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Python/ceval.c:3049 #39 0x000bcb3c in builtin_apply (self=0x0, args=0x1d1dc8) at Python/bltinmodule.c:95 #40 0x000ba398 in PyCFunction_Call (func=0x101d18, arg=0x1c4910, kw=0x0) at Objects/methodobject.c:69 #41 0x00047ec8 in eval_frame (f=0x1a4078) at Python/ceval.c:2004 #42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8, globals=0x1a4078, locals=0x0, args=0x1612d4, argcount=1, kws=0x1612d8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #43 0x00049f20 in fast_function (func=0x0, pp_stack=0x1612d4, n=1446616, na=1, nk=0) at Python/ceval.c:3161 #44 0x00047de0 in eval_frame (f=0x161180) at Python/ceval.c:2024 #45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0, globals=0x161180, locals=0x0, args=0x265e4c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #46 0x000aaa9c in function_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/funcobject.c:374 #47 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/abstract.c:1684 #48 0x0009e644 in instancemethod_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/classobject.c:2276 #49 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x100368, kw=0x0) at Objects/abstract.c:1684 #50 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2d7350, arg=0x100368, kw=0x0) at Python/ceval.c:3049 #51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at Modules/threadmodule.c:190 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-30 23:20 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 23:17 Message: Logged In: YES user_id=33168 I notice that you are using Tk 8.4. Have you (or can you) tried with Tk 8.3? Do you have the most recent version 8.4.1 from Oct 22, 2002? ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 14:10 Message: Logged In: YES user_id=418174 I rebuilt python with -O0 and it still crashes. The new traceback is attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 10:46 Message: Logged In: YES user_id=33168 Andrew, could I get you to look at bug 662787? http://python.org/sf/662787 We are having problems with solaris boxes and could use some help. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-17 11:54 Message: Logged In: YES user_id=418174 I rebuilt python from scratch by saying "make configure", then going into Makefile and removing "-O3" from the definition of the OPT macro, then saying "make". The resulting python still dumps core when executing "./python Lib/pydoc.py -g". Of course there could still be a platform or optimization dependency in tcl, or tk, or some other library. Suggestions? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 22:30 Message: Logged In: YES user_id=33168 I built python 2.2.1+ w/gcc 2.95.3 and did not have the problem. So I think this may be specific to gcc 3.2. Can you try building w/lower optimization or turning off optimization? -O1, -O0 or no -O option? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 From noreply at sourceforge.net Wed Dec 1 03:45:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 03:45:42 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-11-30 20:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Wed Dec 1 04:32:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 04:32:11 2004 Subject: [ python-Feature Requests-1076478 ] Python Interpreter embedded in small memory system Message-ID: Feature Requests item #1076478, was opened at 2004-12-01 03:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1076478&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: stoneabcwujx (stoneabcwujx) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter embedded in small memory system Initial Comment: I'm a newcomer in python. I want to know how large is the size of python interpreter . If I only need some basic funcitons of python(module import,string operation,math operation,etc), not including such as 'tk' or 'multithreading'. How small could the python interpreter's size to be? Is it only a dream to embed such a small interpreter onto a system which only has 128KB memory? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1076478&group_id=5470 From noreply at sourceforge.net Wed Dec 1 04:32:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 04:32:46 2004 Subject: [ python-Bugs-853862 ] 'Demo/embed/' , It crash Message-ID: Bugs item #853862, was opened at 2003-12-04 06:59 Message generated for change (Settings changed) made by guanzijing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853862&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Nobody/Anonymous (nobody) Summary: 'Demo/embed/' , It crash Initial Comment: When I try to run the demo under 'Demo/embed/' , It crash, It's something wrong about my Make step? ========================================== ========== xy2.163.com embed$uname -a FreeBSD xy2.163.com 4.8-RELEASE-p5 FreeBSD 4.8- RELEASE-p5 #0: Thu Sep 25 11:42:40 CST 2003 root@xy2.163.com:/usr/home/root/src/sys/compile/DH2G AME_KERNEL i386 ========================================== =========== xy2.163.com embed$python Python 2.3.2 (#1, Dec 4 2003, 13:18:10) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import distutils.sysconfig >>> distutils.sysconfig.get_config_var('LINKFORSHARED') '-Wl,--export-dynamic' >>> ========================================== ========== xy2.163.com embed$gmake demo gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict- prototypes -fno-strict-aliasing -I../../Include -I../.. -c - o demo.o demo.c gcc -Wl,--export-dynamic demo.o ../../libpython2.3.a - lreadline -ltermcap -pthread -lutil -lc -lm -o demo ../../libpython2.3.a(posixmodule.o): In function `posix_tmpnam': /home/kyo/work/Python-2.3.2/./Modules/posixmodule.c (.text+0x3c8b): warning: tmpnam() possibly used unsafely; consider using mkstemp() ../../libpython2.3.a(posixmodule.o): In function `posix_tempnam': /home/kyo/work/Python-2.3.2/./Modules/posixmodule.c (.text+0x3bee): warning: tempnam() possibly used unsafely; consider using mkstemp() /usr/lib/libc_r.so: WARNING! setkey(3) not present in the system! /usr/lib/libc_r.so: warning: this program uses gets(), which is unsafe. /usr/lib/libc_r.so: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/lib/libc_r.so: WARNING! des_setkey(3) not present in the system! /usr/lib/libc_r.so: WARNING! encrypt(3) not present in the system! /usr/lib/libc_r.so: warning: this program uses f_prealloc (), which is not recommended. /usr/lib/libc_r.so: WARNING! des_cipher(3) not present in the system! xy2.163.com embed$./demo Hello, brave new world ('__builtin__', '__main__', '_codecs', '_sre', '_symtable', 'er rno', 'exceptions', 'gc', 'imp', 'marshal', 'posix', 'signal', 'sys ', 'thread', 'xxsubtype', 'zipimport') ['copy_reg', '__main__', 'cjkcodecs.aliases', 'site', '__builti n__', 'encodings', 'encodings.encodings', 'posixpath', 'enc odings.codecs', 'cjkcodecs', 'os.path', '_codecs', 'encodin gs.exceptions', 'stat', 'zipimport', 'warnings', 'encodings.ty pes', 'UserDict', 'sys', 'cjkcodecs.encodings', 'codecs', 'ty pes', 'xyzzy', 'signal', 'linecache', 'posix', 'encodings.aliase s', 'exceptions', 'encodings.iso8859_1', 'os'] /usr/home/kyo/work/Python-2.3.2/Demo/embed/demo ['./demo'] Goodbye, cruel world Segmentation fault (core dumped) ========================================== =========== xy2.163.com embed$gdb demo demo.core GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown- freebsd"...Deprecated bfd_read called at /usr/home/root/src/gnu/usr.bin/binutils/gdb/../../../../c ontrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/home/root/src/gnu/usr.bin/binutils/gdb/../../../../c ontrib/gdb/gdb/dbxread.c line 933 in fill_symbuf Core was generated by `demo'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libreadline.so.4...done. Reading symbols from /usr/lib/libncurses.so.5...done. Reading symbols from /usr/lib/libutil.so.3...done. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x481fcaa8 in .cerror () from /usr/lib/libc.so.4 (gdb) bt #0 0x481fcaa8 in .cerror () from /usr/lib/libc.so.4 #1 0x4828f927 in _exit () from /usr/lib/libc_r.so.4 #2 0x481fc9a7 in exit () from /usr/lib/libc.so.4 #3 0x80a4b5c in Py_FdIsInteractive (fp=0x0, filename=0xbfbffb08 "&#30245;&#38752;") at Python/pythonrun.c:1547 #4 0x8053d67 in main () #5 0x8053bf6 in _start () (gdb) ========================================== ============== ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853862&group_id=5470 From noreply at sourceforge.net Wed Dec 1 04:47:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 04:48:06 2004 Subject: [ python-Bugs-1072259 ] re module segfaulting in large regular expression Message-ID: Bugs item #1072259, was opened at 2004-11-23 22:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072259&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Erik Demaine (edemaine) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: re module segfaulting in large regular expression Initial Comment: The attached code worked fine in Python 2.3 and prior, but broke in a recent version of Python 2.4 (I think between the alpha and beta, but I'm not sure). It now causes a Segmentation fault, at least on my Linux boxes (2.4.18 and 2.4.22). For those not looking at the attachment, the code is essentially: import re re.match (...big regular expression..., 'December 20, 1997', re.IGNORECASE) The code works if the re.IGNORECASE flag is omitted. I hope I'm not doing anything stupid in installation... I tried both CVS head and 2.4c1, both with-pyalloc and without-pyalloc. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-30 22:47 Message: Logged In: YES user_id=80475 Verified that this segfaults on Py2.4 final but not Py2.3. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-30 18:57 Message: Logged In: YES user_id=265183 FYI, this bug remains in 2.4final, which is a shame to me (but probably just a timing mishap), as it makes 2.4 unusable to me. However, the exact version I attached before does seem to work on on 2.4final on WindowsXP, but still not on Linux. Attached is a version that still fails on 2.4final on all systems I've tried. The only difference is using re.compile(...).match instead of re.match. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-23 22:40 Message: Logged In: YES user_id=265183 An update: The same code crashes (general protection fault) on a vanilla install of 2.4c1 on Windows XP using the MSI installer. So I don't think it's my installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072259&group_id=5470 From noreply at sourceforge.net Wed Dec 1 05:00:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 05:00:34 2004 Subject: [ python-Bugs-1076485 ] Another message that croaks email.FeedParser Message-ID: Bugs item #1076485, was opened at 2004-11-30 22:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076485&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Another message that croaks email.FeedParser Initial Comment: The attached message causes a TypeError exception with the email.FeedParser class that comes with Python 2.4. The traceback I get is: Traceback (most recent call last): File "", line 1, in ? File "/Users/skip/local/lib/python2.4/mailbox.py", line 35, in next return self.factory(_Subfile(self.fp, start, stop)) File "/Users/skip/local/lib/python2.4/site-packages/spambayes/mboxutils.py", line 129, in get_message msg = email.message_from_string(obj) File "/Users/skip/local/lib/python2.4/email/__init__.py", line 43, in message_from_string return Parser(*args, **kws).parsestr(s) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 79, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 68, in parse feedparser.feed(data) File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 146, in feed self._call_parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 150, in _call_parse self._parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 331, in _parsegen for retval in self._parsegen(): File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 228, in _parsegen for retval in self._parsegen(): File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 190, in _parsegen for line in self._input: File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 119, in next line = self.readline() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 79, in readline if ateof(line): TypeError: expected string or buffer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076485&group_id=5470 From noreply at sourceforge.net Wed Dec 1 05:26:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 05:26:23 2004 Subject: [ python-Bugs-1076490 ] Sate/Save typo in Mac/scripts/BuildApplication.py Message-ID: Bugs item #1076490, was opened at 2004-11-30 21:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076490&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Neil Mayhew (neil_mayhew) Assigned to: Jack Jansen (jackjansen) Summary: Sate/Save typo in Mac/scripts/BuildApplication.py Initial Comment: MacPython-OS9 2.3.3, on Mac OS 9.1 Patch attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076490&group_id=5470 From noreply at sourceforge.net Wed Dec 1 05:35:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 05:35:25 2004 Subject: [ python-Bugs-1076492 ] BuildApplication includes many unneeded modules Message-ID: Bugs item #1076492, was opened at 2004-11-30 21:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076492&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Neil Mayhew (neil_mayhew) Assigned to: Jack Jansen (jackjansen) Summary: BuildApplication includes many unneeded modules Initial Comment: I have a simple application to calculate MD5 sums for Macintosh files with resource forks. BuildApplication includes a whole raft of modules, such as httplib, that seem to be unrelated to my application. My imports are: import sys, os import md5 import EasyDialogs import MacOS import Carbon.File as macfs Apologies if this is a known limitation, but I didn't see it mentioned anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076492&group_id=5470 From noreply at sourceforge.net Wed Dec 1 05:36:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 05:37:11 2004 Subject: [ python-Bugs-1076492 ] BuildApplication includes many unneeded modules Message-ID: Bugs item #1076492, was opened at 2004-11-30 21:35 Message generated for change (Comment added) made by neil_mayhew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076492&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Neil Mayhew (neil_mayhew) Assigned to: Jack Jansen (jackjansen) Summary: BuildApplication includes many unneeded modules Initial Comment: I have a simple application to calculate MD5 sums for Macintosh files with resource forks. BuildApplication includes a whole raft of modules, such as httplib, that seem to be unrelated to my application. My imports are: import sys, os import md5 import EasyDialogs import MacOS import Carbon.File as macfs Apologies if this is a known limitation, but I didn't see it mentioned anywhere. ---------------------------------------------------------------------- >Comment By: Neil Mayhew (neil_mayhew) Date: 2004-11-30 21:36 Message: Logged In: YES user_id=709148 MacPython-OS9 2.3.3, on Mac OS 9.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076492&group_id=5470 From noreply at sourceforge.net Wed Dec 1 05:47:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 05:47:14 2004 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 04:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Nobody/Anonymous (nobody) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Wed Dec 1 06:40:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 06:40:50 2004 Subject: [ python-Bugs-1076515 ] shutil.move clobbers read-only files. Message-ID: Bugs item #1076515, was opened at 2004-12-01 00:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move clobbers read-only files. Initial Comment: The summary states it fine. shutil.move happily overwrites read- only files. It looks like it indiscriminately catches OSError, and never bothers to check whether it's a permission error. It'd be nice if permission errors raised an exception that was a subclass of OSError, then it'd be cake to fix this (at least for *nices; I'm not sure about the Windows implications). According to tracker #810879, clobbering read-only files isn't the desired behavior for shutil.copyfile, so I doubt it's desired for shutil.move. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 From noreply at sourceforge.net Wed Dec 1 14:45:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 14:45:37 2004 Subject: [ python-Bugs-1076365 ] Whats New for 2.4 "SafeTemplate" patch. Message-ID: Bugs item #1076365, was opened at 2004-11-30 18:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076365&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: A.M. Kuchling (akuchling) Summary: Whats New for 2.4 "SafeTemplate" patch. Initial Comment: Feel free to assign this back to me if you'd like, I can apply it if it's kosher. The "What's New in 2.4" document shows a demonstration with "SafeTemplate()" used. It should be "Template()", but using the "safe_substitute" method. The text and example are correct except for the use of SafeTemplate instead of Template. Also, I added my name to the string.rsplit() description as the contributor. Sean ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-01 08:45 Message: Logged In: YES user_id=11375 Applied; thanks! ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-11-30 18:45 Message: Logged In: YES user_id=12800 Also, Template does not inherit from unicode (it once did, but that was changed). You might also want to add that getservbyport() was added to the socket module. Also, its second argument and that of getservbyname() were made optional. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076365&group_id=5470 From noreply at sourceforge.net Wed Dec 1 15:41:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 15:41:27 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 15:42:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 15:42:49 2004 Subject: [ python-Bugs-1076791 ] test test_re produced unexpected output Message-ID: Bugs item #1076791, was opened at 2004-12-01 15:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_re produced unexpected output Initial Comment: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 From noreply at sourceforge.net Wed Dec 1 15:45:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 15:45:25 2004 Subject: [ python-Bugs-1076795 ] test test_unicodedata failed Message-ID: Bugs item #1076795, was opened at 2004-12-01 15:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_unicodedata failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 From noreply at sourceforge.net Wed Dec 1 15:53:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 15:53:30 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 15:59:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 15:59:26 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:08:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:09:00 2004 Subject: [ python-Bugs-1076811 ] test test_shutil failed Message-ID: Bugs item #1076811, was opened at 2004-12-01 16:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076811&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_shutil failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076811&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:11:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:11:28 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:11:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:11:49 2004 Subject: [ python-Bugs-1076811 ] test test_shutil failed Message-ID: Bugs item #1076811, was opened at 2004-12-01 16:08 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076811&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_shutil failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Sorry, forgot to search first, bug 1076467 is the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076811&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:22:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:22:48 2004 Subject: [ python-Bugs-1076819 ] test_shelve failures Message-ID: Bugs item #1076819, was opened at 2004-12-01 16:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: ====================================================================== FAIL: test_read (__main__.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestBinaryFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestProto2FileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:26:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:26:04 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:26:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:26:08 2004 Subject: [ python-Bugs-1076791 ] test test_re produced unexpected output Message-ID: Bugs item #1076791, was opened at 2004-12-01 15:42 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_re produced unexpected output Initial Comment: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:26:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:26:09 2004 Subject: [ python-Bugs-1076795 ] test test_unicodedata failed Message-ID: Bugs item #1076795, was opened at 2004-12-01 15:45 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_unicodedata failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:26:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:26:17 2004 Subject: [ python-Bugs-1076819 ] test_shelve failures Message-ID: Bugs item #1076819, was opened at 2004-12-01 16:22 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: ====================================================================== FAIL: test_read (__main__.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestBinaryFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestProto2FileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 From noreply at sourceforge.net Wed Dec 1 16:26:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 16:26:30 2004 Subject: [ python-Bugs-1076795 ] test test_unicodedata failed Message-ID: Bugs item #1076795, was opened at 2004-12-01 15:45 Message generated for change (Settings changed) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 >Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_unicodedata failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:15:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:15:12 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:16:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:16:32 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:21:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:21:59 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:28:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:28:42 2004 Subject: [ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP Message-ID: Bugs item #1076861, was opened at 2004-12-01 10:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: Bad IDLE shortcut by 2.4 installer on XP Initial Comment: There is a problem with the Python 2.4 installer on Windows XP. The IDLE shortcut set up by the installer in the StartUp folder does not work. If the shortcut is removed and recreated manually, it works fine. That was *after* a complete reinstall of Python 2.4 and after removing the previous version of Python 2.3 on the machine. With Python 2.3 present, the IDLE shortcut installed by Python 2.4 runs the 2.3 version. See also and ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:30:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:30:59 2004 Subject: [ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues Message-ID: Bugs item #1074873, was opened at 2004-11-28 16:34 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 Category: Installation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: dmerrill (davemerrill) Assigned to: Nobody/Anonymous (nobody) Summary: Windows 2.4c1 installer default location issues Initial Comment: On win2k sp4, python-2.4c1.msi defaults to installing in c:\Python24\, rather than the more usual c:\Program Files\Python24\ like 2.3.3 did. When I pointed it to c:\Program Files\Python24\, it installed there, but I couldn't get IDLE to run; silent failure. Not sure if there were other similar issues. Uninstalled, and reinstalled to the default location, all is (apparently, so far) well. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 10:30 Message: Logged In: YES user_id=832557 More details on the IDLE issue in bug report 1076861, here ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:32:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:32:07 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:41:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:41:32 2004 Subject: [ python-Bugs-1076795 ] test test_unicodedata failed Message-ID: Bugs item #1076795, was opened at 2004-12-01 15:45 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_unicodedata failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:41 Message: Logged In: YES user_id=192186 Here applies same as for bug 1076790 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 From noreply at sourceforge.net Wed Dec 1 17:48:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 17:48:48 2004 Subject: [ python-Bugs-1076791 ] test test_re produced unexpected output Message-ID: Bugs item #1076791, was opened at 2004-12-01 15:42 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_re produced unexpected output Initial Comment: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:48 Message: Logged In: YES user_id=192186 Here applies same as for bug 1076790 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 From noreply at sourceforge.net Wed Dec 1 18:04:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 18:04:46 2004 Subject: [ python-Bugs-1073736 ] ^Z doesn't exit interpreter - 2.4c1 & Win2K Message-ID: Bugs item #1073736, was opened at 2004-11-26 07:18 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: ^Z doesn't exit interpreter - 2.4c1 & Win2K Initial Comment: In Python 2.3.4 on my Windows 2000 system, typing control-Z at the interpreter prompt echos '^Z' and exits the interpreter. In Python 2.4c1 when I type control-Z, nothing happens at all - the interpreter does not respond in any way. Kent ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 11:04 Message: Logged In: YES user_id=832557 On Windows XP SP2, Python 2.3.4 echos '^Z' and does *not* exit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-29 00:34 Message: Logged In: YES user_id=80475 I cannot reproduce either. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2004-11-27 05:02 Message: Logged In: YES user_id=49695 I am unable to reproduce this today, though I have seen it on more than one occasion... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 From noreply at sourceforge.net Wed Dec 1 18:08:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 18:08:21 2004 Subject: [ python-Bugs-1073736 ] ^Z doesn't exit interpreter - 2.4c1 & Win2K Message-ID: Bugs item #1073736, was opened at 2004-11-26 08:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: ^Z doesn't exit interpreter - 2.4c1 & Win2K Initial Comment: In Python 2.3.4 on my Windows 2000 system, typing control-Z at the interpreter prompt echos '^Z' and exits the interpreter. In Python 2.4c1 when I type control-Z, nothing happens at all - the interpreter does not respond in any way. Kent ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-01 12:08 Message: Logged In: YES user_id=31435 jbrouwers: That's expected. You have to hit ENTER after it echoes ^Z. Then it should exit. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 12:04 Message: Logged In: YES user_id=832557 On Windows XP SP2, Python 2.3.4 echos '^Z' and does *not* exit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-29 01:34 Message: Logged In: YES user_id=80475 I cannot reproduce either. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2004-11-27 06:02 Message: Logged In: YES user_id=49695 I am unable to reproduce this today, though I have seen it on more than one occasion... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 From noreply at sourceforge.net Wed Dec 1 18:20:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 18:21:00 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 18:29:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 18:29:40 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 19:07:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 19:07:10 2004 Subject: [ python-Bugs-1076955 ] Tutorial corrections Message-ID: Bugs item #1076955, was opened at 2004-12-01 13:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076955&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tutorial corrections Initial Comment: This is from an email that got buried in my inbox. Several errors and observations on the Python Tutorial, based on the 2.3.3 and 2.3.4 versions. The reporter notes that most of the issues remain in the 2.4 version. The attached file contains the report originally received, exactly as it was sent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076955&group_id=5470 From noreply at sourceforge.net Wed Dec 1 19:33:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 19:33:52 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 19:37:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 19:38:01 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470Category: Python Library Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470Category: Python Library From noreply at sourceforge.net Wed Dec 1 19:51:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 19:51:15 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Wed Dec 1 20:13:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 20:13:55 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Wed Dec 1 21:19:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 21:19:42 2004 Subject: [ python-Bugs-1077040 ] Error building _bsddb extension Message-ID: Bugs item #1077040, was opened at 2004-12-01 23:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Error building _bsddb extension Initial Comment: Trying to build Python 2.4 on Debian GNU/Linux 3.0 using gcc 3.3.4. BerkeleyDB version is 3.2, header is /usr/include/db.h, library in /usr/lib. Error: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fPIC -I. -I/usr/local/src/Python/Python-2.4/./Include -I/usr/local/include -I/usr/local/src/Python/Python-2.4/Include -I/usr/local/src/Python/Python-2.4 -c /usr/local/src/Python/Python-2.4/Modules/_bsddb.c -o build/temp.linux-i686-2.4/_bsddb.o running build_scripts /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DB_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1464: error: structure has no member named `pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1482: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1483: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DBC_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2928: error: structure has no member named `c_pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2943: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2944: error: structure has no member named `primaryDBType' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 From noreply at sourceforge.net Wed Dec 1 21:32:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 21:32:13 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by dark-storm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Wed Dec 1 21:36:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 21:36:25 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by dark-storm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:30:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:30:18 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by pierre42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:32:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:32:17 2004 Subject: [ python-Bugs-1076791 ] test test_re produced unexpected output Message-ID: Bugs item #1076791, was opened at 2004-12-01 15:42 Message generated for change (Comment added) made by pierre42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_re produced unexpected output Initial Comment: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:32 Message: Logged In: YES user_id=512388 I have the same error. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:48 Message: Logged In: YES user_id=192186 Here applies same as for bug 1076790 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:35:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:35:37 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by pierre42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:35 Message: Logged In: YES user_id=512388 Same here. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:36:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:36:39 2004 Subject: [ python-Bugs-1076795 ] test test_unicodedata failed Message-ID: Bugs item #1076795, was opened at 2004-12-01 15:45 Message generated for change (Comment added) made by pierre42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_unicodedata failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:36 Message: Logged In: YES user_id=512388 Same for me... ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:41 Message: Logged In: YES user_id=192186 Here applies same as for bug 1076790 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:38:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:38:42 2004 Subject: [ python-Bugs-1077103 ] Problem testing python 2.4 Message-ID: Bugs item #1077103, was opened at 2004-12-01 22:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077103&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) Summary: Problem testing python 2.4 Initial Comment: [...] test_unary test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file [...] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077103&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:40:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:40:56 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Wed Dec 1 22:52:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 22:52:18 2004 Subject: [ python-Bugs-1077103 ] Problem testing python 2.4 Message-ID: Bugs item #1077103, was opened at 2004-12-01 13:38 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077103&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Nobody/Anonymous (nobody) Summary: Problem testing python 2.4 Initial Comment: [...] test_unary test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file [...] ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-01 13:52 Message: Logged In: YES user_id=357491 Can you please execute test_unicode independently and upload the traceback that results from the failure? The information in the original post is not enough to know why the test failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077103&group_id=5470 From noreply at sourceforge.net Wed Dec 1 23:07:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 1 23:07:57 2004 Subject: [ python-Feature Requests-1074462 ] Irregular behavior of datetime.__str__() Message-ID: Feature Requests item #1074462, was opened at 2004-11-27 21:18 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Irregular behavior of datetime.__str__() Initial Comment: >From documentation of datetime.isoformat() and __str__() : Return a string representing the date and time in ISO 8601 format, YYYY-MM-DDTHH:MM:SS.mmmmmm or, if microsecond is 0, YYYY-MM-DDTHH:MM:SS This behavior assume if microsecond is 0, it means the user don't need microsecond precision. This is a poor assumption because obviously the user may want microsecond precision but its value just happen to be 0. Now the output is irregular the user can't even use string slicing without checking the length of the output first. Similar behavior found in timedelta.__str__() time.isoformat() ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-01 14:07 Message: Logged In: YES user_id=357491 OK, look at it in terms of math; trailing zeros are almost always truncated from numbers because they are superfluous. The same is happening here; the superfluous zeros after the decimal are just being truncated. And you can also just as easily detect if there are no trailing zeros and tack them on if you prefer:: iso = datetime.datetime.now().isoformat() if '.' not in iso: iso = '%s.000000' % iso Because the docs clearly state this behavior I am changing this to a feature request for Python 2.5 . But I do understand the desire to make parsing easier. If Tim Peters is okays the API change I will patch it to take an optional argument which will force a microsecond output. But personally I am -0 on the option. You listening by any chance, Tim? ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2004-11-28 21:30 Message: Logged In: YES user_id=561546 I don't understand the issue with strftime() and strptime(). If datetime supports microsecond and time doesn't, the user just have to trim the microsecond off like: strptime( str(datetime.now())[:-7], format) The problem is the above won't work. And that's why I filed this bug. It fails if datetime.now() just happen to have microsecond value of 0. How often this happen is not the issue. The issue is it should be deterministic. Actually an issue that happens 1/1000th of time is a lot more problematic than an issue that happens consistently. A preferable design is to have datetime to take an extra flag to indicate if microsecond is wanted. Or a datetime class that supports second precision and a subclass that supports microsecond. The user should make a choice on how much precision should be used, not leaving it up to chance. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-28 11:58 Message: Logged In: YES user_id=357491 But there is a reason for this behavior; strftime() and strptime() do not support microsecond values. If you are working with those two functions those values will cause you issues when specifying the directives. And the chances of actually having a 0 microsecond if you are using them is rather small to say the least. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470 From noreply at sourceforge.net Thu Dec 2 00:11:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 00:11:24 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Comment added) made by foom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 18:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Thu Dec 2 00:56:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 00:56:56 2004 Subject: [ python-Bugs-608033 ] Implied __init__.py not copied Message-ID: Bugs item #608033, was opened at 2002-09-11 17:13 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470 Category: Distutils Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: A.M. Kuchling (akuchling) Summary: Implied __init__.py not copied Initial Comment: The setup method in distutils won't allow me to specify packages and py_modules, and it doesn't correctly deduce all of the directories that need __init__.py files copied. See the attached setup.py for an example. This setup.py is automatically generated from a cca.sidl file containing an interface description. In my example, the directory structure is as follows: gov/ gov/cca/ gov/cca/ports/ decaf/ decaf/ports The problem is that gov/ only contains __init__.py. If I specific packages and py_modules in my setup call, I see the following: [epperly@tux06 runPython]$ python2.2 setup.py --include-dirs=`cd ../../../runtime/python && pwd` --include-dirs=`cd ../../../runtime/sidl && pwd` --include-dirs=`cd . && pwd` --library-dirs=`cd ../../../runtime/sidl/.libs && pwd` install --prefix=/tmp/pytest running install running build running build_py error: build_py: supplying both 'packages' and 'py_modules' options is not allowed [epperly@tux06 runPython]$ If I comment out the "packages = []" part and do a "python setup.py install", it doesn't copy gov/__init__.py, decaf/__init__.py and decaf/ports/__init__.py to the installation directory. >From this data, it appears that distutils isn't deducing the package list correctly from py_modules and ext_modules. For each element of py_modules, it should add all the parent modules. For an py_modules entry, a.b.c.d.e.f, distutils should add a, a.b, a.b.c, a.b.c.d, and a.b.c.d.e to the package list. distutils should also glean package names from the ext_modules list. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-01 20:56 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-06 12:01 Message: Logged In: YES user_id=11375 Actually, it looks like there's code in build_py.py that does add the __init__.py file; see the find_modules() method. It must be broken in some way. I'll look into it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2002-09-12 14:28 Message: Logged In: YES user_id=94539 I can fix my particular problem by using packages and not py_modules. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2002-09-12 14:19 Message: Logged In: YES user_id=94539 I read the section loewis linked me to, and the example given there has 'mod1' in the "root package" and "pkg.mod2" in the pkg/ package. This leads me to believe that py_modules do not go into a single package as loewis suggests. In addition, distutils should copy __init__.py files implied by the list of C extension modules. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-12 04:04 Message: Logged In: YES user_id=21627 It appears that you are misunderstanding the meaning of the py_modules argument. See http://www.python.org/doc/current/dist/setup-script.html#SECTION000320000000000000000 It says "specially the case of a single module that goes in the ``root package'' " All py_modules modules are in a single package, irrespective of their source location. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2002-09-11 17:22 Message: Logged In: YES user_id=94539 I am surprised that sourceforge let me assign this to someone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608033&group_id=5470 From noreply at sourceforge.net Thu Dec 2 01:03:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 01:03:27 2004 Subject: [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 09:24 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-01 21:03 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 13:45 Message: Logged In: YES user_id=612691 Usually it does not have __str__, so __repr__ is getting used. In other cases, the class does have a __str__, and it gets used, but even then I think it shouldn't if there's a __unicode__ All this presumes there's a way to diagnose whether files are wide or narrow -- I'm not familiar enough with the implementation details here to know if this makes sense or not. My original message made the point as follows: If you call str(object), and object's class has a __str__ method, the value is the value of the __str__ method; If you print an object to a normal stream, and object's class has a __str__ method, what appears is the result of the __str__ method. If you call unicode(object), and object's class has a __unicode__ method, the value is the value of the __unicode__ method; So far so good, but read on . . . If you print an object to a unicode stream, and object's class has a __unicode__ method, what appears is the result of . . . _not_ the __unicode__ method, but the __str__ method, if there is one, otherwise the usual default ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 13:38 Message: Logged In: YES user_id=21627 So your class does have an __str__? Or is it the __repr__ that is being used? ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 13:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 12:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 12:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 11:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply at sourceforge.net Thu Dec 2 03:50:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 03:51:01 2004 Subject: [ python-Feature Requests-1074462 ] Irregular behavior of datetime.__str__() Message-ID: Feature Requests item #1074462, was opened at 2004-11-28 00:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Irregular behavior of datetime.__str__() Initial Comment: >From documentation of datetime.isoformat() and __str__() : Return a string representing the date and time in ISO 8601 format, YYYY-MM-DDTHH:MM:SS.mmmmmm or, if microsecond is 0, YYYY-MM-DDTHH:MM:SS This behavior assume if microsecond is 0, it means the user don't need microsecond precision. This is a poor assumption because obviously the user may want microsecond precision but its value just happen to be 0. Now the output is irregular the user can't even use string slicing without checking the length of the output first. Similar behavior found in timedelta.__str__() time.isoformat() ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-01 21:50 Message: Logged In: YES user_id=31435 Sorry, I really don't see a point to this. The claim that slicing doesn't work is unbelievable on two counts: 1. If someone has a datetime object D, and wants, e.g., the year, they don't do str(D), try to slice out the year digits, then convert them to an int(!) -- they just do D.year. Same for the other members (including D.microsecond). 2. Slicing works anyway. For example, str(D)[:4] gets the year digits regardless of D.microsecond. str(D)[17:] gets the seconds likewise, and float(str(D)[17:]) gets the number of seconds as a float regardless of whether D.microsecond is 0. If you want D without microseconds, the intended way to do it is one of: a) Don't set microseconds if you don't want microseconds; or, if you're stuck with unwanted microseconds, b) Use D.replace(microsecond=0) to get a copy of D but with microsecond forced to 0. The current behavior is by design, and documented, so won't be changed regardless. I'm somewhere between -1 and -0 on complicating signatures to give a shortcut for something that's rarely needed and easy to get anyway. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-01 17:07 Message: Logged In: YES user_id=357491 OK, look at it in terms of math; trailing zeros are almost always truncated from numbers because they are superfluous. The same is happening here; the superfluous zeros after the decimal are just being truncated. And you can also just as easily detect if there are no trailing zeros and tack them on if you prefer:: iso = datetime.datetime.now().isoformat() if '.' not in iso: iso = '%s.000000' % iso Because the docs clearly state this behavior I am changing this to a feature request for Python 2.5 . But I do understand the desire to make parsing easier. If Tim Peters is okays the API change I will patch it to take an optional argument which will force a microsecond output. But personally I am -0 on the option. You listening by any chance, Tim? ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2004-11-29 00:30 Message: Logged In: YES user_id=561546 I don't understand the issue with strftime() and strptime(). If datetime supports microsecond and time doesn't, the user just have to trim the microsecond off like: strptime( str(datetime.now())[:-7], format) The problem is the above won't work. And that's why I filed this bug. It fails if datetime.now() just happen to have microsecond value of 0. How often this happen is not the issue. The issue is it should be deterministic. Actually an issue that happens 1/1000th of time is a lot more problematic than an issue that happens consistently. A preferable design is to have datetime to take an extra flag to indicate if microsecond is wanted. Or a datetime class that supports second precision and a subclass that supports microsecond. The user should make a choice on how much precision should be used, not leaving it up to chance. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-28 14:58 Message: Logged In: YES user_id=357491 But there is a reason for this behavior; strftime() and strptime() do not support microsecond values. If you are working with those two functions those values will cause you issues when specifying the directives. And the chances of actually having a 0 microsecond if you are using them is rather small to say the least. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470 From noreply at sourceforge.net Thu Dec 2 04:45:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 04:45:21 2004 Subject: [ python-Bugs-1072642 ] dyld: ./python.exe multiple definitions of symbol _BC Message-ID: Bugs item #1072642, was opened at 2004-11-24 12:51 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072642&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marius (schamschula) Assigned to: Nobody/Anonymous (nobody) Summary: dyld: ./python.exe multiple definitions of symbol _BC Initial Comment: When installing Python 2.3.4 under Mac OS X 10.3.6 (Darwin 7.6.0) I get the following error: running build running build_ext dyld: ./python.exe multiple definitions of symbol _BC /usr/local/lib/libreadline.5.0.dylib(terminal.so) definition of _BC /usr/lib/libncurses.5.dylib(lib_termcap.o) definition of _BC make: *** [sharedmods] Error 133 Note: as the output states I have readline 5.0 installed. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-12-01 22:45 Message: Logged In: YES user_id=139309 Try configuring like this: env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable- framework ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-25 08:23 Message: Logged In: YES user_id=6656 Hum. Is it possible to write a simple C program that links to both readline and ncurses in your setup? From the error messages I would guess not, but that may be too easy. PS: haven't had the courage to go near readline 5 yet :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072642&group_id=5470 From noreply at sourceforge.net Thu Dec 2 05:24:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 05:24:35 2004 Subject: [ python-Bugs-1077302 ] problem with make test on OS/X Message-ID: Bugs item #1077302, was opened at 2004-12-02 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: problem with make test on OS/X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Thu Dec 2 07:30:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 07:31:03 2004 Subject: [ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit Message-ID: Bugs item #1061968, was opened at 2004-11-07 08:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Category: Threads Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-08 06:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 20:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 17:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 14:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 14:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 11:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurrent() call by a call to PyGILState_Release(), and the latter-- like Python before rev 2.41 --does *not* hold the GIL when it decides to delete the tstate. That's the source of the timing hole you're falling into here. Offhand I'm not sure what to do about it, because I'm not familiar with the other bug Mark was trying to fix with rev 2.59. I'm assigning to Mark under the hope that it will be instantly obvious to him. Mark, if it's not, please assign it to me, and I'll try to work it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 From noreply at sourceforge.net Thu Dec 2 08:29:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 08:29:59 2004 Subject: [ python-Bugs-1076955 ] Tutorial corrections Message-ID: Bugs item #1076955, was opened at 2004-12-01 13:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076955&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Tutorial corrections Initial Comment: This is from an email that got buried in my inbox. Several errors and observations on the Python Tutorial, based on the 2.3.3 and 2.3.4 versions. The reporter notes that most of the issues remain in the 2.4 version. The attached file contains the report originally received, exactly as it was sent. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-02 02:29 Message: Logged In: YES user_id=80475 Applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076955&group_id=5470 From noreply at sourceforge.net Thu Dec 2 08:34:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 08:34:31 2004 Subject: [ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit Message-ID: Bugs item #1061968, was opened at 2004-11-08 03:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Category: Threads >Group: Python 2.3 >Status: Open >Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) >Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-12-02 18:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 17:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-09 01:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-08 15:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-08 12:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-08 09:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-08 09:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-08 06:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurrent() call by a call to PyGILState_Release(), and the latter-- like Python before rev 2.41 --does *not* hold the GIL when it decides to delete the tstate. That's the source of the timing hole you're falling into here. Offhand I'm not sure what to do about it, because I'm not familiar with the other bug Mark was trying to fix with rev 2.59. I'm assigning to Mark under the hope that it will be instantly obvious to him. Mark, if it's not, please assign it to me, and I'll try to work it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 From noreply at sourceforge.net Thu Dec 2 10:20:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 10:21:00 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 23:02 Message generated for change (Comment added) made by meyering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 09:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Thu Dec 2 12:07:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 12:07:47 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Thu Dec 2 12:57:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 12:57:04 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:35 Message: Logged In: YES user_id=512388 Same here. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Thu Dec 2 16:40:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 16:40:37 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Thu Dec 2 16:41:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 16:41:39 2004 Subject: [ python-Bugs-1076795 ] test test_unicodedata failed Message-ID: Bugs item #1076795, was opened at 2004-12-01 15:45 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_unicodedata failed Initial Comment: File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:41 Message: Logged In: YES user_id=38388 Fails for the same reason as explained in bug #1076790. Closing it as duplicate. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:36 Message: Logged In: YES user_id=512388 Same for me... ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:41 Message: Logged In: YES user_id=192186 Here applies same as for bug 1076790 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076795&group_id=5470 From noreply at sourceforge.net Thu Dec 2 16:42:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 16:42:54 2004 Subject: [ python-Bugs-1077103 ] Problem testing python 2.4 Message-ID: Bugs item #1077103, was opened at 2004-12-01 22:38 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077103&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Pierre (pierre42) >Assigned to: M.-A. Lemburg (lemburg) Summary: Problem testing python 2.4 Initial Comment: [...] test_unary test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file [...] ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:42 Message: Logged In: YES user_id=38388 This appears to be the same problem as discussed in #1076790. Closing it as duplicate. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-01 22:52 Message: Logged In: YES user_id=357491 Can you please execute test_unicode independently and upload the traceback that results from the failure? The information in the original post is not enough to know why the test failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077103&group_id=5470 From noreply at sourceforge.net Thu Dec 2 16:45:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 16:45:49 2004 Subject: [ python-Bugs-637094 ] print to unicode stream should __unicode Message-ID: Bugs item #637094, was opened at 2002-11-12 13:24 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:45 Message: Logged In: YES user_id=38388 Please leave this open: it's a reminder to start working on an overhaul of the printing sub-system and file.write() in particular. Thanks. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-02 01:03 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:45 Message: Logged In: YES user_id=612691 Usually it does not have __str__, so __repr__ is getting used. In other cases, the class does have a __str__, and it gets used, but even then I think it shouldn't if there's a __unicode__ All this presumes there's a way to diagnose whether files are wide or narrow -- I'm not familiar enough with the implementation details here to know if this makes sense or not. My original message made the point as follows: If you call str(object), and object's class has a __str__ method, the value is the value of the __str__ method; If you print an object to a normal stream, and object's class has a __str__ method, what appears is the result of the __str__ method. If you call unicode(object), and object's class has a __unicode__ method, the value is the value of the __unicode__ method; So far so good, but read on . . . If you print an object to a unicode stream, and object's class has a __unicode__ method, what appears is the result of . . . _not_ the __unicode__ method, but the __str__ method, if there is one, otherwise the usual default ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 17:38 Message: Logged In: YES user_id=21627 So your class does have an __str__? Or is it the __repr__ that is being used? ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 16:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 16:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637094&group_id=5470 From noreply at sourceforge.net Thu Dec 2 16:46:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 16:46:18 2004 Subject: [ python-Feature Requests-637094 ] print to unicode stream should __unicode Message-ID: Feature Requests item #637094, was opened at 2002-11-12 13:24 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=637094&group_id=5470 >Category: Unicode >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:45 Message: Logged In: YES user_id=38388 Please leave this open: it's a reminder to start working on an overhaul of the printing sub-system and file.write() in particular. Thanks. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-02 01:03 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:45 Message: Logged In: YES user_id=612691 Usually it does not have __str__, so __repr__ is getting used. In other cases, the class does have a __str__, and it gets used, but even then I think it shouldn't if there's a __unicode__ All this presumes there's a way to diagnose whether files are wide or narrow -- I'm not familiar enough with the implementation details here to know if this makes sense or not. My original message made the point as follows: If you call str(object), and object's class has a __str__ method, the value is the value of the __str__ method; If you print an object to a normal stream, and object's class has a __str__ method, what appears is the result of the __str__ method. If you call unicode(object), and object's class has a __unicode__ method, the value is the value of the __unicode__ method; So far so good, but read on . . . If you print an object to a unicode stream, and object's class has a __unicode__ method, what appears is the result of . . . _not_ the __unicode__ method, but the __str__ method, if there is one, otherwise the usual default ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 17:38 Message: Logged In: YES user_id=21627 So your class does have an __str__? Or is it the __repr__ that is being used? ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 16:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 16:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=637094&group_id=5470 From noreply at sourceforge.net Thu Dec 2 16:46:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 16:46:50 2004 Subject: [ python-Feature Requests-637094 ] print to unicode stream should __unicode Message-ID: Feature Requests item #637094, was opened at 2002-11-12 13:24 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=637094&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Henry S Thompson (hthompson) Assigned to: M.-A. Lemburg (lemburg) Summary: print to unicode stream should __unicode Initial Comment: To make __unicode__ parallel to __str__ in what seems like the right way, print >>f,x should check for __unicode__ if f is a unicode-enabled stream See http://mail.python.org/pipermail/python-list/2002-November/129859.html for more details ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:46 Message: Logged In: YES user_id=38388 Changed into a feature request. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:45 Message: Logged In: YES user_id=38388 Please leave this open: it's a reminder to start working on an overhaul of the printing sub-system and file.write() in particular. Thanks. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-02 01:03 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:45 Message: Logged In: YES user_id=612691 Usually it does not have __str__, so __repr__ is getting used. In other cases, the class does have a __str__, and it gets used, but even then I think it shouldn't if there's a __unicode__ All this presumes there's a way to diagnose whether files are wide or narrow -- I'm not familiar enough with the implementation details here to know if this makes sense or not. My original message made the point as follows: If you call str(object), and object's class has a __str__ method, the value is the value of the __str__ method; If you print an object to a normal stream, and object's class has a __str__ method, what appears is the result of the __str__ method. If you call unicode(object), and object's class has a __unicode__ method, the value is the value of the __unicode__ method; So far so good, but read on . . . If you print an object to a unicode stream, and object's class has a __unicode__ method, what appears is the result of . . . _not_ the __unicode__ method, but the __str__ method, if there is one, otherwise the usual default ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 17:38 Message: Logged In: YES user_id=21627 So your class does have an __str__? Or is it the __repr__ that is being used? ---------------------------------------------------------------------- Comment By: Henry S Thompson (hthompson) Date: 2002-11-12 17:34 Message: Logged In: YES user_id=612691 As MvL said, I'm looking at a case such as the following: x=X() f=codecs.getwriter('utf8')(open("/tmp/out","w")) print >>f,x where X has a __unicode__ method. It seems wrong to me that __str__ gets used in this case, not __unicode__ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 16:53 Message: Logged In: YES user_id=38388 Hmm, in those cases, passing Unicode objects to .write() should work (and thus printing too). I think he's trying to print some user-defined instances to such a stream... that's where __str__ is called instead of __unicode__ by PyFile_WriteObject(). The question then becomes: how should PyFile_WriteObject() know whether to look for __unicode__ or not ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-12 16:20 Message: Logged In: YES user_id=21627 Henry is talking about the objects returned from codecs.open, or instantiating the classes returned from codecs.get_writer. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-11-12 15:58 Message: Logged In: YES user_id=38388 I'm not sure I understand: what is a "unicode stream". All streams in Python are considered byte streams and (currently) have no encoding attached. Changing that would require a lot of work, some of which is under way. Still, the best way to deal with this is to first encode Unicode to a string using a known stream encoding and then sending off the 8-bit data from the encoding process to the stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=637094&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:03:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:03:32 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:04:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:05:03 2004 Subject: [ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit Message-ID: Bugs item #1061968, was opened at 2004-11-07 11:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-02 11:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 02:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 01:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-08 09:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 23:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 20:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 17:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 17:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 14:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurrent() call by a call to PyGILState_Release(), and the latter-- like Python before rev 2.41 --does *not* hold the GIL when it decides to delete the tstate. That's the source of the timing hole you're falling into here. Offhand I'm not sure what to do about it, because I'm not familiar with the other bug Mark was trying to fix with rev 2.59. I'm assigning to Mark under the hope that it will be instantly obvious to him. Mark, if it's not, please assign it to me, and I'll try to work it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:20:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:20:53 2004 Subject: [ python-Bugs-1072259 ] re module segfaulting in large regular expression Message-ID: Bugs item #1072259, was opened at 2004-11-24 03:38 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072259&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Erik Demaine (edemaine) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re module segfaulting in large regular expression Initial Comment: The attached code worked fine in Python 2.3 and prior, but broke in a recent version of Python 2.4 (I think between the alpha and beta, but I'm not sure). It now causes a Segmentation fault, at least on my Linux boxes (2.4.18 and 2.4.22). For those not looking at the attachment, the code is essentially: import re re.match (...big regular expression..., 'December 20, 1997', re.IGNORECASE) The code works if the re.IGNORECASE flag is omitted. I hope I'm not doing anything stupid in installation... I tried both CVS head and 2.4c1, both with-pyalloc and without-pyalloc. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-12-02 16:20 Message: Logged In: YES user_id=7887 I'm really sorry for not fixing this before 2.4 final. The only reason it wasn't fixed is because I wasn't aware about it until yesterday. The problem is fixed in CVS on revision 2.110 of _sre.c. The patch is also attached for reference. Thank you very much for reporting it Erik, and thanks you for pointing the bug to me Raymond. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-01 03:47 Message: Logged In: YES user_id=80475 Verified that this segfaults on Py2.4 final but not Py2.3. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-30 23:57 Message: Logged In: YES user_id=265183 FYI, this bug remains in 2.4final, which is a shame to me (but probably just a timing mishap), as it makes 2.4 unusable to me. However, the exact version I attached before does seem to work on on 2.4final on WindowsXP, but still not on Linux. Attached is a version that still fails on 2.4final on all systems I've tried. The only difference is using re.compile(...).match instead of re.match. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-24 03:40 Message: Logged In: YES user_id=265183 An update: The same code crashes (general protection fault) on a vanilla install of 2.4c1 on Windows XP using the MSI installer. So I don't think it's my installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072259&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:23:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:23:25 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:38:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:38:57 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:42:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:42:22 2004 Subject: [ python-Bugs-1075990 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075990, was opened at 2004-11-30 08:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075990&group_id=5470 Category: XML Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-02 11:42 Message: Logged In: YES user_id=11375 SF duplicated the bug for some reason; closing as a duplicate of #1075984. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075990&group_id=5470 From noreply at sourceforge.net Thu Dec 2 17:43:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 17:43:16 2004 Subject: [ python-Bugs-1074261 ] gzip dies on gz files with many appended headers Message-ID: Bugs item #1074261, was opened at 2004-11-27 12:29 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074261&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Eichin (eichin) >Assigned to: A.M. Kuchling (akuchling) Summary: gzip dies on gz files with many appended headers Initial Comment: One of the values of the gzip format is that one can reopen for append and the file is, as a whole, still valid. This is accomplished by adding new headers on reopen. gzip.py (as tested on 2.1, 2.3, and 2.4rc1 freshly built) doesn't deal well with more than a certain number of appended headers. The included test case generates (using gzip.py) such a file, runs gzip -tv on it to show that it is valid, and then tries to read it with gzip.py -- and it blows out, with OverflowError: long int too large to convert to int in earlier releases, MemoryError in 2.4rc1 - what's going on is that gzip.GzipFile.read keeps doubling readsize and calling _read again; _read does call _read_gzip_header, and consumes *one* header. So, readsize doubling means that older pythons blow out by not autopromoting past 2**32, and 2.4 blows out trying to call file.read on a huge value - but basically, more than 30 or so headers and it fails. The test case below is based on a real-world queueing case that generates over 200 appended headers - and isn't bounded in any useful way. I'll think about ways to make GzipFile more clever, but I don't have a patch yet. ---------------------------------------------------------------------- Comment By: Mark Eichin (eichin) Date: 2004-11-27 18:28 Message: Logged In: YES user_id=79734 Patch sent to patch-tracker as 1074381. ---------------------------------------------------------------------- Comment By: Mark Eichin (eichin) Date: 2004-11-27 12:48 Message: Logged In: YES user_id=79734 Oh, this is actually easy to fix: just clamp readsize. After all, you don't *actually* want to try to read gigabyte chunks most of the time. (The supplied patch allows one to override gzip.GzipFile.max_read_chunk if one really does.) Tested on 2.4rc1, and a version backported to 2.1 works there too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074261&group_id=5470 From noreply at sourceforge.net Thu Dec 2 20:17:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 20:17:19 2004 Subject: [ python-Feature Requests-1074462 ] Irregular behavior of datetime.__str__() Message-ID: Feature Requests item #1074462, was opened at 2004-11-27 21:18 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Irregular behavior of datetime.__str__() Initial Comment: >From documentation of datetime.isoformat() and __str__() : Return a string representing the date and time in ISO 8601 format, YYYY-MM-DDTHH:MM:SS.mmmmmm or, if microsecond is 0, YYYY-MM-DDTHH:MM:SS This behavior assume if microsecond is 0, it means the user don't need microsecond precision. This is a poor assumption because obviously the user may want microsecond precision but its value just happen to be 0. Now the output is irregular the user can't even use string slicing without checking the length of the output first. Similar behavior found in timedelta.__str__() time.isoformat() ---------------------------------------------------------------------- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2004-12-02 11:17 Message: Logged In: YES user_id=561546 You didn't get the problem case. The microsecond is wanted but it happens to be 0. Now I can't get a timestamp aligned without some doing some extra checking. I also hate complicating signatures. So my recommendation really is to remove the one line of if statement and have it always output the microsecond as a fixed size string. Python will have one less test case. The user will get a fix sized string they can easily slice to get any precision they want. The current logic really only complicate things. If you take it one step further and skip minute and second if they are all 0, it will probably be more of an annoyonce than useful. Nor is the trimming trailing zeros rationale is actually taking place here. On Windows str(now()) always have the last 3 digits 0, except in the 1/1000 of time when the microsecond happens to be 0. Nothing is fatal flawed here. Right now I just avoid str() and use the strptime() instead. The problem is just the extra logic in str() actually make it less useful. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-01 18:50 Message: Logged In: YES user_id=31435 Sorry, I really don't see a point to this. The claim that slicing doesn't work is unbelievable on two counts: 1. If someone has a datetime object D, and wants, e.g., the year, they don't do str(D), try to slice out the year digits, then convert them to an int(!) -- they just do D.year. Same for the other members (including D.microsecond). 2. Slicing works anyway. For example, str(D)[:4] gets the year digits regardless of D.microsecond. str(D)[17:] gets the seconds likewise, and float(str(D)[17:]) gets the number of seconds as a float regardless of whether D.microsecond is 0. If you want D without microseconds, the intended way to do it is one of: a) Don't set microseconds if you don't want microseconds; or, if you're stuck with unwanted microseconds, b) Use D.replace(microsecond=0) to get a copy of D but with microsecond forced to 0. The current behavior is by design, and documented, so won't be changed regardless. I'm somewhere between -1 and -0 on complicating signatures to give a shortcut for something that's rarely needed and easy to get anyway. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-01 14:07 Message: Logged In: YES user_id=357491 OK, look at it in terms of math; trailing zeros are almost always truncated from numbers because they are superfluous. The same is happening here; the superfluous zeros after the decimal are just being truncated. And you can also just as easily detect if there are no trailing zeros and tack them on if you prefer:: iso = datetime.datetime.now().isoformat() if '.' not in iso: iso = '%s.000000' % iso Because the docs clearly state this behavior I am changing this to a feature request for Python 2.5 . But I do understand the desire to make parsing easier. If Tim Peters is okays the API change I will patch it to take an optional argument which will force a microsecond output. But personally I am -0 on the option. You listening by any chance, Tim? ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2004-11-28 21:30 Message: Logged In: YES user_id=561546 I don't understand the issue with strftime() and strptime(). If datetime supports microsecond and time doesn't, the user just have to trim the microsecond off like: strptime( str(datetime.now())[:-7], format) The problem is the above won't work. And that's why I filed this bug. It fails if datetime.now() just happen to have microsecond value of 0. How often this happen is not the issue. The issue is it should be deterministic. Actually an issue that happens 1/1000th of time is a lot more problematic than an issue that happens consistently. A preferable design is to have datetime to take an extra flag to indicate if microsecond is wanted. Or a datetime class that supports second precision and a subclass that supports microsecond. The user should make a choice on how much precision should be used, not leaving it up to chance. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-28 11:58 Message: Logged In: YES user_id=357491 But there is a reason for this behavior; strftime() and strptime() do not support microsecond values. If you are working with those two functions those values will cause you issues when specifying the directives. And the chances of actually having a 0 microsecond if you are using them is rather small to say the least. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1074462&group_id=5470 From noreply at sourceforge.net Thu Dec 2 21:02:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 21:02:57 2004 Subject: [ python-Bugs-1077862 ] assert fail to threw exception when run python with '-O' Message-ID: Bugs item #1077862, was opened at 2004-12-02 20:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077862&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: tj128 (tj128) Assigned to: Nobody/Anonymous (nobody) Summary: assert fail to threw exception when run python with '-O' Initial Comment: in both 2.3 and 2.4 version, if you run 'python -O', assert fail to threw excetption when it should. example >python -O Python 2.3.3 (#4, Apr 11 2004, 12:01:37) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... assert(1==2) ... print 'yyy' ... except: ... print 'zzz' ... yyy >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077862&group_id=5470 From noreply at sourceforge.net Thu Dec 2 21:07:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 21:07:19 2004 Subject: [ python-Bugs-1077862 ] assert fail to threw exception when run python with '-O' Message-ID: Bugs item #1077862, was opened at 2004-12-02 15:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077862&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: tj128 (tj128) Assigned to: Nobody/Anonymous (nobody) Summary: assert fail to threw exception when run python with '-O' Initial Comment: in both 2.3 and 2.4 version, if you run 'python -O', assert fail to threw excetption when it should. example >python -O Python 2.3.3 (#4, Apr 11 2004, 12:01:37) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... assert(1==2) ... print 'yyy' ... except: ... print 'zzz' ... yyy >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-02 15:07 Message: Logged In: YES user_id=31435 That's correct, but it's a deliberate and documented feature. Please read the docs for the assert statement: http://docs.python.org/ref/assert.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077862&group_id=5470 From noreply at sourceforge.net Thu Dec 2 21:52:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 21:52:08 2004 Subject: [ python-Bugs-1074693 ] Errors and omissions in logging module documentation Message-ID: Bugs item #1074693, was opened at 2004-11-28 11:09 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074693&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joachim Boomberschloss (boomberschloss) >Assigned to: Vinay Sajip (vsajip) Summary: Errors and omissions in logging module documentation Initial Comment: Python version: 2.3.3 I found the following problems in the standard logging module's documentation: 1. It is not mentioned that subclasses of LogRecord need to have a getMessage method (http://docs.python.org/lib/node295.html). Instead it is stated that "LogRecord has no methods"! 2. Level values are not documented (which hinders the addition of new levels that need to have a certain relation to the severity of existing levels), nor is the fact that adding a level with the same numeric value as an existing one overrides it. 3. The documentation states that "When a logger is created, the level is set to NOTSET" (http://docs.python.org/lib/node281.html), where in fact it is WARNING. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074693&group_id=5470 From noreply at sourceforge.net Thu Dec 2 21:58:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 21:58:26 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Thu Dec 2 22:21:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 22:21:46 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Thu Dec 2 22:29:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 22:29:10 2004 Subject: [ python-Bugs-1074693 ] Errors and omissions in logging module documentation Message-ID: Bugs item #1074693, was opened at 2004-11-28 16:09 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074693&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Joachim Boomberschloss (boomberschloss) Assigned to: Vinay Sajip (vsajip) Summary: Errors and omissions in logging module documentation Initial Comment: Python version: 2.3.3 I found the following problems in the standard logging module's documentation: 1. It is not mentioned that subclasses of LogRecord need to have a getMessage method (http://docs.python.org/lib/node295.html). Instead it is stated that "LogRecord has no methods"! 2. Level values are not documented (which hinders the addition of new levels that need to have a certain relation to the severity of existing levels), nor is the fact that adding a level with the same numeric value as an existing one overrides it. 3. The documentation states that "When a logger is created, the level is set to NOTSET" (http://docs.python.org/lib/node281.html), where in fact it is WARNING. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-12-02 21:29 Message: Logged In: YES user_id=308438 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074693&group_id=5470 From noreply at sourceforge.net Thu Dec 2 22:35:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 22:36:03 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by dark-storm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Thu Dec 2 22:38:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 2 22:38:44 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by dark-storm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 01:37:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 01:37:52 2004 Subject: [ python-Bugs-1074200 ] xml.dom.minidom produces errors with certain unicode chars Message-ID: Bugs item #1074200, was opened at 2004-11-27 13:58 Message generated for change (Comment added) made by leogah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074200&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peer Janssen (peerjanssen) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom produces errors with certain unicode chars Initial Comment: (note: I tried to file this before, but it didn't show up in the list, so I try again.) In a XML document generated by Trados Translators Workbench (a TMX V 1.1 Translation Memory), the Unicode characters U+0001 ("START OF HEADING", see http://www.fileformat.info/info/unicode/char/0001/index.htm) and SINGLE LOW-9 QUOTATION MARK (U+201A, see http://www.fileformat.info/info/unicode/char/201a/index.htm) produce errors when parsing it from a file with "xml.dom.minidom". The first one (0001) produces this output: Traceback (most recent call last): File "G:\_Prog\TMworks\domtree.py", line 7, in ? dom=parse(tm) File "C:\Python23\lib\xml\dom\minidom.py", line 1919, in parse return expatbuilder.parse(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 928, in parse result = builder.parseFile(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 207, in parseFile parser.Parse(buffer, 0) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 420, column 106 The second one (201A) produces this output: Traceback (most recent call last): File "G:\_Prog\TMworks\domtree.py", line 7, in ? dom=parse(tm) File "C:\Python23\lib\xml\dom\minidom.py", line 1919, in parse return expatbuilder.parse(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 928, in parse result = builder.parseFile(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 207, in parseFile parser.Parse(buffer, 0) xml.parsers.expat.ExpatError: mismatched tag: line 624, column 2 Deleting these two characters in the whole document produces the desired result. I don't see why these characters should be of any problem, especially the quotation mark. ---------------------------------------------------------------------- Comment By: Richard Brodie (leogah) Date: 2004-12-03 00:37 Message: Logged In: YES user_id=356893 I don't think there are any bugs here: at least not Python ones. U+0001 (SOH) isn't an allowed character in XML 1.0: http://www.w3.org/International/questions/qa-controls U+201A (SINGLE LOW-9 QUOTATION MARK) should be fine, except that \x1A is converted to EOF on Windows; then expat chokes on all the unclosed tags. Open the file 'rb'. RB. ---------------------------------------------------------------------- Comment By: Peer Janssen (peerjanssen) Date: 2004-11-27 14:29 Message: Logged In: YES user_id=896722 The file. ---------------------------------------------------------------------- Comment By: Peer Janssen (peerjanssen) Date: 2004-11-27 14:27 Message: Logged In: YES user_id=896722 Here is a zip file with a test program domtree.py and two test files. I noticed that the first test file produces it's bug only on my windows box, but the second test file produces an error on both my windows and my linux box. The windows python version is: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 The linux python version is: Python 2.3.3. (#2, Feb 17, 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-27 14:02 Message: Logged In: YES user_id=38388 Please provide an example that lets us reproduce the error. Unassigning, since I'm not an expert for minidom. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074200&group_id=5470 From noreply at sourceforge.net Fri Dec 3 02:33:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 02:34:01 2004 Subject: [ python-Feature Requests-1076478 ] Python Interpreter embedded in small memory system Message-ID: Feature Requests item #1076478, was opened at 2004-11-30 19:32 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1076478&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: stoneabcwujx (stoneabcwujx) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter embedded in small memory system Initial Comment: I'm a newcomer in python. I want to know how large is the size of python interpreter . If I only need some basic funcitons of python(module import,string operation,math operation,etc), not including such as 'tk' or 'multithreading'. How small could the python interpreter's size to be? Is it only a dream to embed such a small interpreter onto a system which only has 128KB memory? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-02 17:33 Message: Logged In: YES user_id=341410 You picked a funny place to ask a question about Python. The usual places to ask for help are comp.lang.python (also the python-list mailing list) as well as the python-tutor list. Both mailing lists have information about joining on the python.org web site, and comp.lang.python is available on the web via google groups, or most any newsgroup provider. Those with close access: I would suggest this 'RFE' be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1076478&group_id=5470 From noreply at sourceforge.net Fri Dec 3 03:25:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 03:25:24 2004 Subject: [ python-Feature Requests-1076478 ] Python Interpreter embedded in small memory system Message-ID: Feature Requests item #1076478, was opened at 2004-11-30 22:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1076478&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: stoneabcwujx (stoneabcwujx) Assigned to: Nobody/Anonymous (nobody) Summary: Python Interpreter embedded in small memory system Initial Comment: I'm a newcomer in python. I want to know how large is the size of python interpreter . If I only need some basic funcitons of python(module import,string operation,math operation,etc), not including such as 'tk' or 'multithreading'. How small could the python interpreter's size to be? Is it only a dream to embed such a small interpreter onto a system which only has 128KB memory? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-02 20:33 Message: Logged In: YES user_id=341410 You picked a funny place to ask a question about Python. The usual places to ask for help are comp.lang.python (also the python-list mailing list) as well as the python-tutor list. Both mailing lists have information about joining on the python.org web site, and comp.lang.python is available on the web via google groups, or most any newsgroup provider. Those with close access: I would suggest this 'RFE' be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1076478&group_id=5470 From noreply at sourceforge.net Fri Dec 3 05:23:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 05:23:39 2004 Subject: [ python-Bugs-1077302 ] problem with make test on OS/X Message-ID: Bugs item #1077302, was opened at 2004-12-01 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: problem with make test on OS/X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Fri Dec 3 05:45:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 05:45:59 2004 Subject: [ python-Bugs-1077302 ] problem with make test on OS/X Message-ID: Bugs item #1077302, was opened at 2004-12-01 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: problem with make test on OS/X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Fri Dec 3 11:21:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 11:21:38 2004 Subject: [ python-Bugs-1077302 ] problem with make test on OS/X Message-ID: Bugs item #1077302, was opened at 2004-12-02 04:24 Message generated for change (Comment added) made by jneb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: problem with make test on OS/X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 10:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 04:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 04:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Fri Dec 3 11:30:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 11:30:47 2004 Subject: [ python-Bugs-1077302 ] problem with make test on OS/X Message-ID: Bugs item #1077302, was opened at 2004-12-02 05:24 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: problem with make test on OS/X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 11:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 05:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 05:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Fri Dec 3 11:43:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 11:43:43 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 11:46:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 11:46:21 2004 Subject: [ python-Bugs-1077302 ] problem with make test on OS/X Message-ID: Bugs item #1077302, was opened at 2004-12-02 15:24 Message generated for change (Comment added) made by webperf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: problem with make test on OS/X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Ian Holsman (webperf) Date: 2004-12-03 21:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 21:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 21:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Fri Dec 3 12:03:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 12:03:18 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 12:16:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 12:16:14 2004 Subject: [ python-Bugs-1078245 ] Python2.4: building '_socket' extension fails with `INET_ADD Message-ID: Bugs item #1078245, was opened at 2004-12-03 12:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.4: building '_socket' extension fails with `INET_ADD Initial Comment: HI! I'm trying to build Python2.4 on a rather old Debian machine. Building _socket fails (see below) although I tried to use configure --disable-ipv6 I've added #define INET_ADDRSTRLEN 16 to Modules/socketmodule.h which made it work. There were no problems compiling Python2.2 on the very same machine. Ciao, Michael. ------------------------------ snip ------------------------------ building '_socket' extension gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/tmp/Python-2.4/./Include -I/user/W3311/local/include -I/usr/local/include -I/tmp/Python-2.4/Include -I/tmp/Python-2.4 -c /tmp/Python-2.4/Modules/socketmodule.c -o build/t emp.linux-i686-2.4/socketmodule.o /tmp/Python-2.4/Modules/socketmodule.c: In function `socket_inet_ntop': /tmp/Python-2.4/Modules/socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use this function) /tmp/Python-2.4/Modules/socketmodule.c:3350: (Each undeclared identifier is reported only once /tmp/Python-2.4/Modules/socketmodule.c:3350: for each function it appears in.) /tmp/Python-2.4/Modules/socketmodule.c:3350: size of array `ip' has non-integer type ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470 From noreply at sourceforge.net Fri Dec 3 12:19:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 12:19:39 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 12:29:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 12:30:03 2004 Subject: [ python-Bugs-1074200 ] xml.dom.minidom produces errors with certain unicode chars Message-ID: Bugs item #1074200, was opened at 2004-11-27 14:58 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074200&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Peer Janssen (peerjanssen) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom produces errors with certain unicode chars Initial Comment: (note: I tried to file this before, but it didn't show up in the list, so I try again.) In a XML document generated by Trados Translators Workbench (a TMX V 1.1 Translation Memory), the Unicode characters U+0001 ("START OF HEADING", see http://www.fileformat.info/info/unicode/char/0001/index.htm) and SINGLE LOW-9 QUOTATION MARK (U+201A, see http://www.fileformat.info/info/unicode/char/201a/index.htm) produce errors when parsing it from a file with "xml.dom.minidom". The first one (0001) produces this output: Traceback (most recent call last): File "G:\_Prog\TMworks\domtree.py", line 7, in ? dom=parse(tm) File "C:\Python23\lib\xml\dom\minidom.py", line 1919, in parse return expatbuilder.parse(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 928, in parse result = builder.parseFile(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 207, in parseFile parser.Parse(buffer, 0) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 420, column 106 The second one (201A) produces this output: Traceback (most recent call last): File "G:\_Prog\TMworks\domtree.py", line 7, in ? dom=parse(tm) File "C:\Python23\lib\xml\dom\minidom.py", line 1919, in parse return expatbuilder.parse(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 928, in parse result = builder.parseFile(file) File "C:\Python23\lib\xml\dom\expatbuilder.py", line 207, in parseFile parser.Parse(buffer, 0) xml.parsers.expat.ExpatError: mismatched tag: line 624, column 2 Deleting these two characters in the whole document produces the desired result. I don't see why these characters should be of any problem, especially the quotation mark. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-12-03 12:29 Message: Logged In: YES user_id=38376 Closing; see leogah's reply for background. ---------------------------------------------------------------------- Comment By: Richard Brodie (leogah) Date: 2004-12-03 01:37 Message: Logged In: YES user_id=356893 I don't think there are any bugs here: at least not Python ones. U+0001 (SOH) isn't an allowed character in XML 1.0: http://www.w3.org/International/questions/qa-controls U+201A (SINGLE LOW-9 QUOTATION MARK) should be fine, except that \x1A is converted to EOF on Windows; then expat chokes on all the unclosed tags. Open the file 'rb'. RB. ---------------------------------------------------------------------- Comment By: Peer Janssen (peerjanssen) Date: 2004-11-27 15:29 Message: Logged In: YES user_id=896722 The file. ---------------------------------------------------------------------- Comment By: Peer Janssen (peerjanssen) Date: 2004-11-27 15:27 Message: Logged In: YES user_id=896722 Here is a zip file with a test program domtree.py and two test files. I noticed that the first test file produces it's bug only on my windows box, but the second test file produces an error on both my windows and my linux box. The windows python version is: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 The linux python version is: Python 2.3.3. (#2, Feb 17, 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-11-27 15:02 Message: Logged In: YES user_id=38388 Please provide an example that lets us reproduce the error. Unassigning, since I'm not an expert for minidom. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074200&group_id=5470 From noreply at sourceforge.net Fri Dec 3 12:46:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 12:47:01 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:46 Message: Logged In: YES user_id=192186 Okay, it IS locales problem. You should trust man page :-), calling towupper/towlower without set locales (or with POSIX locales) gives wrong result. After applying attached patch, all problems in tests are gone. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 12:58:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 12:58:39 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 13:02:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 13:03:05 2004 Subject: [ python-Bugs-1076791 ] test test_re produced unexpected output Message-ID: Bugs item #1076791, was opened at 2004-12-01 15:42 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_re produced unexpected output Initial Comment: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-03 13:02 Message: Logged In: YES user_id=192186 Okay, this is duplicate of 1076790 ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:32 Message: Logged In: YES user_id=512388 I have the same error. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:48 Message: Logged In: YES user_id=192186 Here applies same as for bug 1076790 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076791&group_id=5470 From noreply at sourceforge.net Fri Dec 3 13:16:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 13:16:21 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 13:16 Message: Logged In: YES user_id=38388 Thanks for the patch. I see a few problems with this approach, though: * We brake binary compatibility depending on the configure settings used for building Python; if this is really necessary we should place the changes into the _PyUnicode_ToLowerCase() et al. APIs defined in unicodectype.c * I'm not sure whether there is any performance or memory usage win in using the wctype functions from glibc: the Unicode type mapping DB table has to be included anyway (due to the title case mapping), so the only win I could see is a performance one and given that towlower et al. do seem to be locale aware I have strong doubts that these functions are actually faster than the lookup in our own database. Could you check whether using the wctype functions from glibc does have any effect on size of the interpreter and performance of e.g. .lower() and .upper() ? If not, I'm inclined to remove the wctype function support altogether. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:46 Message: Logged In: YES user_id=192186 Okay, it IS locales problem. You should trust man page :-), calling towupper/towlower without set locales (or with POSIX locales) gives wrong result. After applying attached patch, all problems in tests are gone. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 13:31:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 13:31:15 2004 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 01:47 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Nobody/Anonymous (nobody) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 09:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Fri Dec 3 13:42:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 13:42:46 2004 Subject: [ python-Bugs-1073736 ] ^Z doesn't exit interpreter - 2.4c1 & Win2K Message-ID: Bugs item #1073736, was opened at 2004-11-26 10:18 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: ^Z doesn't exit interpreter - 2.4c1 & Win2K Initial Comment: In Python 2.3.4 on my Windows 2000 system, typing control-Z at the interpreter prompt echos '^Z' and exits the interpreter. In Python 2.4c1 when I type control-Z, nothing happens at all - the interpreter does not respond in any way. Kent ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 09:42 Message: Logged In: YES user_id=752496 I'm using Win2k, sp2, Py2.4, and it works OK. Could you please test 2.4 final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-01 14:08 Message: Logged In: YES user_id=31435 jbrouwers: That's expected. You have to hit ENTER after it echoes ^Z. Then it should exit. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 14:04 Message: Logged In: YES user_id=832557 On Windows XP SP2, Python 2.3.4 echos '^Z' and does *not* exit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-29 03:34 Message: Logged In: YES user_id=80475 I cannot reproduce either. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2004-11-27 08:02 Message: Logged In: YES user_id=49695 I am unable to reproduce this today, though I have seen it on more than one occasion... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 From noreply at sourceforge.net Fri Dec 3 13:53:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 13:53:26 2004 Subject: [ python-Bugs-1073736 ] ^Z doesn't exit interpreter - 2.4c1 & Win2K Message-ID: Bugs item #1073736, was opened at 2004-11-26 13:18 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: ^Z doesn't exit interpreter - 2.4c1 & Win2K Initial Comment: In Python 2.3.4 on my Windows 2000 system, typing control-Z at the interpreter prompt echos '^Z' and exits the interpreter. In Python 2.4c1 when I type control-Z, nothing happens at all - the interpreter does not respond in any way. Kent ---------------------------------------------------------------------- >Comment By: Kent Johnson (kjohnson) Date: 2004-12-03 12:53 Message: Logged In: YES user_id=49695 I haven't seen this problem in 2.4 final. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 12:42 Message: Logged In: YES user_id=752496 I'm using Win2k, sp2, Py2.4, and it works OK. Could you please test 2.4 final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-01 17:08 Message: Logged In: YES user_id=31435 jbrouwers: That's expected. You have to hit ENTER after it echoes ^Z. Then it should exit. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 17:04 Message: Logged In: YES user_id=832557 On Windows XP SP2, Python 2.3.4 echos '^Z' and does *not* exit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-29 06:34 Message: Logged In: YES user_id=80475 I cannot reproduce either. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2004-11-27 11:02 Message: Logged In: YES user_id=49695 I am unable to reproduce this today, though I have seen it on more than one occasion... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 From noreply at sourceforge.net Fri Dec 3 13:56:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 13:56:21 2004 Subject: [ python-Bugs-1073736 ] ^Z doesn't exit interpreter - 2.4c1 & Win2K Message-ID: Bugs item #1073736, was opened at 2004-11-26 10:18 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: ^Z doesn't exit interpreter - 2.4c1 & Win2K Initial Comment: In Python 2.3.4 on my Windows 2000 system, typing control-Z at the interpreter prompt echos '^Z' and exits the interpreter. In Python 2.4c1 when I type control-Z, nothing happens at all - the interpreter does not respond in any way. Kent ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2004-12-03 09:53 Message: Logged In: YES user_id=49695 I haven't seen this problem in 2.4 final. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 09:42 Message: Logged In: YES user_id=752496 I'm using Win2k, sp2, Py2.4, and it works OK. Could you please test 2.4 final? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-01 14:08 Message: Logged In: YES user_id=31435 jbrouwers: That's expected. You have to hit ENTER after it echoes ^Z. Then it should exit. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 14:04 Message: Logged In: YES user_id=832557 On Windows XP SP2, Python 2.3.4 echos '^Z' and does *not* exit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-11-29 03:34 Message: Logged In: YES user_id=80475 I cannot reproduce either. ---------------------------------------------------------------------- Comment By: Kent Johnson (kjohnson) Date: 2004-11-27 08:02 Message: Logged In: YES user_id=49695 I am unable to reproduce this today, though I have seen it on more than one occasion... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1073736&group_id=5470 From noreply at sourceforge.net Fri Dec 3 14:13:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 14:13:19 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:13 Message: Logged In: YES user_id=192186 After talk to glibc developer: towlower/towupper will never work as expected with POSIX/C locales (because anything besides a-z is not alpha character for these). I can give some performace results, but even without tests, it looks to me like good idea to drop support for this. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 13:16 Message: Logged In: YES user_id=38388 Thanks for the patch. I see a few problems with this approach, though: * We brake binary compatibility depending on the configure settings used for building Python; if this is really necessary we should place the changes into the _PyUnicode_ToLowerCase() et al. APIs defined in unicodectype.c * I'm not sure whether there is any performance or memory usage win in using the wctype functions from glibc: the Unicode type mapping DB table has to be included anyway (due to the title case mapping), so the only win I could see is a performance one and given that towlower et al. do seem to be locale aware I have strong doubts that these functions are actually faster than the lookup in our own database. Could you check whether using the wctype functions from glibc does have any effect on size of the interpreter and performance of e.g. .lower() and .upper() ? If not, I'm inclined to remove the wctype function support altogether. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:46 Message: Logged In: YES user_id=192186 Okay, it IS locales problem. You should trust man page :-), calling towupper/towlower without set locales (or with POSIX locales) gives wrong result. After applying attached patch, all problems in tests are gone. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 14:26:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 14:26:59 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:26 Message: Logged In: YES user_id=192186 without wctype: 100x test_codecs: 10.209s, libpython size: 1140098 with wctype: 100x test_codecs: 10.120s (removed one failing test), libpython size: 1140314 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:13 Message: Logged In: YES user_id=192186 After talk to glibc developer: towlower/towupper will never work as expected with POSIX/C locales (because anything besides a-z is not alpha character for these). I can give some performace results, but even without tests, it looks to me like good idea to drop support for this. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 13:16 Message: Logged In: YES user_id=38388 Thanks for the patch. I see a few problems with this approach, though: * We brake binary compatibility depending on the configure settings used for building Python; if this is really necessary we should place the changes into the _PyUnicode_ToLowerCase() et al. APIs defined in unicodectype.c * I'm not sure whether there is any performance or memory usage win in using the wctype functions from glibc: the Unicode type mapping DB table has to be included anyway (due to the title case mapping), so the only win I could see is a performance one and given that towlower et al. do seem to be locale aware I have strong doubts that these functions are actually faster than the lookup in our own database. Could you check whether using the wctype functions from glibc does have any effect on size of the interpreter and performance of e.g. .lower() and .upper() ? If not, I'm inclined to remove the wctype function support altogether. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:46 Message: Logged In: YES user_id=192186 Okay, it IS locales problem. You should trust man page :-), calling towupper/towlower without set locales (or with POSIX locales) gives wrong result. After applying attached patch, all problems in tests are gone. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 15:46:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 15:46:33 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 15:50:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 15:50:20 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:50 Message: Logged In: YES user_id=38388 Thanks for the tests. Looks to me as if the trouble of keeping the wctype support and working around quirks with the locales is not worth it. I think it's better to remove the support altogether and stick with the builtin type database. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:26 Message: Logged In: YES user_id=192186 without wctype: 100x test_codecs: 10.209s, libpython size: 1140098 with wctype: 100x test_codecs: 10.120s (removed one failing test), libpython size: 1140314 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:13 Message: Logged In: YES user_id=192186 After talk to glibc developer: towlower/towupper will never work as expected with POSIX/C locales (because anything besides a-z is not alpha character for these). I can give some performace results, but even without tests, it looks to me like good idea to drop support for this. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 13:16 Message: Logged In: YES user_id=38388 Thanks for the patch. I see a few problems with this approach, though: * We brake binary compatibility depending on the configure settings used for building Python; if this is really necessary we should place the changes into the _PyUnicode_ToLowerCase() et al. APIs defined in unicodectype.c * I'm not sure whether there is any performance or memory usage win in using the wctype functions from glibc: the Unicode type mapping DB table has to be included anyway (due to the title case mapping), so the only win I could see is a performance one and given that towlower et al. do seem to be locale aware I have strong doubts that these functions are actually faster than the lookup in our own database. Could you check whether using the wctype functions from glibc does have any effect on size of the interpreter and performance of e.g. .lower() and .upper() ? If not, I'm inclined to remove the wctype function support altogether. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:46 Message: Logged In: YES user_id=192186 Okay, it IS locales problem. You should trust man page :-), calling towupper/towlower without set locales (or with POSIX locales) gives wrong result. After applying attached patch, all problems in tests are gone. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 15:55:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 15:55:27 2004 Subject: [ python-Bugs-1076790 ] test test_codecs failed Message-ID: Bugs item #1076790, was opened at 2004-12-01 15:41 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test test_codecs failed Initial Comment: test test_codecs failed -- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/test_codecs.py", line 446, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-03 15:55 Message: Logged In: YES user_id=192186 I agree with removing it, however I'm not the one who could decide :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:50 Message: Logged In: YES user_id=38388 Thanks for the tests. Looks to me as if the trouble of keeping the wctype support and working around quirks with the locales is not worth it. I think it's better to remove the support altogether and stick with the builtin type database. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:26 Message: Logged In: YES user_id=192186 without wctype: 100x test_codecs: 10.209s, libpython size: 1140098 with wctype: 100x test_codecs: 10.120s (removed one failing test), libpython size: 1140314 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 14:13 Message: Logged In: YES user_id=192186 After talk to glibc developer: towlower/towupper will never work as expected with POSIX/C locales (because anything besides a-z is not alpha character for these). I can give some performace results, but even without tests, it looks to me like good idea to drop support for this. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 13:16 Message: Logged In: YES user_id=38388 Thanks for the patch. I see a few problems with this approach, though: * We brake binary compatibility depending on the configure settings used for building Python; if this is really necessary we should place the changes into the _PyUnicode_ToLowerCase() et al. APIs defined in unicodectype.c * I'm not sure whether there is any performance or memory usage win in using the wctype functions from glibc: the Unicode type mapping DB table has to be included anyway (due to the title case mapping), so the only win I could see is a performance one and given that towlower et al. do seem to be locale aware I have strong doubts that these functions are actually faster than the lookup in our own database. Could you check whether using the wctype functions from glibc does have any effect on size of the interpreter and performance of e.g. .lower() and .upper() ? If not, I'm inclined to remove the wctype function support altogether. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:46 Message: Logged In: YES user_id=192186 Okay, it IS locales problem. You should trust man page :-), calling towupper/towlower without set locales (or with POSIX locales) gives wrong result. After applying attached patch, all problems in tests are gone. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 12:19 Message: Logged In: YES user_id=38388 Could you run this test (comparing lower and upper) for all code points in the range(sys.maxunicode) ?! The origin of the problem could be a different code point. I don't think that it has to do with locale (but you never know...), since Unicode is all about unifying locales. The C functions should not be locale aware (even though the man page says it depends on LC_CTYPE). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-03 12:03 Message: Logged In: YES user_id=192186 However when I make simple C program containing: s = 0x143; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); s = 0x144; printf("%lc %lc %lc\n", s, towupper(s), towlower(s)); I get expected results and they're same as from python code: s =u'\u0143' print '%s %s %s' % (s, s.upper(), s.lower()) s =u'\u0144' print '%s %s %s' % (s, s.upper(), s.lower()) I'm starting to thing that it might be something with locales, I'll investigate it more. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 11:43 Message: Logged In: YES user_id=38388 Maybe you should add some hooks to the Py_UNICODE_* macros and recompile (or run the script in a C debugger). The difference in output is minimal (\u0143 vs. \u0144) which I believe hints at a change in the used Unicode DB: 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 The only difference here is the case. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:38 Message: Logged In: YES user_id=192186 I tried towupper and towupper functions for all characters in failed test and I can see no difference comared to python ones... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 17:23 Message: Logged In: YES user_id=38388 The punycode codec uses the .upper() method on Unicode objects. Since this method uses Py_UNICODE_TOUPPER(), any difference in case mapping between the Unicode DB used in Python and the one used in glibc will be noticable as a result of --with-wctype-functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 17:03 Message: Logged In: YES user_id=192186 Compiling without --with-wctype-functions "fixes" this problem. I still don't see what has wctype functions to do with this. They are used for operations like is this numeric, alphanumeric, upper,... I'd like to trace this bug either it is in Python or glibc, but I still don't know what of glibc functions do influence this test. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 16:40 Message: Logged In: YES user_id=38388 Do you get the same error when compiling without --with-wctype-functions ? If not, then we'll just have to close this report as "won't fix" - the reason is that we as Python developers don't have control over what glibc does or does not do. Unfortunately, there's not way to disable the failing tests since the configure option is not available to the Python program. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:07 Message: Logged In: YES user_id=192186 Well, glibc 2.3.3 is reportedly using Unicode DB 3.2, so there must be either bug in it or in Python, I can't tell. Any idea how to find out? ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:30 Message: Logged In: YES user_id=512388 I have the same problem ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 19:37 Message: Logged In: YES user_id=192186 I understand the question, but I have no idea how to find this information inside glibc. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 19:33 Message: Logged In: YES user_id=38388 The wctype functions must have been built using tables from the Unicode code point database. Python's own APIs for this were built using the Unicode DB 3.2. My question is whether you know which version the glibc was built from. It is not surprising that the two tests fail if the underlying Unicode DB versions differ. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 18:29 Message: Logged In: YES user_id=192186 I'm not sure what means "uses", but I found several mentions of Unicode 3.2 in code and in changelogs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 18:20 Message: Logged In: YES user_id=38388 Ah, now I understand: it is well possible that the Unicode database versions differ. Python uses version 3.2. Do you know which version glibc 2.3.3 uses ? Note that for portability it is usually better not to use wctype functions. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:32 Message: Logged In: YES user_id=192186 The problem seems to be in glibc, when I remove --with-wctype-functions, it passes. Or could it be in Python interface to wctype functions? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 17:21 Message: Logged In: YES user_id=192186 gcc (GCC) 3.3.4 (pre 3.3.5 20040809) Yes, I'm building UCS4 version. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:16 Message: Logged In: YES user_id=38388 Sorry: I misread glibc as gcc. Still, this sounds a lot like a broken compiler. BTW, are you building a UCS4 version ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 17:15 Message: Logged In: YES user_id=38388 The tests pass just fine on my machine. Is it possible that your compiler is broken ? gcc 2.3.3 is *very* old ! ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:59 Message: Logged In: YES user_id=192186 It's clean build root with no other python, so it has no chance to pickup bad modules. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-01 15:53 Message: Logged In: YES user_id=38388 Please make sure that Python is picking up the correct modules. You can do so, buy running Python in verbose mode (python -vv). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076790&group_id=5470 From noreply at sourceforge.net Fri Dec 3 16:42:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 16:42:55 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by dark-storm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 20:43:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 20:43:07 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 21:01:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 21:01:04 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 22:45:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 22:46:01 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by dark-storm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 3 23:23:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 3 23:23:08 2004 Subject: [ python-Bugs-1077302 ] test_macostools failure on OS X Message-ID: Bugs item #1077302, was opened at 2004-12-01 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 >Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) >Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-03 14:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-03 02:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 02:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 02:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Sat Dec 4 03:45:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 03:46:02 2004 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 04:47 Message generated for change (Comment added) made by guanzijing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Nobody/Anonymous (nobody) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: guan zi jing (guanzijing) Date: 2004-12-04 02:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 12:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Sat Dec 4 04:10:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 04:10:51 2004 Subject: [ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4) Message-ID: Bugs item #1075703, was opened at 2004-11-29 17:54 Message generated for change (Comment added) made by andivajda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andi Vajda (andivajda) Assigned to: Nobody/Anonymous (nobody) >Summary: PyGILState_Ensure() deadlocks (ver 2.4) Initial Comment: PyLucene (http://pylucene.osafoundation.org) wraps libgcj with python. Python objects are also wrapped by java objects. The ref count of the python is incremented in the wrapping java object constructor and is decremented in the wrapping java object's finalize() method. Yes, finalize() is not a reliable means of cleaning memory up but, so far, I wasn't able to figure out a better way to do this. The finalize() method runs in its own libgcj finalizer thread. It has to acquire the GIL before it can call Py_DECREF() is my understanding. The java finalize() calls this code in PyLucene: void finalizeObject(PyObject *object) { #if PY_VERSION_HEX >= 0x02040000 PyGILState_STATE state = PyGILState_Ensure(); Py_DECREF(object); PyGILState_Release(state); #endif } When compiled with python 2.4c1, this mostly works. Except that it deadlocks, every now and then. If I comment this code out, no deadlock. I also verified that the finalizer is called at most once per such object. I realize that reproducing this bug maybe hard, building PyLucene is not particularly easy, unless you have gcj ready. If you contact me, I'm more than willing to help in providing all that's needed to reproduce this. I've seen the deadlock on Mac OS X 10.3.6, my main development OS. For what it's worth, I also tried this with python 2.3.4 (including threadmodule.c patch made in September, related to GIL function usage). ---------------------------------------------------------------------- >Comment By: Andi Vajda (andivajda) Date: 2004-12-03 19:10 Message: Logged In: YES user_id=1139346 I verified this now with python 2.4 final. It still happens as tested on Mac OS X. I was also able to narrow it down to a unit test, that when run repeatedly will eventually lock up. It is attached. If you need assistance building PyLucene from sources, or want me to provide a binary, let me know. At the moment, to reproduce this bug, it is best to build PyLucene from subversion. See http://pylucene.osafoundation.org for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 From noreply at sourceforge.net Sat Dec 4 04:42:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 04:42:41 2004 Subject: [ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4) Message-ID: Bugs item #1075703, was opened at 2004-11-29 17:54 Message generated for change (Comment added) made by andivajda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andi Vajda (andivajda) Assigned to: Nobody/Anonymous (nobody) Summary: PyGILState_Ensure() deadlocks (ver 2.4) Initial Comment: PyLucene (http://pylucene.osafoundation.org) wraps libgcj with python. Python objects are also wrapped by java objects. The ref count of the python is incremented in the wrapping java object constructor and is decremented in the wrapping java object's finalize() method. Yes, finalize() is not a reliable means of cleaning memory up but, so far, I wasn't able to figure out a better way to do this. The finalize() method runs in its own libgcj finalizer thread. It has to acquire the GIL before it can call Py_DECREF() is my understanding. The java finalize() calls this code in PyLucene: void finalizeObject(PyObject *object) { #if PY_VERSION_HEX >= 0x02040000 PyGILState_STATE state = PyGILState_Ensure(); Py_DECREF(object); PyGILState_Release(state); #endif } When compiled with python 2.4c1, this mostly works. Except that it deadlocks, every now and then. If I comment this code out, no deadlock. I also verified that the finalizer is called at most once per such object. I realize that reproducing this bug maybe hard, building PyLucene is not particularly easy, unless you have gcj ready. If you contact me, I'm more than willing to help in providing all that's needed to reproduce this. I've seen the deadlock on Mac OS X 10.3.6, my main development OS. For what it's worth, I also tried this with python 2.3.4 (including threadmodule.c patch made in September, related to GIL function usage). ---------------------------------------------------------------------- >Comment By: Andi Vajda (andivajda) Date: 2004-12-03 19:42 Message: Logged In: YES user_id=1139346 I've been running the same test loop on Gentoo/2.6/python 2.4 and was not able to get it to deadlock so far. This bug could be limited to Mac OS X. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-03 19:10 Message: Logged In: YES user_id=1139346 I verified this now with python 2.4 final. It still happens as tested on Mac OS X. I was also able to narrow it down to a unit test, that when run repeatedly will eventually lock up. It is attached. If you need assistance building PyLucene from sources, or want me to provide a binary, let me know. At the moment, to reproduce this bug, it is best to build PyLucene from subversion. See http://pylucene.osafoundation.org for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 From noreply at sourceforge.net Sat Dec 4 05:29:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 05:29:49 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-03 23:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 18:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sat Dec 4 05:55:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 05:55:34 2004 Subject: [ python-Bugs-947894 ] calendar.weekheader() undocumented Message-ID: Bugs item #947894, was opened at 2004-05-04 14:20 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947894&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) >Assigned to: Walter D?rwald (doerwalter) Summary: calendar.weekheader() undocumented Initial Comment: http://www.python.org/doc/current/lib/module-calendar.html makes no mention of calendar.weekheader() ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-12-03 23:55 Message: Logged In: YES user_id=3066 The patch looks good to me. Walter, can you commit on the trunk and the release24-maint branch? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-02 14:53 Message: Logged In: YES user_id=89016 How about the following patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947894&group_id=5470 From noreply at sourceforge.net Sat Dec 4 10:37:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 10:37:16 2004 Subject: [ python-Bugs-1077302 ] test_macostools failure on OS X Message-ID: Bugs item #1077302, was opened at 2004-12-02 15:24 Message generated for change (Comment added) made by webperf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Ian Holsman (webperf) Date: 2004-12-04 20:37 Message: Logged In: YES user_id=5209 Python 2.4 (#1, Dec 2 2004, 11:53:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.prefix /Library/Frameworks/Python.framework/Versions/2.4 This directory doesn't exist. the make test uses DYLD_FRAMEWORK_PATH ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-04 09:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-03 21:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 21:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 21:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Sat Dec 4 12:43:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 12:43:40 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-02 06:40 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 20:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 13:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-02 08:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sat Dec 4 12:46:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 12:46:22 2004 Subject: [ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit Message-ID: Bugs item #1061968, was opened at 2004-11-07 16:30 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Category: Threads Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-12-04 11:46 Message: Logged In: YES user_id=4771 Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3. Closing the bug report... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-02 16:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 07:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 06:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-11-08 14:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-08 04:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-08 01:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 22:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 22:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-07 19:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurrent() call by a call to PyGILState_Release(), and the latter-- like Python before rev 2.41 --does *not* hold the GIL when it decides to delete the tstate. That's the source of the timing hole you're falling into here. Offhand I'm not sure what to do about it, because I'm not familiar with the other bug Mark was trying to fix with rev 2.59. I'm assigning to Mark under the hope that it will be instantly obvious to him. Mark, if it's not, please assign it to me, and I'll try to work it all out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 From noreply at sourceforge.net Sat Dec 4 15:42:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 15:42:41 2004 Subject: [ python-Bugs-1078905 ] Docs for run() methods are misleading Message-ID: Bugs item #1078905, was opened at 2004-12-04 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for run() methods are misleading Initial Comment: In the unittest module, the methods TestCase.run() and TestSuite.run() are not very useful and the documentation for them is misleading. I'm not sure whether to call this a problem with the docs or the code, but I think the easiest fix is to change the docs. >From the documentation, you would think that to specialize the way a TestCase or TestSuite is run, you should override the run() methods. For example, you might try this: The output from this program is just My test The problem is that the run() methods are never used by the rest of the framework. In both cases, run() is equivalent to __call__(), and it is __call__() that is actually used by the rest of the framework. To get the expected output, change 'run' to '__call__' in four places, then you will see this: Suite start MyTests run My test Suite end I suggest that, at a minimum, the documentation should be changed to refer to __call__() instead of run for these two classes. Possibly the code should be changed to either get rid of run() or actually use it, but I'm not so sure this can be done without breaking existing usage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 From noreply at sourceforge.net Sat Dec 4 15:43:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 15:43:06 2004 Subject: [ python-Bugs-1078905 ] Docs for unittest run() methods are misleading Message-ID: Bugs item #1078905, was opened at 2004-12-04 14:42 Message generated for change (Settings changed) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) >Summary: Docs for unittest run() methods are misleading Initial Comment: In the unittest module, the methods TestCase.run() and TestSuite.run() are not very useful and the documentation for them is misleading. I'm not sure whether to call this a problem with the docs or the code, but I think the easiest fix is to change the docs. >From the documentation, you would think that to specialize the way a TestCase or TestSuite is run, you should override the run() methods. For example, you might try this: The output from this program is just My test The problem is that the run() methods are never used by the rest of the framework. In both cases, run() is equivalent to __call__(), and it is __call__() that is actually used by the rest of the framework. To get the expected output, change 'run' to '__call__' in four places, then you will see this: Suite start MyTests run My test Suite end I suggest that, at a minimum, the documentation should be changed to refer to __call__() instead of run for these two classes. Possibly the code should be changed to either get rid of run() or actually use it, but I'm not so sure this can be done without breaking existing usage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 From noreply at sourceforge.net Sat Dec 4 16:47:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 16:47:37 2004 Subject: [ python-Bugs-1078919 ] Email.Header encodes non-ASCII content incorrectly Message-ID: Bugs item #1078919, was opened at 2004-12-04 07:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tessa Lau (tlau) Assigned to: Nobody/Anonymous (nobody) Summary: Email.Header encodes non-ASCII content incorrectly Initial Comment: I'm generating a MIME message with an attachment whose filename includes non-ASCII characters. I create the MIME header as follows: msg.add_header('Content-Disposition', 'attachment', filename=u'Fu\xdfballer_sind_klug.ppt') The Python-generated header looks like this: Content-disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IkZ1w59iYWxsZXJf?= =?utf-8?q?sind=5Fklug=2Eppt=22?= I sent messages with this header to Gmail, evolution, and thunderbird, and none of them correctly decode that header to suggest the correct default filename. However, I've found that those three mailers do behave correctly when the header looks like this instead: Content-disposition: attachment; filename="=?iso-8859-1?q?Fu=DFballer=5Fsind=5Fklug=2Eppt?=" Is there a way to make Python's email module generate a Content-disposition header that works with common MUAs? I know I can manually encode the filename before passing it to add_header(), but it seems that Python should be doing this for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470 From noreply at sourceforge.net Sat Dec 4 18:47:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 18:47:30 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-12-01 02:45 Message generated for change (Comment added) made by edcjones You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- Comment By: Edward C. Jones (edcjones) Date: 2004-12-04 17:47 Message: Logged In: YES user_id=58796 I am having the same problem with Mandrake 10.1. I have an AMD chip with at least a i686 architecture. My Mandrake 10.1 is set at security level 3. In the past (RedHat, Gentoo), I have installed programs from source as follows: 1. su to root. 2. Copy the tar ball (.tgz, .tar.gz, or .tar.bz2) into /usr/local/src. 3. Expand the tar ball. 4. cd to the top directory of the new source tree. 5. Follow the directions given there. For Mandrake 10.1, this process failed when installing Python 2.4. The failure occured during "make test" in test_shutil.py with the same error message as above in this thread. Nigel said above that "This failure happens only when testing as root, because then permissions don't have usual meaning". Have the meaning of the root permissions changed? What do the root permissions now mean? Is this documented somewhere? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 11:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 21:35 Message: Logged In: YES user_id=512388 Same here. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:11 Message: Logged In: YES user_id=192186 Same happends on i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Sat Dec 4 20:44:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 20:44:08 2004 Subject: [ python-Bugs-1079011 ] Incorrect error message (somewhat) Message-ID: Bugs item #1079011, was opened at 2004-12-04 20:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect error message (somewhat) Initial Comment: Comparing complex numbers with cmp yields: >>> cmp(1+3j, 1+3j) 0 >>> cmp(1+3j, 3+4j) Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= Well, I didn't use <, <=, > or >=. It's not a major bug, but it doesn't look too nice... would it be possible to return NotImplemented? Or would that be semantically incorrect? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 From noreply at sourceforge.net Sat Dec 4 21:04:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 21:04:17 2004 Subject: [ python-Bugs-1077302 ] test_macostools failure on OS X Message-ID: Bugs item #1077302, was opened at 2004-12-01 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-04 12:04 Message: Logged In: YES user_id=357491 Aha! That missing directory is the problem. If you read the docs on what macostools.mkalias does is it creates a Finder shortcut for a location. Well, it fails because it can't make a shortcut to a non-existent location. OK, I have uploaded a patch that basically just checks for sys.prefix's existence; if it is missing the test just returns without running. I figured creating the directory would be the improper thing to do since ``make install`` will handle that and use specific permissions I didn't want to override by having the test create it. If you can, Ian, apply the patch and let me know if it fixes the issue. ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-04 01:37 Message: Logged In: YES user_id=5209 Python 2.4 (#1, Dec 2 2004, 11:53:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.prefix /Library/Frameworks/Python.framework/Versions/2.4 This directory doesn't exist. the make test uses DYLD_FRAMEWORK_PATH ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 14:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-03 02:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 02:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 02:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Sat Dec 4 21:13:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 21:13:14 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 22:40 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 21:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 12:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 05:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-02 00:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sat Dec 4 21:38:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 21:38:26 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 04:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 23:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sat Dec 4 21:58:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 21:59:03 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 15:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 15:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 15:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 06:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-03 23:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 18:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sat Dec 4 22:05:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 22:05:21 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-04 22:05 Message: Logged In: YES user_id=192186 I meant, that as root you can do anything regardless actual file permissions: as root: # mkdir test # touch test/file # chmod 400 test # ll -d test dr-------- 2 root root 4096 2004-12-04 22:00 test # rm -rf test # as user: $ mkdir test $ touch test/file $ chmod 400 test $ ll -d test dr-------- 2 michal michal 4096 2004-12-04 22:05 test $ rm -rf test rm: cannot chdir from `.' to `test': Permission denied $ ---------------------------------------------------------------------- Comment By: Edward C. Jones (edcjones) Date: 2004-12-04 18:47 Message: Logged In: YES user_id=58796 I am having the same problem with Mandrake 10.1. I have an AMD chip with at least a i686 architecture. My Mandrake 10.1 is set at security level 3. In the past (RedHat, Gentoo), I have installed programs from source as follows: 1. su to root. 2. Copy the tar ball (.tgz, .tar.gz, or .tar.bz2) into /usr/local/src. 3. Expand the tar ball. 4. cd to the top directory of the new source tree. 5. Follow the directions given there. For Mandrake 10.1, this process failed when installing Python 2.4. The failure occured during "make test" in test_shutil.py with the same error message as above in this thread. Nigel said above that "This failure happens only when testing as root, because then permissions don't have usual meaning". Have the meaning of the root permissions changed? What do the root permissions now mean? Is this documented somewhere? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:35 Message: Logged In: YES user_id=512388 Same here. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Sat Dec 4 22:11:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 22:11:53 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-04 21:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 20:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 04:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 23:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sat Dec 4 22:24:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 4 22:25:34 2004 Subject: [ python-Bugs-1078905 ] Docs for unittest run() methods are misleading Message-ID: Bugs item #1078905, was opened at 2004-12-04 09:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 >Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for unittest run() methods are misleading Initial Comment: In the unittest module, the methods TestCase.run() and TestSuite.run() are not very useful and the documentation for them is misleading. I'm not sure whether to call this a problem with the docs or the code, but I think the easiest fix is to change the docs. >From the documentation, you would think that to specialize the way a TestCase or TestSuite is run, you should override the run() methods. For example, you might try this: The output from this program is just My test The problem is that the run() methods are never used by the rest of the framework. In both cases, run() is equivalent to __call__(), and it is __call__() that is actually used by the rest of the framework. To get the expected output, change 'run' to '__call__' in four places, then you will see this: Suite start MyTests run My test Suite end I suggest that, at a minimum, the documentation should be changed to refer to __call__() instead of run for these two classes. Possibly the code should be changed to either get rid of run() or actually use it, but I'm not so sure this can be done without breaking existing usage. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 16:24 Message: Logged In: YES user_id=80475 Fixed. See Lib/unittest.py 1.37 and 1.36.2.1 Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 From noreply at sourceforge.net Sun Dec 5 00:29:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 00:29:24 2004 Subject: [ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4" Message-ID: Bugs item #1079134, was opened at 2004-12-04 23:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) Assigned to: Nobody/Anonymous (nobody) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 From noreply at sourceforge.net Sun Dec 5 01:39:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 01:39:26 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 19:39 Message: Logged In: YES user_id=80475 No, I simply tried the OP's example and reported its behavior on my system. If you don't want to create a new test file, try adding this on to test_subprocess. Yes, I read the patch. Yes, I forgot you added the assertion already. So are you going commit or wait for an engraved invitation? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 16:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 15:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 15:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 15:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 06:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-03 23:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 18:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sun Dec 5 01:43:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 01:44:05 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-23 03:34 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Peter ?strand (astrand) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Sun Dec 5 03:45:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 03:45:56 2004 Subject: [ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4" Message-ID: Bugs item #1079134, was opened at 2004-12-04 18:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) Assigned to: Nobody/Anonymous (nobody) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-04 21:45 Message: Logged In: YES user_id=31435 The truth (which is more involved than your characterization) is in the NEWS file: """ SF bug #1028306: Trying to compare a ``datetime.date`` to a ``datetime.datetime`` mistakenly compared only the year, month and day. Now it acts like a mixed-type comparison: ``False`` for ``==``, ``True`` for ``!=``, and raises ``TypeError`` for other comparison operators. Because datetime is a subclass of date, comparing only the base class (date) members can still be done, if that's desired, by forcing using of the approprate date method; e.g., ``a_date.__eq__(a_datetime)`` is true if and only if the year, month and day members of ``a_date`` and ``a_datetime`` are equal. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 From noreply at sourceforge.net Sun Dec 5 04:30:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 04:30:28 2004 Subject: [ python-Bugs-1076485 ] Another message that croaks email.FeedParser Message-ID: Bugs item #1076485, was opened at 2004-11-30 23:00 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076485&group_id=5470 Category: Python Library >Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Another message that croaks email.FeedParser Initial Comment: The attached message causes a TypeError exception with the email.FeedParser class that comes with Python 2.4. The traceback I get is: Traceback (most recent call last): File "", line 1, in ? File "/Users/skip/local/lib/python2.4/mailbox.py", line 35, in next return self.factory(_Subfile(self.fp, start, stop)) File "/Users/skip/local/lib/python2.4/site-packages/spambayes/mboxutils.py", line 129, in get_message msg = email.message_from_string(obj) File "/Users/skip/local/lib/python2.4/email/__init__.py", line 43, in message_from_string return Parser(*args, **kws).parsestr(s) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 79, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 68, in parse feedparser.feed(data) File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 146, in feed self._call_parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 150, in _call_parse self._parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 331, in _parsegen for retval in self._parsegen(): File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 228, in _parsegen for retval in self._parsegen(): File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 190, in _parsegen for line in self._input: File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 119, in next line = self.readline() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 79, in readline if ateof(line): TypeError: expected string or buffer ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-12-04 22:30 Message: Logged In: YES user_id=12800 I have a fix for this which I'll commit to the CVS head and release24-maint. The problem is caused by a place where readline() could have returned NeedsMoreData, but that case wasn't being checked. If you use email.message_from_*, that uses the Parser interface, which reads the text in 8192 byte chunks. The test message just happens to have the first 8192 chunk fall inside a line in the message/delivery-status, which was the block that had the readline() that failed to check for NeedsMoreData. BTW, you can work around this by using the FeedParser interface directly, since that doesn't chunk the input. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076485&group_id=5470 From noreply at sourceforge.net Sun Dec 5 05:15:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 05:16:03 2004 Subject: [ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4) Message-ID: Bugs item #1075703, was opened at 2004-11-29 17:54 Message generated for change (Comment added) made by andivajda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 Category: Threads Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andi Vajda (andivajda) Assigned to: Nobody/Anonymous (nobody) Summary: PyGILState_Ensure() deadlocks (ver 2.4) Initial Comment: PyLucene (http://pylucene.osafoundation.org) wraps libgcj with python. Python objects are also wrapped by java objects. The ref count of the python is incremented in the wrapping java object constructor and is decremented in the wrapping java object's finalize() method. Yes, finalize() is not a reliable means of cleaning memory up but, so far, I wasn't able to figure out a better way to do this. The finalize() method runs in its own libgcj finalizer thread. It has to acquire the GIL before it can call Py_DECREF() is my understanding. The java finalize() calls this code in PyLucene: void finalizeObject(PyObject *object) { #if PY_VERSION_HEX >= 0x02040000 PyGILState_STATE state = PyGILState_Ensure(); Py_DECREF(object); PyGILState_Release(state); #endif } When compiled with python 2.4c1, this mostly works. Except that it deadlocks, every now and then. If I comment this code out, no deadlock. I also verified that the finalizer is called at most once per such object. I realize that reproducing this bug maybe hard, building PyLucene is not particularly easy, unless you have gcj ready. If you contact me, I'm more than willing to help in providing all that's needed to reproduce this. I've seen the deadlock on Mac OS X 10.3.6, my main development OS. For what it's worth, I also tried this with python 2.3.4 (including threadmodule.c patch made in September, related to GIL function usage). ---------------------------------------------------------------------- >Comment By: Andi Vajda (andivajda) Date: 2004-12-04 20:15 Message: Logged In: YES user_id=1139346 I finally tracked down this bug to gcj bug 16478 which is fixed in gcj version >= 3.4.2. I am hence closing this python bug as invalid. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-03 19:42 Message: Logged In: YES user_id=1139346 I've been running the same test loop on Gentoo/2.6/python 2.4 and was not able to get it to deadlock so far. This bug could be limited to Mac OS X. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-03 19:10 Message: Logged In: YES user_id=1139346 I verified this now with python 2.4 final. It still happens as tested on Mac OS X. I was also able to narrow it down to a unit test, that when run repeatedly will eventually lock up. It is attached. If you need assistance building PyLucene from sources, or want me to provide a binary, let me know. At the moment, to reproduce this bug, it is best to build PyLucene from subversion. See http://pylucene.osafoundation.org for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 From noreply at sourceforge.net Sun Dec 5 11:05:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 11:05:22 2004 Subject: [ python-Bugs-1077302 ] test_macostools failure on OS X Message-ID: Bugs item #1077302, was opened at 2004-12-02 15:24 Message generated for change (Comment added) made by webperf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Ian Holsman (webperf) Date: 2004-12-05 21:05 Message: Logged In: YES user_id=5209 your patch did the trick Thanks Brett! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-05 07:04 Message: Logged In: YES user_id=357491 Aha! That missing directory is the problem. If you read the docs on what macostools.mkalias does is it creates a Finder shortcut for a location. Well, it fails because it can't make a shortcut to a non-existent location. OK, I have uploaded a patch that basically just checks for sys.prefix's existence; if it is missing the test just returns without running. I figured creating the directory would be the improper thing to do since ``make install`` will handle that and use specific permissions I didn't want to override by having the test create it. If you can, Ian, apply the patch and let me know if it fixes the issue. ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-04 20:37 Message: Logged In: YES user_id=5209 Python 2.4 (#1, Dec 2 2004, 11:53:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.prefix /Library/Frameworks/Python.framework/Versions/2.4 This directory doesn't exist. the make test uses DYLD_FRAMEWORK_PATH ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-04 09:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-03 21:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 21:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 21:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Sun Dec 5 11:30:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 11:30:40 2004 Subject: [ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault Message-ID: Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault exarkun@boson:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-05 10:30 Message: Logged In: YES user_id=6656 I'm waiting until I'm not behind a modem at my parents' house :) Tomorrow. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-05 00:39 Message: Logged In: YES user_id=80475 No, I simply tried the OP's example and reported its behavior on my system. If you don't want to create a new test file, try adding this on to test_subprocess. Yes, I read the patch. Yes, I forgot you added the assertion already. So are you going commit or wait for an engraved invitation? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 21:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 20:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 04:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2004-12-01 23:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 From noreply at sourceforge.net Sun Dec 5 11:35:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 11:35:51 2004 Subject: [ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4) Message-ID: Bugs item #1075703, was opened at 2004-11-30 01:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 Category: Threads Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Andi Vajda (andivajda) Assigned to: Nobody/Anonymous (nobody) Summary: PyGILState_Ensure() deadlocks (ver 2.4) Initial Comment: PyLucene (http://pylucene.osafoundation.org) wraps libgcj with python. Python objects are also wrapped by java objects. The ref count of the python is incremented in the wrapping java object constructor and is decremented in the wrapping java object's finalize() method. Yes, finalize() is not a reliable means of cleaning memory up but, so far, I wasn't able to figure out a better way to do this. The finalize() method runs in its own libgcj finalizer thread. It has to acquire the GIL before it can call Py_DECREF() is my understanding. The java finalize() calls this code in PyLucene: void finalizeObject(PyObject *object) { #if PY_VERSION_HEX >= 0x02040000 PyGILState_STATE state = PyGILState_Ensure(); Py_DECREF(object); PyGILState_Release(state); #endif } When compiled with python 2.4c1, this mostly works. Except that it deadlocks, every now and then. If I comment this code out, no deadlock. I also verified that the finalizer is called at most once per such object. I realize that reproducing this bug maybe hard, building PyLucene is not particularly easy, unless you have gcj ready. If you contact me, I'm more than willing to help in providing all that's needed to reproduce this. I've seen the deadlock on Mac OS X 10.3.6, my main development OS. For what it's worth, I also tried this with python 2.3.4 (including threadmodule.c patch made in September, related to GIL function usage). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-05 10:35 Message: Logged In: YES user_id=6656 Speaking as a Python developer, phew :) ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-05 04:15 Message: Logged In: YES user_id=1139346 I finally tracked down this bug to gcj bug 16478 which is fixed in gcj version >= 3.4.2. I am hence closing this python bug as invalid. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-04 03:42 Message: Logged In: YES user_id=1139346 I've been running the same test loop on Gentoo/2.6/python 2.4 and was not able to get it to deadlock so far. This bug could be limited to Mac OS X. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-04 03:10 Message: Logged In: YES user_id=1139346 I verified this now with python 2.4 final. It still happens as tested on Mac OS X. I was also able to narrow it down to a unit test, that when run repeatedly will eventually lock up. It is attached. If you need assistance building PyLucene from sources, or want me to provide a binary, let me know. At the moment, to reproduce this bug, it is best to build PyLucene from subversion. See http://pylucene.osafoundation.org for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 From noreply at sourceforge.net Sun Dec 5 15:43:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 15:43:48 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-23 09:34 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Peter ?strand (astrand) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2004-12-05 15:43 Message: Logged In: YES user_id=344921 This seems to be a Cygwin bug: p.stdout.read() only returns a partial result. Another p.stdout.read() is necessary to retrieve all data. fileobject.read should return all data, though. It doesn't, because fread() is behaving strange: It returns a short read, but neither feof() nor ferror() is set. This is wrong: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered." One strange thing is that this only happens if close-on-exec is used for the error pipe. Perhaps a race condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:42:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:42:23 2004 Subject: [ python-Bugs-1078919 ] Email.Header encodes non-ASCII content incorrectly Message-ID: Bugs item #1078919, was opened at 2004-12-04 16:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tessa Lau (tlau) Assigned to: Nobody/Anonymous (nobody) Summary: Email.Header encodes non-ASCII content incorrectly Initial Comment: I'm generating a MIME message with an attachment whose filename includes non-ASCII characters. I create the MIME header as follows: msg.add_header('Content-Disposition', 'attachment', filename=u'Fu\xdfballer_sind_klug.ppt') The Python-generated header looks like this: Content-disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IkZ1w59iYWxsZXJf?= =?utf-8?q?sind=5Fklug=2Eppt=22?= I sent messages with this header to Gmail, evolution, and thunderbird, and none of them correctly decode that header to suggest the correct default filename. However, I've found that those three mailers do behave correctly when the header looks like this instead: Content-disposition: attachment; filename="=?iso-8859-1?q?Fu=DFballer=5Fsind=5Fklug=2Eppt?=" Is there a way to make Python's email module generate a Content-disposition header that works with common MUAs? I know I can manually encode the filename before passing it to add_header(), but it seems that Python should be doing this for me. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:42 Message: Logged In: YES user_id=21627 The fact that neither Gmail, evolution, or thunderbird can decode this string properly does not mean that Python encodes it incorrectly. I cannot see an error in this header - although I can sympathize with the developers of the MUAs that this is a non-obvious usage of the standards. So I recommend you report this as a bug to the authors of the MUAs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:45:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:45:47 2004 Subject: [ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues Message-ID: Bugs item #1074873, was opened at 2004-11-28 23:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 Category: Installation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: dmerrill (davemerrill) Assigned to: Nobody/Anonymous (nobody) Summary: Windows 2.4c1 installer default location issues Initial Comment: On win2k sp4, python-2.4c1.msi defaults to installing in c:\Python24\, rather than the more usual c:\Program Files\Python24\ like 2.3.3 did. When I pointed it to c:\Program Files\Python24\, it installed there, but I couldn't get IDLE to run; silent failure. Not sure if there were other similar issues. Uninstalled, and reinstalled to the default location, all is (apparently, so far) well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:45 Message: Logged In: YES user_id=21627 Not sure what the bug is that you are reporting here. It is intentional that Python installs into c:\python24, not into Program Files. The IDLE problem indicates a bug, of course. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 17:30 Message: Logged In: YES user_id=832557 More details on the IDLE issue in bug report 1076861, here ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:46:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:46:28 2004 Subject: [ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP Message-ID: Bugs item #1076861, was opened at 2004-12-01 17:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) >Assigned to: Martin v. L?wis (loewis) Summary: Bad IDLE shortcut by 2.4 installer on XP Initial Comment: There is a problem with the Python 2.4 installer on Windows XP. The IDLE shortcut set up by the installer in the StartUp folder does not work. If the shortcut is removed and recreated manually, it works fine. That was *after* a complete reinstall of Python 2.4 and after removing the previous version of Python 2.3 on the machine. With Python 2.3 present, the IDLE shortcut installed by Python 2.4 runs the 2.3 version. See also and ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:49:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:49:08 2004 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 05:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) >Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 03:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 13:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:49:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:49:37 2004 Subject: [ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues Message-ID: Bugs item #1074873, was opened at 2004-11-28 23:34 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 Category: Installation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: dmerrill (davemerrill) >Assigned to: Martin v. L?wis (loewis) Summary: Windows 2.4c1 installer default location issues Initial Comment: On win2k sp4, python-2.4c1.msi defaults to installing in c:\Python24\, rather than the more usual c:\Program Files\Python24\ like 2.3.3 did. When I pointed it to c:\Program Files\Python24\, it installed there, but I couldn't get IDLE to run; silent failure. Not sure if there were other similar issues. Uninstalled, and reinstalled to the default location, all is (apparently, so far) well. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:45 Message: Logged In: YES user_id=21627 Not sure what the bug is that you are reporting here. It is intentional that Python installs into c:\python24, not into Program Files. The IDLE problem indicates a bug, of course. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 17:30 Message: Logged In: YES user_id=832557 More details on the IDLE issue in bug report 1076861, here ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:50:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:50:36 2004 Subject: [ python-Bugs-1071594 ] Windows msi doesn't install site-packages directory Message-ID: Bugs item #1071594, was opened at 2004-11-23 11:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071594&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anna Ravenscroft (annarave) Assigned to: Nobody/Anonymous (nobody) Summary: Windows msi doesn't install site-packages directory Initial Comment: On Windows XP, I downloaded and installed python-2.4c1.msi, both the "single user" and the "all users" versions. It did not create a site-packages directory in Lib (or in libs - I checked). I found this surprising behavior. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:50 Message: Logged In: YES user_id=21627 This was fixed in the final 2.4 msi. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071594&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:51:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:51:40 2004 Subject: [ python-Bugs-1067732 ] wininst --install-script leaves residual files on C:Mime-Version: 1.0 Message-ID: Bugs item #1067732, was opened at 2004-11-17 01:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067732&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J Livingston (jlivingston) >Assigned to: Thomas Heller (theller) Summary: wininst --install-script leaves residual files on C: Initial Comment: I'm running Python 2.3.4 and using distutils ( __revision__ of 1.58 2003/02/19) on WinXP SP2 to create a windows .exe installer. Both installation and removal of the package result in a residual file on the root of C: drive. This seems to be directly related to the use of the windows install-script which is provided with the --install-script switch. The residual file has a naming convention of sxxx where 'xxx' is any alphanumeric combination. There is never an extension on the file name. On installation, the residual file contains the same text the install-script prints in the install screen window. On removal, the residual file is empty (the install-script does not print anything when removing.) Users attempting to execute the installer from a network drive experience installer crash as they do not have file system permission to generate the residual file.. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:51 Message: Logged In: YES user_id=21627 Thomas, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067732&group_id=5470 From noreply at sourceforge.net Sun Dec 5 20:53:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 20:53:39 2004 Subject: [ python-Bugs-1067153 ] win32con missing codes VK_VOLUME_MUTE, VK_BROWSER_BACK, ... Message-ID: Bugs item #1067153, was opened at 2004-11-16 07:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067153&group_id=5470 Category: Windows >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeff Connelly aka shellreef (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: win32con missing codes VK_VOLUME_MUTE, VK_BROWSER_BACK, ... Initial Comment: win32con is missing many virtual keycode constants: # from WinUser.h win32con.MOUSEEVENTF_XDOWN = 0x0080 win32con.MOUSEEVENTF_XUP = 0x0100 win32con.MOUSEEVENTF_WHEEL = 0x0800 win32con.VK_XBUTTON1 = 0x05 win32con.VK_XBUTTON2 = 0x06 win32con.VK_VOLUME_MUTE = 0xAD win32con.VK_VOLUME_DOWN = 0xAE win32con.VK_VOLUME_UP = 0xAF win32con.VK_MEDIA_NEXT_TRACK = 0xB0 win32con.VK_MEDIA_PREV_TRACK = 0xB1 win32con.VK_MEDIA_PLAY_PAUSE = 0xB3 win32con.VK_BROWSER_BACK = 0xA6 win32con.VK_BROWSER_FORWARD = 0xA7 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:53 Message: Logged In: YES user_id=21627 win32con is not supported in the Python project. Please report this to https://sourceforge.net/projects/pywin32/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067153&group_id=5470 From noreply at sourceforge.net Sun Dec 5 21:02:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 21:02:30 2004 Subject: [ python-Bugs-1079545 ] python-2.4.msi install error Message-ID: Bugs item #1079545, was opened at 2004-12-05 20:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: maharal (maharal) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.4.msi install error Initial Comment: when I try to install python2.4. using the python- 2.4.msi-file, it stopps with the error message: "The installer has encountered an unexpected error installing this package. This may inidicate a problem with this package. The error code is 2738" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 From noreply at sourceforge.net Sun Dec 5 21:40:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 5 21:40:51 2004 Subject: [ python-Bugs-1078919 ] Email.Header encodes non-ASCII content incorrectly Message-ID: Bugs item #1078919, was opened at 2004-12-04 10:47 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tessa Lau (tlau) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Email.Header encodes non-ASCII content incorrectly Initial Comment: I'm generating a MIME message with an attachment whose filename includes non-ASCII characters. I create the MIME header as follows: msg.add_header('Content-Disposition', 'attachment', filename=u'Fu\xdfballer_sind_klug.ppt') The Python-generated header looks like this: Content-disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IkZ1w59iYWxsZXJf?= =?utf-8?q?sind=5Fklug=2Eppt=22?= I sent messages with this header to Gmail, evolution, and thunderbird, and none of them correctly decode that header to suggest the correct default filename. However, I've found that those three mailers do behave correctly when the header looks like this instead: Content-disposition: attachment; filename="=?iso-8859-1?q?Fu=DFballer=5Fsind=5Fklug=2Eppt?=" Is there a way to make Python's email module generate a Content-disposition header that works with common MUAs? I know I can manually encode the filename before passing it to add_header(), but it seems that Python should be doing this for me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 14:42 Message: Logged In: YES user_id=21627 The fact that neither Gmail, evolution, or thunderbird can decode this string properly does not mean that Python encodes it incorrectly. I cannot see an error in this header - although I can sympathize with the developers of the MUAs that this is a non-obvious usage of the standards. So I recommend you report this as a bug to the authors of the MUAs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470 From noreply at sourceforge.net Mon Dec 6 07:28:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 07:28:26 2004 Subject: [ python-Bugs-1077302 ] test_macostools failure on OS X Message-ID: Bugs item #1077302, was opened at 2004-12-01 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ian Holsman (webperf) >Assigned to: Brett Cannon (bcannon) Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-05 22:28 Message: Logged In: YES user_id=357491 OK, fixed in HEAD as rev. 1.6, 2.4 as rev. 1.5.18.1, and 2.3 as rev. 1.5.14.1 (damn that is a lot of branches). Thanks for helping out with this, Ian. ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-05 02:05 Message: Logged In: YES user_id=5209 your patch did the trick Thanks Brett! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-04 12:04 Message: Logged In: YES user_id=357491 Aha! That missing directory is the problem. If you read the docs on what macostools.mkalias does is it creates a Finder shortcut for a location. Well, it fails because it can't make a shortcut to a non-existent location. OK, I have uploaded a patch that basically just checks for sys.prefix's existence; if it is missing the test just returns without running. I figured creating the directory would be the improper thing to do since ``make install`` will handle that and use specific permissions I didn't want to override by having the test create it. If you can, Ian, apply the patch and let me know if it fixes the issue. ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-04 01:37 Message: Logged In: YES user_id=5209 Python 2.4 (#1, Dec 2 2004, 11:53:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.prefix /Library/Frameworks/Python.framework/Versions/2.4 This directory doesn't exist. the make test uses DYLD_FRAMEWORK_PATH ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 14:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? ---------------------------------------------------------------------- Comment By: Ian Holsman (webperf) Date: 2004-12-03 02:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 02:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? ---------------------------------------------------------------------- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 02:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 20:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As for the test_macostools failure, I will need to recompile with --enable- toolbox-glue to see if I get the failure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 From noreply at sourceforge.net Mon Dec 6 08:04:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 08:04:21 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 13:16 Message generated for change (Comment added) made by connelly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Tim Peters (tim_one) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- Comment By: Connelly (connelly) Date: 2004-12-06 07:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 18:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 07:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 05:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 16:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 15:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 15:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 13:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Mon Dec 6 09:14:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 09:14:41 2004 Subject: [ python-Bugs-947894 ] calendar.weekheader() undocumented Message-ID: Bugs item #947894, was opened at 2004-05-04 20:20 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947894&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Walter D?rwald (doerwalter) Summary: calendar.weekheader() undocumented Initial Comment: http://www.python.org/doc/current/lib/module-calendar.html makes no mention of calendar.weekheader() ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-06 09:14 Message: Logged In: YES user_id=89016 Checked in as: Doc/lib/libcalendar.tex 1.19 Doc/lib/libcalendar.tex 1.18.4.1 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-12-04 05:55 Message: Logged In: YES user_id=3066 The patch looks good to me. Walter, can you commit on the trunk and the release24-maint branch? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-06-02 20:53 Message: Logged In: YES user_id=89016 How about the following patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947894&group_id=5470 From noreply at sourceforge.net Mon Dec 6 21:53:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 21:53:36 2004 Subject: [ python-Bugs-1071513 ] test_sutil fails on cygwin Message-ID: Bugs item #1071513, was opened at 2004-11-23 09:29 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: test_sutil fails on cygwin Initial Comment: [10:23] $python -V Python 2.4c1 [10:25] $python -c 'from test.test_shutil import test_main; test_main()' -v test_dont_copy_file_onto_link_to_itself (test.test_shutil.TestShutil) ... ok test_dont_move_dir_in_itself (test.test_shutil.TestShutil) ... ok test_on_error (test.test_shutil.TestShutil) ... ERROR test_rmtree_dont_delete_file (test.test_shutil.TestShutil) ... ok test_rmtree_errors (test.test_shutil.TestShutil) ... ok ====================================================================== ERROR: test_on_error (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_shutil.py", line 34, in test_on_error os.chmod(TESTFN, old_dir_mode) OSError: [Errno 2] No such file or directory: '@test' ---------------------------------------------------------------------- Ran 5 tests in 0.036s FAILED (errors=1) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_shutil.py", line 99, in test_main test_support.run_unittest(TestShutil) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 275, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/lib/python2.4/test/test_shutil.py", line 34, in test_on_error os.chmod(TESTFN, old_dir_mode) OSError: [Errno 2] No such file or directory: '@test' ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 21:53 Message: Logged In: YES user_id=469548 Closing this. I've added a comment to the source pointing to here. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-23 11:04 Message: Logged In: YES user_id=469548 Hmm, strange. I should perhaps have provided the link that I based this on: http://www.cygwin.com/faq/faq_3.html#SEC41. The thing is, the test needs a permissions error so it can check shutil.rmtree's error handling. Setting the permissions for the directory to stat.S_IREAD (0400) doesn't seem to prevent Python from removing the file. I don't know enough about the intricacies of Cygwin+chmod (I don't have a Windows machine) to make this work reliably, but I'll be happy to take another patch. Note, by the way, that this is not a problem with shutil itself, but just with the test. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-11-23 10:41 Message: Logged In: YES user_id=358087 I disagree, chmod seems to work: [11:35] - adp96: touch zzz [11:35] - adp96: ll zzz -rw-rw-rw- 1 mikit Domain U 0 Nov 23 11:35 zzz [11:35] - adp96: python -c 'from os import chmod; chmod("zzz", 0700)' [11:36] - adp96: ll zzz -rwx------ 1 mikit Domain U 0 Nov 23 11:35 zzz ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-23 10:29 Message: Logged In: YES user_id=469548 Ah, seems like chmod doesn't work on Cygwin. That means there's no way to run this test there, so I've changed it so that it doesn't run on Cygwin anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071513&group_id=5470 From noreply at sourceforge.net Mon Dec 6 22:22:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 22:22:59 2004 Subject: [ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1 Message-ID: Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 22:22 Message: Logged In: YES user_id=469548 Fixed by not running this test when running as root. Checked in on both HEAD and release24-maint. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-04 22:05 Message: Logged In: YES user_id=192186 I meant, that as root you can do anything regardless actual file permissions: as root: # mkdir test # touch test/file # chmod 400 test # ll -d test dr-------- 2 root root 4096 2004-12-04 22:00 test # rm -rf test # as user: $ mkdir test $ touch test/file $ chmod 400 test $ ll -d test dr-------- 2 michal michal 4096 2004-12-04 22:05 test $ rm -rf test rm: cannot chdir from `.' to `test': Permission denied $ ---------------------------------------------------------------------- Comment By: Edward C. Jones (edcjones) Date: 2004-12-04 18:47 Message: Logged In: YES user_id=58796 I am having the same problem with Mandrake 10.1. I have an AMD chip with at least a i686 architecture. My Mandrake 10.1 is set at security level 3. In the past (RedHat, Gentoo), I have installed programs from source as follows: 1. su to root. 2. Copy the tar ball (.tgz, .tar.gz, or .tar.bz2) into /usr/local/src. 3. Expand the tar ball. 4. cd to the top directory of the new source tree. 5. Follow the directions given there. For Mandrake 10.1, this process failed when installing Python 2.4. The failure occured during "make test" in test_shutil.py with the same error message as above in this thread. Nigel said above that "This failure happens only when testing as root, because then permissions don't have usual meaning". Have the meaning of the root permissions changed? What do the root permissions now mean? Is this documented somewhere? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. ---------------------------------------------------------------------- Comment By: Pierre (pierre42) Date: 2004-12-01 22:35 Message: Logged In: YES user_id=512388 Same here. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 From noreply at sourceforge.net Mon Dec 6 22:24:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 22:24:23 2004 Subject: [ python-Bugs-853411 ] After fork in subthread, signals are blocked Message-ID: Bugs item #853411, was opened at 2003-12-03 16:55 Message generated for change (Comment added) made by pymonger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 Category: Threads Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: G?ran Uddeborg (goeran) Assigned to: Nobody/Anonymous (nobody) Summary: After fork in subthread, signals are blocked Initial Comment: When a Python program starts a new thread, and this new thread forks, the forked process ingores signals. It will not terminate, or dump core if that would be applicable, when it receives a signal. I attach a test case which illustrates the behaviour. In this example, the child process is sent a SEGV signal from the subthread of the parent process. This should cause the child process to die and produce a core. But execution of the parent program threads finishes, there is still a python process around, continuing to sleep. Apparently, Python subthreads blocks signals. On Linux, /proc/*/status for subthreads includes the line SigBlk: ffffffff7ffbfeff The Python documentation says one should only install signal handlers in the main thread, and only the main thread will recieve signals. So this makes sense. But when the subthread forks, the new process inherits this signal mask, which seems to be incorrect behaviour. I would assume, if Python sets this signal mask for threads, it should also reset it again after a fork. I've seen this on these two platforms: Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32) Python 2.2.1 on Sun Solaris 8 (Sparc) ---------------------------------------------------------------------- Comment By: gmanipon (pymonger) Date: 2004-12-06 21:24 Message: Logged In: YES user_id=1173063 Sorry for the bother. Was there any resolution to this bug report? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-01-26 10:02 Message: Logged In: YES user_id=45365 I have absolutely no idea where the bug could be, someone better versed in the threading ideosyncracies of the various platforms needs to look at this, but I do want to point at hairy_flange's comment that fink-python 2.2.3 on OSX does *not* exhibit the bug (while on other platforms it does). It may be worthwhile to download a fink-python in source form, and see whether they do any configure magic. ---------------------------------------------------------------------- Comment By: Steve Muir (hairy_flange) Date: 2004-01-26 04:04 Message: Logged In: YES user_id=960132 I just submitted a bug report that is a duplicate of this bug (apologies!), I observed the same behaviour with the Python shipped with Mac OS X (Python 2.3), and Python 2.2.2 on RedHat/x86, but Fink Python 2.2.3 for OS X does not have this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853411&group_id=5470 From noreply at sourceforge.net Mon Dec 6 22:49:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 22:49:34 2004 Subject: [ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4" Message-ID: Bugs item #1079134, was opened at 2004-12-05 00:29 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) >Assigned to: A.M. Kuchling (akuchling) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-05 03:45 Message: Logged In: YES user_id=31435 The truth (which is more involved than your characterization) is in the NEWS file: """ SF bug #1028306: Trying to compare a ``datetime.date`` to a ``datetime.datetime`` mistakenly compared only the year, month and day. Now it acts like a mixed-type comparison: ``False`` for ``==``, ``True`` for ``!=``, and raises ``TypeError`` for other comparison operators. Because datetime is a subclass of date, comparing only the base class (date) members can still be done, if that's desired, by forcing using of the approprate date method; e.g., ``a_date.__eq__(a_datetime)`` is true if and only if the year, month and day members of ``a_date`` and ``a_datetime`` are equal. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 From noreply at sourceforge.net Mon Dec 6 22:59:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 22:59:55 2004 Subject: [ python-Bugs-1079545 ] python-2.4.msi install error Message-ID: Bugs item #1079545, was opened at 2004-12-05 21:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: maharal (maharal) >Assigned to: Martin v. L?wis (loewis) Summary: python-2.4.msi install error Initial Comment: when I try to install python2.4. using the python- 2.4.msi-file, it stopps with the error message: "The installer has encountered an unexpected error installing this package. This may inidicate a problem with this package. The error code is 2738" ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:59 Message: Logged In: YES user_id=21627 Can you please try to install VBScript, from http://msdn.microsoft.com/downloads/list/webdev.asp and report whether this works? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 From noreply at sourceforge.net Mon Dec 6 23:21:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 6 23:21:11 2004 Subject: [ python-Bugs-1076515 ] shutil.move clobbers read-only files. Message-ID: Bugs item #1076515, was opened at 2004-12-01 06:40 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move clobbers read-only files. Initial Comment: The summary states it fine. shutil.move happily overwrites read- only files. It looks like it indiscriminately catches OSError, and never bothers to check whether it's a permission error. It'd be nice if permission errors raised an exception that was a subclass of OSError, then it'd be cake to fix this (at least for *nices; I'm not sure about the Windows implications). According to tracker #810879, clobbering read-only files isn't the desired behavior for shutil.copyfile, so I doubt it's desired for shutil.move. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 23:21 Message: Logged In: YES user_id=469548 Your analysis is not correct. On Unix, you need write permission to the *directory* to rename. So the os.rename() call simply succeeds on a read-only file if you have write access to its parent directory. I think we could shield from this by always using the fallback implementation (copy2+unlink(src)), but I'm not sure what the implications of that would be (qua performance and cross-platform issues). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 From noreply at sourceforge.net Tue Dec 7 00:11:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 00:11:13 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 23:02 Message generated for change (Comment added) made by wom-work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 23:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 09:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Tue Dec 7 00:27:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 00:27:37 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 23:02 Message generated for change (Comment added) made by meyering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-06 23:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 23:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 09:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Tue Dec 7 01:33:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 01:33:54 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 23:02 Message generated for change (Comment added) made by wom-work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 00:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-06 23:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 23:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 09:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Tue Dec 7 01:47:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 01:47:09 2004 Subject: [ python-Bugs-955197 ] CFLAGS, CPPFLAGS, LDFLAGS are NOT used when building modules Message-ID: Bugs item #955197, was opened at 2004-05-17 03:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=955197&group_id=5470 Category: Build >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Niki W. Waibel (nikiwaibel) Assigned to: Brett Cannon (bcannon) Summary: CFLAGS, CPPFLAGS, LDFLAGS are NOT used when building modules Initial Comment: i am trying to compile python in solaris 2.8. ncurses incl files and libs are not in theis usual places (/usr/include, /usr/lib)! so i usually set CPPFLAGS, CFLAGS, LDFLAGS and LD_RUN_PATH when compiling programs. that works nicely if all of the automake, autoconf and libtool machinery is used. but it seems that the python team has decided to do sthg unusual when building the modules... === building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/tmp/Python-2.3.3/./Include -I/tmp/Python-2.3. 3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3. 3/Modules/_cursesmodule.c -o build/temp.solaris-2.8-sun4u-2. 3/_cursesmodule.o In file included from /tmp/Python-2.3.3/Modules/_cursesmodule.c:113: /tmp/Python-2.3.3/./Include/py_curses.h:43:21: ncurses.h: No such file or directory === adding CPPFLAGS or CFLAGS to the compile command would sort things out. the same thing happens to other modules as well (bz2 ie). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-06 16:47 Message: Logged In: YES user_id=357491 rev. 1.205 of setup.py and rev. 1.149 of Makefile.pre.in allow extension modules to be compiled with the directories specified in LDFLAGS and CPPFLAGS. As for CFLAGS, that gets trickier. For that situation I would set OPT or BASECFLAGS when running configure (be careful of the latter, though, since you really are not supposed to play with that). Considering this bug closed and fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-11-06 17:30 Message: Logged In: YES user_id=357491 It's too late for 2.4, but I will get this in for 2.5 . I will try to add support for CC, CFLAGS, LDFLAGS, CPPFLAGS, and CPP (all of the environment variables listed by ``./configure -h``). Basically the problem is that setup.py does not check these. If you need a quick fix than just add the directories yourself (grep for Fink or DarwinPorts in setup.py to see the function calls). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=955197&group_id=5470 From noreply at sourceforge.net Tue Dec 7 03:54:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 03:54:43 2004 Subject: [ python-Bugs-1080387 ] IDLE and old color themes Message-ID: Bugs item #1080387, was opened at 2004-12-06 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 From noreply at sourceforge.net Tue Dec 7 06:13:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 06:13:29 2004 Subject: [ python-Bugs-1080387 ] IDLE and old color themes Message-ID: Bugs item #1080387, was opened at 2004-12-06 21:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 00:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 From noreply at sourceforge.net Tue Dec 7 06:36:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 06:36:08 2004 Subject: [ python-Bugs-1080424 ] Inplace set merge produces wrong results Message-ID: Bugs item #1080424, was opened at 2004-12-07 06:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace set merge produces wrong results Initial Comment: [forwarded from http://bugs.debian.org/284490] the inplace set merge can produce wrong results compared to the a = a | b non in-place (and slower) version. Please see the attached tarball: running the "test" script shows the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 From noreply at sourceforge.net Tue Dec 7 07:24:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 07:25:01 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 13:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Tue Dec 7 08:46:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 08:46:35 2004 Subject: [ python-Bugs-1080424 ] Inplace set merge produces wrong results Message-ID: Bugs item #1080424, was opened at 2004-12-07 00:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace set merge produces wrong results Initial Comment: [forwarded from http://bugs.debian.org/284490] the inplace set merge can produce wrong results compared to the a = a | b non in-place (and slower) version. Please see the attached tarball: running the "test" script shows the problem. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:46 Message: Logged In: YES user_id=31435 I can pretty much guarantee this isn't a bug in Python, but is in some aspect of your algorithm that *relies* on not sharing mutable sets. For example, if I leave Debtags1.py's self.items[t] |= add_elements alone but add this right after it: self.items[t] = self.items[t].copy() then Debtags1.py produces the same output as Debtags.py. Same thing with Debtags2.py: adding that line also makes Debtag2.py's output the same. That proves the problem isn't in the implementations of "|=" or .update(). It strongly suggests that you're mutating a shared set that you're not expecting to mutate, or aren't expecting is shared. For example, your driver does s = db.elset(sys.argv[1]) for t in sys.argv[2:]: s &= db.elset(t) and that mutates the set in self.items[sys.argv[1]]. If you don't intend that computing output will mutate the sets in db, then that code is confused. That's not the source of your differing output, but "something like it" probably is. In fact, the problem is probably here: self.items[t] = add_elements That can assign the same add_elements as the value associated with *many* distinct values of t. Then you try to update those later in place, but "those" is a single shared set. Changing the value associated with one of the t's then changes the value associated with all of the t's that originally got assigned the same "add_elements" set. If I go back to the original Debtags1.py, and replace self.items[t] = add_elements with self.items[t] = add_elements.copy() then the later updates-in-place do no harm, and it produces the output you said you expected. If you don't understand this, here's a dead simple example: >>> x = set([1]) >>> y = x # y and x are the *same* set now >>> x |= set([2]) # so mutating x in place ... >>> x set([1, 2]) >>> y # ... also mutates the set bound to y set([1, 2]) >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 From noreply at sourceforge.net Tue Dec 7 08:51:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 08:51:59 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 01:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Tue Dec 7 12:35:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 12:35:25 2004 Subject: [ python-Bugs-1080424 ] Inplace set merge produces wrong results Message-ID: Bugs item #1080424, was opened at 2004-12-07 00:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Invalid Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace set merge produces wrong results Initial Comment: [forwarded from http://bugs.debian.org/284490] the inplace set merge can produce wrong results compared to the a = a | b non in-place (and slower) version. Please see the attached tarball: running the "test" script shows the problem. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-07 06:35 Message: Logged In: YES user_id=80475 On line 39, replace self.items[t] = add_elements with self.items[t] = add_elements.copy() That will fix all three. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:46 Message: Logged In: YES user_id=31435 I can pretty much guarantee this isn't a bug in Python, but is in some aspect of your algorithm that *relies* on not sharing mutable sets. For example, if I leave Debtags1.py's self.items[t] |= add_elements alone but add this right after it: self.items[t] = self.items[t].copy() then Debtags1.py produces the same output as Debtags.py. Same thing with Debtags2.py: adding that line also makes Debtag2.py's output the same. That proves the problem isn't in the implementations of "|=" or .update(). It strongly suggests that you're mutating a shared set that you're not expecting to mutate, or aren't expecting is shared. For example, your driver does s = db.elset(sys.argv[1]) for t in sys.argv[2:]: s &= db.elset(t) and that mutates the set in self.items[sys.argv[1]]. If you don't intend that computing output will mutate the sets in db, then that code is confused. That's not the source of your differing output, but "something like it" probably is. In fact, the problem is probably here: self.items[t] = add_elements That can assign the same add_elements as the value associated with *many* distinct values of t. Then you try to update those later in place, but "those" is a single shared set. Changing the value associated with one of the t's then changes the value associated with all of the t's that originally got assigned the same "add_elements" set. If I go back to the original Debtags1.py, and replace self.items[t] = add_elements with self.items[t] = add_elements.copy() then the later updates-in-place do no harm, and it produces the output you said you expected. If you don't understand this, here's a dead simple example: >>> x = set([1]) >>> y = x # y and x are the *same* set now >>> x |= set([2]) # so mutating x in place ... >>> x set([1, 2]) >>> y # ... also mutates the set bound to y set([1, 2]) >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080424&group_id=5470 From noreply at sourceforge.net Tue Dec 7 14:08:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 14:08:28 2004 Subject: [ python-Bugs-1080387 ] IDLE and old color themes Message-ID: Bugs item #1080387, was opened at 2004-12-06 19:54 Message generated for change (Comment added) made by projecktzero You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. ---------------------------------------------------------------------- >Comment By: projecktzero (projecktzero) Date: 2004-12-07 06:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-06 22:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 From noreply at sourceforge.net Tue Dec 7 14:54:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 14:54:11 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 13:24 Message generated for change (Comment added) made by dileep_nirala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 20:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 14:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Tue Dec 7 14:56:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 14:56:30 2004 Subject: [ python-Bugs-1080634 ] Python Icon in system Tray Message-ID: Bugs item #1080634, was opened at 2004-12-07 20:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: Python Icon in system Tray Initial Comment: The python icon remains in the system Tray even if you close the application. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 From noreply at sourceforge.net Tue Dec 7 15:35:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 15:35:59 2004 Subject: [ python-Bugs-1080387 ] IDLE and old color themes Message-ID: Bugs item #1080387, was opened at 2004-12-06 19:54 Message generated for change (Comment added) made by projecktzero You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. ---------------------------------------------------------------------- >Comment By: projecktzero (projecktzero) Date: 2004-12-07 07:35 Message: Logged In: YES user_id=1173237 I was able to reproduce the problem. I'm attaching the warning messages in a text file. ---------------------------------------------------------------------- Comment By: projecktzero (projecktzero) Date: 2004-12-07 06:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-06 22:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 From noreply at sourceforge.net Tue Dec 7 15:48:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 15:48:14 2004 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Tue Dec 7 15:51:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 15:51:20 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 06:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-07 14:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 13:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 07:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Tue Dec 7 17:32:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 17:32:51 2004 Subject: [ python-Bugs-1080713 ] os.ttyname() accepts wrong arguments Message-ID: Bugs item #1080713, was opened at 2004-12-07 08:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080713&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian H?ltje (docwhat) Assigned to: Nobody/Anonymous (nobody) Summary: os.ttyname() accepts wrong arguments Initial Comment: Problem: The doc for os.ttyname says it accepts an fd What Happens: It raises a type error and says it expects an integer instead. Experimentally, it seems to accept fd.fileno() as input What should happen: It should an accept an fd (file object) I have attached a test case for this. The output I get using python 2.2 & 2.3 is: Documentation Sez: ------------------------------------------------------------ ttyname(fd) -> String Return the name of the terminal device connected to 'fd'. ------------------------------------------------------------ TTY Name (should work): exceptions.TypeError an integer is required TTY Name (shouldn't work): /dev/pts/2 Ciao! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080713&group_id=5470 From noreply at sourceforge.net Tue Dec 7 17:47:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 17:47:56 2004 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 17:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) Assigned to: Nobody/Anonymous (nobody) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Tue Dec 7 18:13:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 18:13:19 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 01:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 12:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-07 09:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 08:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Tue Dec 7 18:33:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 18:34:00 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 01:24 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-07 12:33 Message: Logged In: YES user_id=31435 BTW, while nothing is guaranteed here, your best shot at working (albeit still by accident) portable code is to use expressions that don't tickle IEEE special values directly. For example, use pinf = 1e300 * 1e300 minf = -pinf nan = pinf - pinf That will work the same way from .py or .pyc. Whether pinf is actually +Infinity and nan is actually a NaN then remain platform-dependent accidents, but they will be on the majority platforms (Linux and Windows, using gcc or MSVC to compile Python). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 12:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-07 09:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 08:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 02:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Tue Dec 7 19:53:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 19:53:55 2004 Subject: [ python-Bugs-1080811 ] full test with all unicode text files Message-ID: Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 From noreply at sourceforge.net Tue Dec 7 21:23:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 21:23:50 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Tue Dec 7 21:25:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 21:25:55 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Tue Dec 7 22:39:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 22:39:42 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by zgoda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Tue Dec 7 22:44:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 22:44:40 2004 Subject: [ python-Bugs-1080387 ] IDLE and old color themes Message-ID: Bugs item #1080387, was opened at 2004-12-06 21:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE and old color themes Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 16:44 Message: Logged In: YES user_id=149084 Thanks for the report. I'll try to reproduce the problem myself. What is supposed to happen is if IDLE has a problem retreiving the theme, it's supposed to load the default theme from config-highlight.def and if that fails it's supposed to use a fallback theme written into the code itself. Clearly all this complexity isn't working too well, and the error messages aren't particularly helpful. ---------------------------------------------------------------------- Comment By: projecktzero (projecktzero) Date: 2004-12-07 09:35 Message: Logged In: YES user_id=1173237 I was able to reproduce the problem. I'm attaching the warning messages in a text file. ---------------------------------------------------------------------- Comment By: projecktzero (projecktzero) Date: 2004-12-07 08:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 00:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 From noreply at sourceforge.net Tue Dec 7 23:13:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 7 23:14:00 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 00:08:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 00:08:36 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 03:19:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 03:19:05 2004 Subject: [ python-Bugs-1081045 ] readline module doesn't build on MacOSX Message-ID: Bugs item #1081045, was opened at 2004-12-07 20:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL= /sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS= -L/sw/lib CONFIG_ARGS= '--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 From noreply at sourceforge.net Wed Dec 8 03:46:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 04:02:20 2004 Subject: [ python-Bugs-1081045 ] readline module doesn't build on MacOSX Message-ID: Bugs item #1081045, was opened at 2004-12-07 20:19 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL= /sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS= -L/sw/lib CONFIG_ARGS= '--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 20:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 From noreply at sourceforge.net Wed Dec 8 08:04:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 08:04:25 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 10:05:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 10:05:07 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 13:29:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 13:29:39 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by childsplay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 14:06:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 14:06:43 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 15:01:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 15:01:45 2004 Subject: [ python-Bugs-1081370 ] Bad reference in whrandom docs Message-ID: Bugs item #1081370, was opened at 2004-12-08 15:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081370&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lars Marius Garshol (larsga) Assigned to: Nobody/Anonymous (nobody) Summary: Bad reference in whrandom docs Initial Comment: The third paragraph of the documentation of the whrandom module has a sentence saying: "Instances of the whrandom class conform to the Random Number Generator interface described in section ." The section name/number and link are missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081370&group_id=5470 From noreply at sourceforge.net Wed Dec 8 15:16:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 15:16:16 2004 Subject: [ python-Bugs-1079545 ] python-2.4.msi install error Message-ID: Bugs item #1079545, was opened at 2004-12-05 20:02 Message generated for change (Comment added) made by maharal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: maharal (maharal) Assigned to: Martin v. L?wis (loewis) Summary: python-2.4.msi install error Initial Comment: when I try to install python2.4. using the python- 2.4.msi-file, it stopps with the error message: "The installer has encountered an unexpected error installing this package. This may inidicate a problem with this package. The error code is 2738" ---------------------------------------------------------------------- >Comment By: maharal (maharal) Date: 2004-12-08 14:16 Message: Logged In: YES user_id=1171290 Dear Mr. L?wis, Your presumption was right: vbscript 5.6 was all that was needed to make the installation run! Thanks a lot for your help! Ralf ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 21:59 Message: Logged In: YES user_id=21627 Can you please try to install VBScript, from http://msdn.microsoft.com/downloads/list/webdev.asp and report whether this works? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 From noreply at sourceforge.net Wed Dec 8 16:09:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 16:09:52 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by childsplay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 16:31:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 16:31:11 2004 Subject: [ python-Bugs-1080634 ] PythonWin Tray Icon in system Tray on Windows platform Message-ID: Bugs item #1080634, was opened at 2004-12-07 20:56 Message generated for change (Comment added) made by dileep_nirala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) >Summary: PythonWin Tray Icon in system Tray on Windows platform Initial Comment: The python icon remains in the system Tray even if you close the application. ---------------------------------------------------------------------- >Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-08 22:31 Message: Logged In: YES user_id=1173293 PythonWin tray icons remains in the system tray once you close the application for Python-2.4.0-243 build on Windows platform. If you hover the mouse then only it goes off. If you open and close PythonWin application 10 times, you will see 10 tray icons. Any probable date, when this could get resolved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 From noreply at sourceforge.net Wed Dec 8 22:23:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 22:23:36 2004 Subject: [ python-Bugs-1081633 ] LDAP search segfaults on RedHat FC3 Message-ID: Bugs item #1081633, was opened at 2004-12-08 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tessa Lau (tlau) Assigned to: Nobody/Anonymous (nobody) Summary: LDAP search segfaults on RedHat FC3 Initial Comment: Doing an LDAP search against one of our intranet LDAP servers results in a segmentation fault with Python 2.3.4 on Fedora Core 3. Here is a 2-line test case: server = ldap.initialize(URL) results = server.search_st(BASE, ldap.SCOPE_ONELEVEL, '(cn=anyone@gmail.com)', ['cn', 'email']) The gdb backtrace is attached. If I run the same code on a different system (Debian, Python 2.3.4, OpenLDAP 2.1.30), instead of a segfault I see an LDAP error: ldap.NO_RESULTS_RETURNED: {'info': '', 'desc': 'No results returned'} Based on the backtrace, I think the FC3 system is not handling that error correctly. Python version information: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Python and LDAP RPMs installed: python-2.3.4-11 nss_ldap-220-3 python-ldap-2.0.1-2 openldap-2.2.13-2 openldap-devel-2.2.13-2 openldap-clients-2.2.13-2 openldap-servers-2.2.13-2 uname -a: Linux xxx.yyy.net 2.6.9-1.681_FC3.WKD_tr_mts_1 #1 Tue Nov 23 22:35:54 EST 2004 i686 athlon i386 GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470 From noreply at sourceforge.net Wed Dec 8 22:28:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 22:28:13 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Wed Dec 8 22:30:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 22:30:28 2004 Subject: [ python-Bugs-1081633 ] LDAP search segfaults on RedHat FC3 Message-ID: Bugs item #1081633, was opened at 2004-12-08 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470 Category: Extension Modules >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tessa Lau (tlau) Assigned to: Nobody/Anonymous (nobody) Summary: LDAP search segfaults on RedHat FC3 Initial Comment: Doing an LDAP search against one of our intranet LDAP servers results in a segmentation fault with Python 2.3.4 on Fedora Core 3. Here is a 2-line test case: server = ldap.initialize(URL) results = server.search_st(BASE, ldap.SCOPE_ONELEVEL, '(cn=anyone@gmail.com)', ['cn', 'email']) The gdb backtrace is attached. If I run the same code on a different system (Debian, Python 2.3.4, OpenLDAP 2.1.30), instead of a segfault I see an LDAP error: ldap.NO_RESULTS_RETURNED: {'info': '', 'desc': 'No results returned'} Based on the backtrace, I think the FC3 system is not handling that error correctly. Python version information: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Python and LDAP RPMs installed: python-2.3.4-11 nss_ldap-220-3 python-ldap-2.0.1-2 openldap-2.2.13-2 openldap-devel-2.2.13-2 openldap-clients-2.2.13-2 openldap-servers-2.2.13-2 uname -a: Linux xxx.yyy.net 2.6.9-1.681_FC3.WKD_tr_mts_1 #1 Tue Nov 23 22:35:54 EST 2004 i686 athlon i386 GNU/Linux ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:30 Message: Logged In: YES user_id=21627 python-ldap is not part of the Python project; please report this bug to http://python-ldap.sourceforge.net/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081633&group_id=5470 From noreply at sourceforge.net Wed Dec 8 22:42:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 22:42:12 2004 Subject: [ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple Message-ID: Feature Requests item #1075902, was opened at 2004-11-30 11:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Proctor (sproctor) Assigned to: Nobody/Anonymous (nobody) Summary: ignore element format character for PyArg_ParseTuple Initial Comment: Some kind of option to indicate there is an element, but we don't care about its value would be nice. It could be _. then an example would be: PyArg_ParseTuple (tuple, "_i", &my_int); This indicates that there is another value before the int, but we don't care about it one way or the other. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:42 Message: Logged In: YES user_id=21627 What's wrong with using O as the format character? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 From noreply at sourceforge.net Wed Dec 8 23:12:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 23:12:53 2004 Subject: [ python-Bugs-1079545 ] python-2.4.msi install error Message-ID: Bugs item #1079545, was opened at 2004-12-05 21:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: maharal (maharal) Assigned to: Martin v. L?wis (loewis) Summary: python-2.4.msi install error Initial Comment: when I try to install python2.4. using the python- 2.4.msi-file, it stopps with the error message: "The installer has encountered an unexpected error installing this package. This may inidicate a problem with this package. The error code is 2738" ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 23:12 Message: Logged In: YES user_id=21627 Ok, I have added an entry into http://www.python.org/2.4/bugs.html For 2.4.1, I will try to do without VB. ---------------------------------------------------------------------- Comment By: maharal (maharal) Date: 2004-12-08 15:16 Message: Logged In: YES user_id=1171290 Dear Mr. L?wis, Your presumption was right: vbscript 5.6 was all that was needed to make the installation run! Thanks a lot for your help! Ralf ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:59 Message: Logged In: YES user_id=21627 Can you please try to install VBScript, from http://msdn.microsoft.com/downloads/list/webdev.asp and report whether this works? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 From noreply at sourceforge.net Wed Dec 8 23:13:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 8 23:13:37 2004 Subject: [ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP Message-ID: Bugs item #1076861, was opened at 2004-12-01 17:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Martin v. L?wis (loewis) Summary: Bad IDLE shortcut by 2.4 installer on XP Initial Comment: There is a problem with the Python 2.4 installer on Windows XP. The IDLE shortcut set up by the installer in the StartUp folder does not work. If the shortcut is removed and recreated manually, it works fine. That was *after* a complete reinstall of Python 2.4 and after removing the previous version of Python 2.3 on the machine. With Python 2.3 present, the IDLE shortcut installed by Python 2.4 runs the 2.3 version. See also and ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 23:13 Message: Logged In: YES user_id=21627 I've added an entry to http://www.python.org/2.4/bugs.html now and hope to fix the problem for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 From noreply at sourceforge.net Thu Dec 9 02:16:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 02:16:47 2004 Subject: [ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP Message-ID: Bugs item #1076861, was opened at 2004-12-01 10:28 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Martin v. L?wis (loewis) Summary: Bad IDLE shortcut by 2.4 installer on XP Initial Comment: There is a problem with the Python 2.4 installer on Windows XP. The IDLE shortcut set up by the installer in the StartUp folder does not work. If the shortcut is removed and recreated manually, it works fine. That was *after* a complete reinstall of Python 2.4 and after removing the previous version of Python 2.3 on the machine. With Python 2.3 present, the IDLE shortcut installed by Python 2.4 runs the 2.3 version. See also and ---------------------------------------------------------------------- >Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-08 19:16 Message: Logged In: YES user_id=832557 One more piece of data. We installed Python 2.4 in directory "C:\Program Files\Python24". Maybe the space in the name is causing the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 16:13 Message: Logged In: YES user_id=21627 I've added an entry to http://www.python.org/2.4/bugs.html now and hope to fix the problem for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 From noreply at sourceforge.net Thu Dec 9 03:06:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 03:06:12 2004 Subject: [ python-Bugs-1081824 ] Rewrite of docs for compiler.visitor Message-ID: Bugs item #1081824, was opened at 2004-12-09 02:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Rewrite of docs for compiler.visitor Initial Comment: I was recently prompted to look at the docs for compiler.visitor (Lib Ref 19.4 Using Visitors to Walk ASTs). With all due respect it is not up to the standards of most of the docs. I have attempted a rewrite which is in the attachment. I suggest also that the entry for walk() on the main compiler doc page (19.1) should be updated to refer to 19.4 for details. HTH Kent ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470 From noreply at sourceforge.net Thu Dec 9 04:35:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 04:35:24 2004 Subject: [ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple Message-ID: Feature Requests item #1075902, was opened at 2004-11-30 05:28 Message generated for change (Comment added) made by sproctor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Proctor (sproctor) Assigned to: Nobody/Anonymous (nobody) Summary: ignore element format character for PyArg_ParseTuple Initial Comment: Some kind of option to indicate there is an element, but we don't care about its value would be nice. It could be _. then an example would be: PyArg_ParseTuple (tuple, "_i", &my_int); This indicates that there is another value before the int, but we don't care about it one way or the other. ---------------------------------------------------------------------- >Comment By: Sean Proctor (sproctor) Date: 2004-12-08 22:35 Message: Logged In: YES user_id=43755 If I use O, then I need to have a variable to store it in. I think it's less readable. Like with pattern matching in ML, you can use a variable instead of _, but it's not obvious that you aren't going to use that value. With some kind of place holder, this is made clear, and I don't need to create a variable to store a value that I don't care about. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 16:42 Message: Logged In: YES user_id=21627 What's wrong with using O as the format character? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 From noreply at sourceforge.net Thu Dec 9 06:04:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 06:04:42 2004 Subject: [ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple Message-ID: Feature Requests item #1075902, was opened at 2004-11-30 05:28 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Proctor (sproctor) Assigned to: Nobody/Anonymous (nobody) Summary: ignore element format character for PyArg_ParseTuple Initial Comment: Some kind of option to indicate there is an element, but we don't care about its value would be nice. It could be _. then an example would be: PyArg_ParseTuple (tuple, "_i", &my_int); This indicates that there is another value before the int, but we don't care about it one way or the other. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-09 00:04 Message: Logged In: YES user_id=31435 If you want to make C code look like ML, declare PyObject** _; and use _ in the argument list. I'm -1 on this: the case has almost never arisen in my experience, and the limited pool of format characters should be preserved for high-value uses. ---------------------------------------------------------------------- Comment By: Sean Proctor (sproctor) Date: 2004-12-08 22:35 Message: Logged In: YES user_id=43755 If I use O, then I need to have a variable to store it in. I think it's less readable. Like with pattern matching in ML, you can use a variable instead of _, but it's not obvious that you aren't going to use that value. With some kind of place holder, this is made clear, and I don't need to create a variable to store a value that I don't care about. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 16:42 Message: Logged In: YES user_id=21627 What's wrong with using O as the format character? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 From noreply at sourceforge.net Thu Dec 9 06:14:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 06:14:10 2004 Subject: [ python-Bugs-1081879 ] Pydoc can't find browser (bug+solution!) Message-ID: Bugs item #1081879, was opened at 2004-12-08 22:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stewart Midwinter (midtoad) Assigned to: Nobody/Anonymous (nobody) Summary: Pydoc can't find browser (bug+solution!) Initial Comment: I've got Python 2.3 installed on Mandrake Linux 10.1 with KDE 3.2 running. When I run "pydoc -g" and search on any term, if I try to display the relevant documentation, pydoc throws an exception: Traceback (most recent call last): File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/usr/lib/python2.3/pydoc.py", line 1970, in open webbrowser.open(url) File "/usr/lib/python2.3/webbrowser.py", line 43, in open get().open(url, new, autoraise) File "/usr/lib/python2.3/webbrowser.py", line 38, in get raise Error("could not locate runnable browser") Error: could not locate runnable browser I did some research and found that the problem is that KDE sets the BROWSER environment variable to an unexpected value: BROWSER='kfmclient openProfile webbrowsing' The solution would be to test for this strange setting. I patched webbrowser.py on my system in an inelegant fashion by simply inserting the following code at the top of the file, just after the 'import' statements: #patch for KDE mangling of BROWSER environment variable #per: http://mail.python.org/pipermail/tutor/2004-September/032060.html if os.environ.has_key("BROWSER") and \ os.environ["BROWSER"]=='kfmclient openProfile webbrowsing': os.environ["BROWSER"] = 'konqueror' # set it to konqueror ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470 From noreply at sourceforge.net Thu Dec 9 06:37:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 06:37:21 2004 Subject: [ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple Message-ID: Feature Requests item #1075902, was opened at 2004-11-30 05:28 Message generated for change (Comment added) made by sproctor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Proctor (sproctor) Assigned to: Nobody/Anonymous (nobody) Summary: ignore element format character for PyArg_ParseTuple Initial Comment: Some kind of option to indicate there is an element, but we don't care about its value would be nice. It could be _. then an example would be: PyArg_ParseTuple (tuple, "_i", &my_int); This indicates that there is another value before the int, but we don't care about it one way or the other. ---------------------------------------------------------------------- >Comment By: Sean Proctor (sproctor) Date: 2004-12-09 00:37 Message: Logged In: YES user_id=43755 that would turn my example into PyArg_ParseTuple (tuple, "Oi", _, &my_int); I don't particularly care. I thought it was a good suggestion. To me _ looks like a blank. I wouldn't really want to use it in a format string for something besides an any/none scenario. Your reasoning about preserving format characters seems really weak. You've never had a tuple where you didn't care about the value of each element? Somewhat separate topic. Could you say "PyArg_ParseTuple (tuple, "Oi", NULL, &my_int);" ? I guess that would be a less elegant way of doing what I intended. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-09 00:04 Message: Logged In: YES user_id=31435 If you want to make C code look like ML, declare PyObject** _; and use _ in the argument list. I'm -1 on this: the case has almost never arisen in my experience, and the limited pool of format characters should be preserved for high-value uses. ---------------------------------------------------------------------- Comment By: Sean Proctor (sproctor) Date: 2004-12-08 22:35 Message: Logged In: YES user_id=43755 If I use O, then I need to have a variable to store it in. I think it's less readable. Like with pattern matching in ML, you can use a variable instead of _, but it's not obvious that you aren't going to use that value. With some kind of place holder, this is made clear, and I don't need to create a variable to store a value that I don't care about. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 16:42 Message: Logged In: YES user_id=21627 What's wrong with using O as the format character? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 From noreply at sourceforge.net Thu Dec 9 10:27:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 10:27:29 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by childsplay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Thu Dec 9 10:42:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 10:42:13 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Thu Dec 9 10:56:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 10:56:21 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Thu Dec 9 11:33:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 11:33:13 2004 Subject: [ python-Bugs-1075427 ] urllib2.HTTPBasicAuthHandler problem with [HOST]:[PORT] Message-ID: Bugs item #1075427, was opened at 2004-11-29 19:06 Message generated for change (Comment added) made by mmzeeman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075427&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: O-Zone (o-zone2004) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler problem with [HOST]:[PORT] Initial Comment: I've encountered problems authenticating to an host with this piece of code: passman = urllib2.HTTPPasswordMgrWithDefaultRealm() passman.add_password(None, theurl, username, password) authhandler = urllib2.HTTPBasicAuthHandler(passman) opener = urllib2.build_opener(authhandler) urllib2.install_opener(opener) req = urllib2.Request(theurl) try: handle = urllib2.urlopen(req) if i specify an URL like: http://[MyHostIP]:[Port] auth helper never authorize me on the host. It work perfectly if i don't specify ANY port in the URL. Regards, Michele "O-Zone" Pinassi ---------------------------------------------------------------------- Comment By: MM Zeeman (mmzeeman) Date: 2004-12-09 11:33 Message: Logged In: YES user_id=350634 This is actually the same problem as reported in bug 974757, which has a patch attached to it. The problem is that with basic authentication only the hostname + portnumber is passed to find_user_password. This method works if there is no port number when a netloc is used. It looks like the answer from reduce_uri is wrong when port numbers are used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075427&group_id=5470 From noreply at sourceforge.net Thu Dec 9 14:08:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 14:08:40 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-09 08:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 14:09:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 14:09:35 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-09 08:08 Message generated for change (Settings changed) made by ajung You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 14:12:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 14:12:12 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-09 08:08 Message generated for change (Comment added) made by ajung You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2004-12-09 08:12 Message: Logged In: YES user_id=11084 This error not only happens with u'\xc4', it happens with *any* string containing a character >0x7f. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 15:04:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 15:04:19 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-10 00:08 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-10 01:04 Message: Logged In: YES user_id=29957 Please attach a test case that shows the failure. I can't reproduce it here with the information you've given. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2004-12-10 00:12 Message: Logged In: YES user_id=11084 This error not only happens with u'\xc4', it happens with *any* string containing a character >0x7f. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 15:14:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 15:14:35 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-09 13:08 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- >Comment By: Jim Fulton (dcjim) Date: 2004-12-09 14:14 Message: Logged In: YES user_id=73023 I can't reproduce this: >>> ick = u'\xc4' >>> import struct >>> struct.pack(ick) Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xc4' in position 0: ordinal not in range(128) >>> struct.pack(u'i', 1) '\x01\x00\x00\x00' The code that provked this in Zope is buggy., ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-09 14:04 Message: Logged In: YES user_id=29957 Please attach a test case that shows the failure. I can't reproduce it here with the information you've given. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2004-12-09 13:12 Message: Logged In: YES user_id=11084 This error not only happens with u'\xc4', it happens with *any* string containing a character >0x7f. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 15:27:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 15:28:06 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-09 13:08 Message generated for change (Settings changed) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 7 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2004-12-09 14:14 Message: Logged In: YES user_id=73023 I can't reproduce this: >>> ick = u'\xc4' >>> import struct >>> struct.pack(ick) Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xc4' in position 0: ordinal not in range(128) >>> struct.pack(u'i', 1) '\x01\x00\x00\x00' The code that provked this in Zope is buggy., ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-09 14:04 Message: Logged In: YES user_id=29957 Please attach a test case that shows the failure. I can't reproduce it here with the information you've given. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2004-12-09 13:12 Message: Logged In: YES user_id=11084 This error not only happens with u'\xc4', it happens with *any* string containing a character >0x7f. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 16:05:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 16:05:56 2004 Subject: [ python-Bugs-1082085 ] PyString_AsString() segfaults when passed a unicode string Message-ID: Bugs item #1082085, was opened at 2004-12-09 08:08 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug Status: Closed >Resolution: Invalid Priority: 7 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_AsString() segfaults when passed a unicode string Initial Comment: If you pass a PyObject representation the unicode string u'\xc4' to PyString_AsString() then Python (2.3.4, 2.4.0) segfault. Famous last words of Python 2.4: Exception exceptions.UnicodeEncodeError: in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Famous last words of Python 2.4 (debug build): XXX undetected error Traceback (most recent call last): File "test.py", line 4, in ? print S.split(u'\xc4') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) [6545 refs] This bug has been reported first on the zope-dev list. I confirmed that this error does not only occur in Zope but also in a Python-only environment. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-09 10:05 Message: Logged In: YES user_id=31435 For the record, this appeared to be due to an extension module doing PyString_AsString(name)[0] when name was a Unicode string containing a "high-bit" character. PyString_AsString(name) legitimately returned NULL, and bad stuff followed. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2004-12-09 09:14 Message: Logged In: YES user_id=73023 I can't reproduce this: >>> ick = u'\xc4' >>> import struct >>> struct.pack(ick) Traceback (most recent call last): File "", line 1, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xc4' in position 0: ordinal not in range(128) >>> struct.pack(u'i', 1) '\x01\x00\x00\x00' The code that provked this in Zope is buggy., ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-09 09:04 Message: Logged In: YES user_id=29957 Please attach a test case that shows the failure. I can't reproduce it here with the information you've given. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2004-12-09 08:12 Message: Logged In: YES user_id=11084 This error not only happens with u'\xc4', it happens with *any* string containing a character >0x7f. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082085&group_id=5470 From noreply at sourceforge.net Thu Dec 9 19:59:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 19:59:53 2004 Subject: [ python-Bugs-1076233 ] distutils.core.setup() with unicode arguments broken Message-ID: Bugs item #1076233, was opened at 2004-11-30 14:53 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076233&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: A.M. Kuchling (akuchling) Summary: distutils.core.setup() with unicode arguments broken Initial Comment: When using unicode arguments for distutils.core.setup() running setup.py breaks with the following exception: Traceback (most recent call last): ... \Lib\distutils\command\sdist.py", line 430, in make_release_tree self.distribution.metadata.write_pkg_info(base_dir) File "C:\Programme\Python24\Lib\distutils\dist.py", line 1047, in write_pkg_info pkg_info.write('Author: %s\n' % self.get_contact() ) UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 16: ordinal not in range(128) Changing the system default encoding to iso-8859-1 works around this problem. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-09 13:59 Message: Logged In: YES user_id=11375 Encoding was never considered. PEP 314 is an updated version of PEP 241; it should specify an encoding (probably UTF-8 is the most reasonable choice). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-11-30 15:13 Message: Logged In: YES user_id=11105 I'm unusure about the allowed encoding in PKG-INFO, and I cannot find anything in PEP 241. Andrew, since you are listed as the author, can you comment? bdist_wininst does accept unicode strings, and that may be the reason that walter expects this to work for sdist also... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076233&group_id=5470 From noreply at sourceforge.net Thu Dec 9 20:06:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 20:06:10 2004 Subject: [ python-Bugs-1080811 ] full test with all unicode text files Message-ID: Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-09 20:06 Message: Logged In: YES user_id=89016 I can't reproduce this on Linux. Putting JOHAB.TXT (and the other files) into the current directory (dist from a CVS checkout) and running "python Lib/test/regrtest.py" works. Putting all the files into Lib/test and running regrtest.py from there works too. Which version of Python are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 From noreply at sourceforge.net Thu Dec 9 22:43:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 9 22:44:00 2004 Subject: [ python-Bugs-1082487 ] font lock keyword regular expressions Message-ID: Bugs item #1082487, was opened at 2004-12-09 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Brown (robert-brown) Assigned to: Nobody/Anonymous (nobody) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 From noreply at sourceforge.net Fri Dec 10 00:21:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 00:21:39 2004 Subject: [ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple Message-ID: Feature Requests item #1075902, was opened at 2004-11-30 11:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Proctor (sproctor) Assigned to: Nobody/Anonymous (nobody) Summary: ignore element format character for PyArg_ParseTuple Initial Comment: Some kind of option to indicate there is an element, but we don't care about its value would be nice. It could be _. then an example would be: PyArg_ParseTuple (tuple, "_i", &my_int); This indicates that there is another value before the int, but we don't care about it one way or the other. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:21 Message: Logged In: YES user_id=21627 So just call the variable _: PyObject *_; PyArg_ParseTuple(tuple, "Oi", &_, &my_int); Given that this is possible today already, I expect that this RFE will be considered so minor that it won't be implemented anytime soon. It increases the learning curve for a nearly-unnoticable convenience. ---------------------------------------------------------------------- Comment By: Sean Proctor (sproctor) Date: 2004-12-09 06:37 Message: Logged In: YES user_id=43755 that would turn my example into PyArg_ParseTuple (tuple, "Oi", _, &my_int); I don't particularly care. I thought it was a good suggestion. To me _ looks like a blank. I wouldn't really want to use it in a format string for something besides an any/none scenario. Your reasoning about preserving format characters seems really weak. You've never had a tuple where you didn't care about the value of each element? Somewhat separate topic. Could you say "PyArg_ParseTuple (tuple, "Oi", NULL, &my_int);" ? I guess that would be a less elegant way of doing what I intended. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-09 06:04 Message: Logged In: YES user_id=31435 If you want to make C code look like ML, declare PyObject** _; and use _ in the argument list. I'm -1 on this: the case has almost never arisen in my experience, and the limited pool of format characters should be preserved for high-value uses. ---------------------------------------------------------------------- Comment By: Sean Proctor (sproctor) Date: 2004-12-09 04:35 Message: Logged In: YES user_id=43755 If I use O, then I need to have a variable to store it in. I think it's less readable. Like with pattern matching in ML, you can use a variable instead of _, but it's not obvious that you aren't going to use that value. With some kind of place holder, this is made clear, and I don't need to create a variable to store a value that I don't care about. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:42 Message: Logged In: YES user_id=21627 What's wrong with using O as the format character? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 From noreply at sourceforge.net Fri Dec 10 00:26:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 00:26:46 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Fri Dec 10 09:54:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 09:54:10 2004 Subject: [ python-Bugs-1080811 ] full test with all unicode text files Message-ID: Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Comment added) made by makaron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. ---------------------------------------------------------------------- >Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-10 09:54 Message: Logged In: YES user_id=115179 my system is windows 2000 pro sp4 with latest fixes from ms, polish language, python from cvs (head), msvc 7.1 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-09 20:06 Message: Logged In: YES user_id=89016 I can't reproduce this on Linux. Putting JOHAB.TXT (and the other files) into the current directory (dist from a CVS checkout) and running "python Lib/test/regrtest.py" works. Putting all the files into Lib/test and running regrtest.py from there works too. Which version of Python are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 From noreply at sourceforge.net Fri Dec 10 13:26:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 13:26:57 2004 Subject: [ python-Bugs-1082874 ] Unable to see Python binary Message-ID: Bugs item #1082874, was opened at 2004-12-10 12:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Prabal Rakshit (prabal_rakshit) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Python binary Initial Comment: After extracting the Python-2.3.3.tar we could get the appropriate folder structure. We then executed the configure script. Therafter when we execute the make command the Python binary is not created in /usr/local/bin. Any pointers?? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 From noreply at sourceforge.net Fri Dec 10 14:16:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 14:17:02 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 14:16 Message: Logged In: YES user_id=38388 Well, if the alias mapping is good enough for X, then it's good enough for me :-) I think we ought to update the alias table with the current data of the X locale.alias file. This file also includes the mappings that childsplay mentioned. There also seems to be a bug in the encoding alias table: "utf" is no longer recognized by setlocale(). This should be changed to "utf8". I'll fix that and post an update here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Fri Dec 10 15:38:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 15:38:57 2004 Subject: [ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r Message-ID: Bugs item #1082944, was opened at 2004-12-10 14:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 From noreply at sourceforge.net Fri Dec 10 16:53:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 16:53:25 2004 Subject: [ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r Message-ID: Bugs item #1082944, was opened at 2004-12-10 09:38 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-10 10:53 Message: Logged In: YES user_id=31435 Umm, no, you typed so much into the Summary box that it got truncated. It ends with "incorrectly says it r". I assume "r" started as "returns", but that's where my telepathy stalls . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 From noreply at sourceforge.net Fri Dec 10 17:44:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 17:44:50 2004 Subject: [ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r Message-ID: Bugs item #1082944, was opened at 2004-12-10 14:38 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) ---------------------------------------------------------------------- >Comment By: Jim Fulton (dcjim) Date: 2004-12-10 16:44 Message: Logged In: YES user_id=73023 Crap. SourceForge accepted a long title and then truncated it. :( The Documentation for PyUnicode_TailMatch incorrrectly says it returns a PyObject pointer, which is incorrect. It returns an int. (It doesn't mention error returns. I assume that, in absense of any statement, a return value of -1 indicates an error, as is standard.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-10 15:53 Message: Logged In: YES user_id=31435 Umm, no, you typed so much into the Summary box that it got truncated. It ends with "incorrectly says it r". I assume "r" started as "returns", but that's where my telepathy stalls . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 From noreply at sourceforge.net Fri Dec 10 17:46:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 17:46:25 2004 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by kerofin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Fri Dec 10 17:52:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 17:53:02 2004 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-10 16:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:01:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:01:46 2004 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by kerofin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 17:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 16:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:14:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:14:43 2004 Subject: [ python-Bugs-1082944 ] Documentation for PyUnicode_TailMatch incorrrectly says it r Message-ID: Bugs item #1082944, was opened at 2004-12-10 09:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for PyUnicode_TailMatch incorrrectly says it r Initial Comment: nuf said ;) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:14 Message: Logged In: YES user_id=80475 Fixed. See Doc/api/concrete.tex 1.59 and 1.58.2.1. ---------------------------------------------------------------------- Comment By: Jim Fulton (dcjim) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=73023 Crap. SourceForge accepted a long title and then truncated it. :( The Documentation for PyUnicode_TailMatch incorrrectly says it returns a PyObject pointer, which is incorrect. It returns an int. (It doesn't mention error returns. I assume that, in absense of any statement, a return value of -1 indicates an error, as is standard.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-10 10:53 Message: Logged In: YES user_id=31435 Umm, no, you typed so much into the Summary box that it got truncated. It ends with "incorrectly says it r". I assume "r" started as "returns", but that's where my telepathy stalls . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082944&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:24:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:24:42 2004 Subject: [ python-Bugs-1081370 ] Bad reference in whrandom docs Message-ID: Bugs item #1081370, was opened at 2004-12-08 09:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081370&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lars Marius Garshol (larsga) Assigned to: Nobody/Anonymous (nobody) Summary: Bad reference in whrandom docs Initial Comment: The third paragraph of the documentation of the whrandom module has a sentence saying: "Instances of the whrandom class conform to the Random Number Generator interface described in section ." The section name/number and link are missing. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:24 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libwhrandom.tex 1.15.30.1 Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081370&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:31:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:32:05 2004 Subject: [ python-Bugs-1079011 ] Incorrect error message (somewhat) Message-ID: Bugs item #1079011, was opened at 2004-12-04 14:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect error message (somewhat) Initial Comment: Comparing complex numbers with cmp yields: >>> cmp(1+3j, 1+3j) 0 >>> cmp(1+3j, 3+4j) Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= Well, I didn't use <, <=, > or >=. It's not a major bug, but it doesn't look too nice... would it be possible to return NotImplemented? Or would that be semantically incorrect? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:31 Message: Logged In: YES user_id=80475 That is incorrect be == and != are implemented. The message is slightly weird but still helpful. Any rewording I can think of makes the message more obtuse, so I recommend leaving it alone and closing this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:35:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:35:45 2004 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) >Assigned to: Tim Peters (tim_one) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:45:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:45:59 2004 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) >Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-10 12:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Fri Dec 10 18:57:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 18:57:53 2004 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Comment added) made by corvus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- >Comment By: John Speno (corvus) Date: 2004-12-10 12:57 Message: Logged In: YES user_id=2138 Given that I can't reproduce it in a simple test, and it happens so rarely in my real applications, I'm okay with notice of it just being in google and here on sf. Maybe someday someone will encounter it again and we can make progress. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-10 12:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Fri Dec 10 19:54:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 19:54:14 2004 Subject: [ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault Message-ID: Bugs item #1083110, was opened at 2004-12-10 10:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sam Rushing (rushing) Assigned to: Nobody/Anonymous (nobody) Summary: truncated gzip file triggers zlibmodule segfault Initial Comment: If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 From noreply at sourceforge.net Fri Dec 10 20:44:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 20:44:38 2004 Subject: [ python-Bugs-1081045 ] readline module doesn't build on MacOSX Message-ID: Bugs item #1081045, was opened at 2004-12-07 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL= /sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS= -L/sw/lib CONFIG_ARGS= '--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=357491 I have uploaded a patch to add some debugging output. Can you run make and let me know what it outputs (might need to touch a file to trigger the need for setup.py to execute)? I need to know exactly what the environment variables are set to when they are parsed and what setup.py ends up with for its library and include directories. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 18:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 From noreply at sourceforge.net Fri Dec 10 21:58:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 21:58:35 2004 Subject: [ python-Bugs-1083177 ] Change in signal function in the signal module Message-ID: Bugs item #1083177, was opened at 2004-12-10 13:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 From noreply at sourceforge.net Fri Dec 10 22:19:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 22:19:49 2004 Subject: [ python-Bugs-1082874 ] Unable to see Python binary Message-ID: Bugs item #1082874, was opened at 2004-12-10 12:26 Message generated for change (Comment added) made by dyoo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Prabal Rakshit (prabal_rakshit) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Python binary Initial Comment: After extracting the Python-2.3.3.tar we could get the appropriate folder structure. We then executed the configure script. Therafter when we execute the make command the Python binary is not created in /usr/local/bin. Any pointers?? ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2004-12-10 21:19 Message: Logged In: YES user_id=49843 The 'make install' target will copy the built binary to '/usr/local/bin'. Did you try 'make install' yet? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 From noreply at sourceforge.net Fri Dec 10 22:39:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 22:39:37 2004 Subject: [ python-Bugs-1083202 ] UnboundLocalError raised by atexit module Message-ID: Bugs item #1083202, was opened at 2004-12-10 14:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError raised by atexit module Initial Comment: The following exception is raised on exit by Python 2.4 under certain circumstances: Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs exc_info = sys.exc_info() UnboundLocalError: local variable 'sys' referenced before assignment I traced the problem to a missing import statement in the atexit.py file. I am enclosing a corrected file with the patch. Gary H. Loechelt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&group_id=5470 From noreply at sourceforge.net Fri Dec 10 22:58:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 22:58:42 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: stas Z (childsplay) Assigned to: Nobody/Anonymous (nobody) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 22:58 Message: Logged In: YES user_id=38388 Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.29; previous revision: 1.28 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 14:16 Message: Logged In: YES user_id=38388 Well, if the alias mapping is good enough for X, then it's good enough for me :-) I think we ought to update the alias table with the current data of the X locale.alias file. This file also includes the mappings that childsplay mentioned. There also seems to be a bug in the encoding alias table: "utf" is no longer recognized by setlocale(). This should be changed to "utf8". I'll fix that and post an update here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Fri Dec 10 22:59:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 10 22:59:35 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: stas Z (childsplay) >Assigned to: M.-A. Lemburg (lemburg) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 22:58 Message: Logged In: YES user_id=38388 Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.29; previous revision: 1.28 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 14:16 Message: Logged In: YES user_id=38388 Well, if the alias mapping is good enough for X, then it's good enough for me :-) I think we ought to update the alias table with the current data of the X locale.alias file. This file also includes the mappings that childsplay mentioned. There also seems to be a bug in the encoding alias table: "utf" is no longer recognized by setlocale(). This should be changed to "utf8". I'll fix that and post an update here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Sat Dec 11 02:22:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 11 02:22:28 2004 Subject: [ python-Bugs-1083299 ] Distutils doesn't pick up all the files it should. Message-ID: Bugs item #1083299, was opened at 2004-12-10 19:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083299&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils doesn't pick up all the files it should. Initial Comment: Distutils doesn't pick up files specified in setup.py that it knows about. For instance, files listed on the depends keyword of the Extension class don't get included in a source distribution, or copied to the build directory when building a binary distribution. The data-files keyword to the setup function reportedly suffers the same fate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083299&group_id=5470 From noreply at sourceforge.net Sat Dec 11 03:54:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 11 03:54:06 2004 Subject: [ python-Bugs-1083202 ] UnboundLocalError raised by atexit module Message-ID: Bugs item #1083202, was opened at 2004-12-10 16:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError raised by atexit module Initial Comment: The following exception is raised on exit by Python 2.4 under certain circumstances: Error in sys.exitfunc: Traceback (most recent call last): File "/usr/local/python/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs exc_info = sys.exc_info() UnboundLocalError: local variable 'sys' referenced before assignment I traced the problem to a missing import statement in the atexit.py file. I am enclosing a corrected file with the patch. Gary H. Loechelt ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 21:54 Message: Logged In: YES user_id=80475 Fixed. See Lib/atexit.py 1.9 and 1.8.2.1. Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083202&group_id=5470 From noreply at sourceforge.net Sat Dec 11 04:32:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 11 04:32:58 2004 Subject: [ python-Bugs-1083177 ] Change in signal function in the signal module Message-ID: Bugs item #1083177, was opened at 2004-12-10 15:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:32 Message: Logged In: YES user_id=80475 On WinME, I appropriately get an AttributeError consistently for Py2.2, Py2.3, and Py2.4. Anthony, you've made the most recent updates to the signalmodule. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 From noreply at sourceforge.net Sat Dec 11 04:36:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 11 04:36:42 2004 Subject: [ python-Bugs-1082487 ] font lock keyword regular expressions Message-ID: Bugs item #1082487, was opened at 2004-12-09 16:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Brown (robert-brown) >Assigned to: Skip Montanaro (montanaro) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 From noreply at sourceforge.net Sat Dec 11 04:43:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 11 04:43:27 2004 Subject: [ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault Message-ID: Bugs item #1083110, was opened at 2004-12-10 13:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Sam Rushing (rushing) >Assigned to: A.M. Kuchling (akuchling) Summary: truncated gzip file triggers zlibmodule segfault Initial Comment: If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:43 Message: Logged In: YES user_id=80475 On WinME, I can confirm segfaults in Py2.3 and Py2.4. Andrew, I think this is your baby. BTW, the OP's example would make an excellent testcase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 From noreply at sourceforge.net Sat Dec 11 17:18:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 11 17:19:03 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by childsplay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: stas Z (childsplay) Assigned to: M.-A. Lemburg (lemburg) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: stas Z (childsplay) Date: 2004-12-11 17:18 Message: Logged In: YES user_id=638376 I've looked at the CVS/locale.py but is the utf8 entry missing? Don't know about the X alias mapping, but I suspect that there should also be an utf8 entry also for nb_NO/nn_NO. (Just as there is for no_NO) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 22:58 Message: Logged In: YES user_id=38388 Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.29; previous revision: 1.28 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 14:16 Message: Logged In: YES user_id=38388 Well, if the alias mapping is good enough for X, then it's good enough for me :-) I think we ought to update the alias table with the current data of the X locale.alias file. This file also includes the mappings that childsplay mentioned. There also seems to be a bug in the encoding alias table: "utf" is no longer recognized by setlocale(). This should be changed to "utf8". I'll fix that and post an update here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Sun Dec 12 00:06:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 00:06:44 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-12 00:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sun Dec 12 09:43:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 09:43:29 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-05 04:42 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 19:43 Message: Logged In: YES user_id=250749 OS/2 specific fixes checked in. As there appears to be no further action required, I'm closing this item. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-20 22:03 Message: Logged In: YES user_id=11375 CVS finally came through, and r234 doesn't seem to report any problems; I put a debug print into joinpath() so I'm sure that it was actually being invoked. So I think this bug no longer applies, in the absence of a transcript demonstrating an actual problem. I'll reassign this bug to Andrew MacIntyre so that he knows about the OS/2 overflow and can fix it before his next OS/2 release. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-20 06:41 Message: Logged In: YES user_id=11375 OK; I think I've got it working now, and neither 2.4CVS or 2.3-maint run into any problems with the sharefuzz library in use. I'm trying to pull the r234 tag, but SF CVS is being really slow; I'll try it tomorrow. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-20 06:18 Message: Logged In: YES user_id=11375 I haven't figured out how to get sharefuzz to work yet, but did notice one OS/2 specific overflow; around line 3250 of posixmodule.c, it defines char args[1024], and then does a strcpy from the COMSPEC env. var. into args. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-10-20 06:10 Message: Logged In: YES user_id=11375 The URL mentioned for sharefuzz seems to be out of date; the correct location is now http://sourceforge.net/projects/sharefuzz/ . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-10 04:43 Message: Logged In: YES user_id=31435 vacuum, are you saying that sharefuzz provokes an actual bug in Python 2.4a2? In Python 2.3.4? ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-10 04:26 Message: Logged In: YES user_id=116409 Use the sharefuzz utility that I referenced in another comment. Then call any function that will invoke the joinpath function call. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-10 03:56 Message: Logged In: YES user_id=31435 The patch didn't intend to fix a bug that's known to exist. Python 2.0 presumably fixed the bugs here, but in a shaky way, relying on dozens of distinct call sites to establish an undocumented precondition. joinpath() suffers a buffer overrun if the precondition isn't met. The patch verifies that the precondition *is* met, killing the Python process if it's not. That should never happen, but joinpath() is called on so many distinct code paths that "eyeball analysis" is inadequate. To test the patch, change any of joinpath's call sites to violate the precondition, and see that Python dies then. The OP suggested a driver to provoke an envar attack, in the 2004-08-07 14:15 comment. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-10 03:39 Message: Logged In: YES user_id=11375 How would I go about testing the patch? Where can I find code that tickles the bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 11:01 Message: Logged In: YES user_id=31435 I checked in the attached patch too. If there's ever another release in the 2.3 line, these patches would make decent backport candidates. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-08 08:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 05:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 05:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 04:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 04:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-08 04:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 02:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-08 01:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sun Dec 12 09:53:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 09:53:51 2004 Subject: [ python-Bugs-1076819 ] test_shelve failures Message-ID: Bugs item #1076819, was opened at 2004-12-02 02:22 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: ====================================================================== FAIL: test_read (__main__.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestBinaryFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestProto2FileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 19:53 Message: Logged In: YES user_id=250749 Test works for me on FreeBSD 4.8. Make sure that you can use anydbm - more details on what db module is actually invoked by anydbm might help shed some more light on the matter (use the file utility on a database created with anydbm.open()). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-02 02:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:05:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:05:39 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-23 19:34 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Peter ?strand (astrand) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 20:05 Message: Logged In: YES user_id=250749 As a Cygwin specific issue, I'd suggest reassigning the bug to Jason Tishler (jlt63) who maintains the Cygwin port. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-06 01:43 Message: Logged In: YES user_id=344921 This seems to be a Cygwin bug: p.stdout.read() only returns a partial result. Another p.stdout.read() is necessary to retrieve all data. fileobject.read should return all data, though. It doesn't, because fread() is behaving strange: It returns a short read, but neither feof() nor ferror() is set. This is wrong: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered." One strange thing is that this only happens if close-on-exec is used for the error pipe. Perhaps a race condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:23:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:23:54 2004 Subject: [ python-Bugs-1077040 ] Error building _bsddb extension Message-ID: Bugs item #1077040, was opened at 2004-12-02 07:19 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Error building _bsddb extension Initial Comment: Trying to build Python 2.4 on Debian GNU/Linux 3.0 using gcc 3.3.4. BerkeleyDB version is 3.2, header is /usr/include/db.h, library in /usr/lib. Error: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fPIC -I. -I/usr/local/src/Python/Python-2.4/./Include -I/usr/local/include -I/usr/local/src/Python/Python-2.4/Include -I/usr/local/src/Python/Python-2.4 -c /usr/local/src/Python/Python-2.4/Modules/_bsddb.c -o build/temp.linux-i686-2.4/_bsddb.o running build_scripts /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DB_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1464: error: structure has no member named `pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1482: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1483: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DBC_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2928: error: structure has no member named `c_pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2943: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2944: error: structure has no member named `primaryDBType' ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 20:23 Message: Logged In: YES user_id=250749 What are the DB_VERSION_MAJOR and DB_VERSION_MINOR macros defined to in your /usr/include/db.h? The primaryDBType symbol is only referenced in code compiled for DB versions 3.3 and higher, and the pget symbol is referenced in code compiled for DB 3.2 and higher. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:25:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:25:29 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:36:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:36:30 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-23 09:34 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2004-12-12 10:36 Message: Logged In: YES user_id=344921 Reassigned to jlt63. See http://cygwin.com/ml/cygwin/2004-12/msg00135.html and http://sources.redhat.com/ml/newlib/2004/msg00559.html for details. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 10:05 Message: Logged In: YES user_id=250749 As a Cygwin specific issue, I'd suggest reassigning the bug to Jason Tishler (jlt63) who maintains the Cygwin port. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-05 15:43 Message: Logged In: YES user_id=344921 This seems to be a Cygwin bug: p.stdout.read() only returns a partial result. Another p.stdout.read() is necessary to retrieve all data. fileobject.read should return all data, though. It doesn't, because fread() is behaving strange: It returns a short read, but neither feof() nor ferror() is set. This is wrong: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered." One strange thing is that this only happens if close-on-exec is used for the error pipe. Perhaps a race condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:55:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:55:19 2004 Subject: [ python-Bugs-1080811 ] full test with all unicode text files Message-ID: Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Comment added) made by makaron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. ---------------------------------------------------------------------- >Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-12 10:55 Message: Logged In: YES user_id=115179 works like a harm - but i dont know why 255 tests OK. 35 tests skipped: test__locale test_aepack test_al test_applesingle test_cd test_cl test_commands test_curses test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_imgfile test_ioctl test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_sunaudiodev test_threadsignals test_timing Those skips are all expected on win32. :) nice python ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-10 09:54 Message: Logged In: YES user_id=115179 my system is windows 2000 pro sp4 with latest fixes from ms, polish language, python from cvs (head), msvc 7.1 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-09 20:06 Message: Logged In: YES user_id=89016 I can't reproduce this on Linux. Putting JOHAB.TXT (and the other files) into the current directory (dist from a CVS checkout) and running "python Lib/test/regrtest.py" works. Putting all the files into Lib/test and running regrtest.py from there works too. Which version of Python are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:56:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:56:21 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 04:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 04:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Sun Dec 12 10:56:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 10:56:40 2004 Subject: [ python-Bugs-1080811 ] full test with all unicode text files Message-ID: Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Settings changed) made by makaron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug >Status: Closed Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-12 10:55 Message: Logged In: YES user_id=115179 works like a harm - but i dont know why 255 tests OK. 35 tests skipped: test__locale test_aepack test_al test_applesingle test_cd test_cl test_commands test_curses test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_imgfile test_ioctl test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_sunaudiodev test_threadsignals test_timing Those skips are all expected on win32. :) nice python ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-10 09:54 Message: Logged In: YES user_id=115179 my system is windows 2000 pro sp4 with latest fixes from ms, polish language, python from cvs (head), msvc 7.1 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-09 20:06 Message: Logged In: YES user_id=89016 I can't reproduce this on Linux. Putting JOHAB.TXT (and the other files) into the current directory (dist from a CVS checkout) and running "python Lib/test/regrtest.py" works. Putting all the files into Lib/test and running regrtest.py from there works too. Which version of Python are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 From noreply at sourceforge.net Sun Dec 12 11:47:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 11:47:41 2004 Subject: [ python-Bugs-1077040 ] Error building _bsddb extension Message-ID: Bugs item #1077040, was opened at 2004-12-01 23:19 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: Error building _bsddb extension Initial Comment: Trying to build Python 2.4 on Debian GNU/Linux 3.0 using gcc 3.3.4. BerkeleyDB version is 3.2, header is /usr/include/db.h, library in /usr/lib. Error: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fPIC -I. -I/usr/local/src/Python/Python-2.4/./Include -I/usr/local/include -I/usr/local/src/Python/Python-2.4/Include -I/usr/local/src/Python/Python-2.4 -c /usr/local/src/Python/Python-2.4/Modules/_bsddb.c -o build/temp.linux-i686-2.4/_bsddb.o running build_scripts /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DB_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1464: error: structure has no member named `pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1482: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1483: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DBC_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2928: error: structure has no member named `c_pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2943: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2944: error: structure has no member named `primaryDBType' ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2004-12-12 13:47 Message: Logged In: YES user_id=4799 #define DB_VERSION_MAJOR 3 #define DB_VERSION_MINOR 2 #define DB_VERSION_PATCH 9 #define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 3.2.9: (April 7, 2002)" ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 12:23 Message: Logged In: YES user_id=250749 What are the DB_VERSION_MAJOR and DB_VERSION_MINOR macros defined to in your /usr/include/db.h? The primaryDBType symbol is only referenced in code compiled for DB versions 3.3 and higher, and the pget symbol is referenced in code compiled for DB 3.2 and higher. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 From noreply at sourceforge.net Sun Dec 12 17:06:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 17:06:10 2004 Subject: [ python-Bugs-1083895 ] functions replaced should point to its docs Message-ID: Bugs item #1083895, was opened at 2004-12-12 17:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) Summary: functions replaced should point to its docs Initial Comment: We should either move or copy the "Replacing Older Functions with the subprocess Module" section to the documentation of the functions that are replaced by subprocess. See http://mail.python.org/pipermail/python-dev/2004-December/050266.html, for non-subprocess specific rationale. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470 From noreply at sourceforge.net Sun Dec 12 17:06:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 12 17:06:34 2004 Subject: [ python-Bugs-1083895 ] functions replaced by subprocess should point to its docs Message-ID: Bugs item #1083895, was opened at 2004-12-12 17:06 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) >Summary: functions replaced by subprocess should point to its docs Initial Comment: We should either move or copy the "Replacing Older Functions with the subprocess Module" section to the documentation of the functions that are replaced by subprocess. See http://mail.python.org/pipermail/python-dev/2004-December/050266.html, for non-subprocess specific rationale. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470 From noreply at sourceforge.net Mon Dec 13 10:29:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 10:29:25 2004 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by kerofin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 09:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 17:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 16:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Mon Dec 13 11:07:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 11:07:50 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 11:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Mon Dec 13 13:07:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 13:07:47 2004 Subject: [ python-Bugs-991754 ] _bsddb segfault Message-ID: Bugs item #991754, was opened at 2004-07-15 10:27 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Jim Fulton (dcjim) Assigned to: Gregory P. Smith (greg) Summary: _bsddb segfault Initial Comment: I have to remove the _bsddb extension to run the Python tests. Otherwise I get a segfault when test_anydbm is run. I also get a segfault running test_bsddb uname -r 2.4.22-1.2188.nptlsmp rpm -q db4 db4-4.1.25-14 gdb ./python GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r -E -tt ./Lib/test/regrtest.py -vv test_bsddb Starting program: /home/jim/src/python/cvs2/dist/src/python -E -tt ./Lib/test/regrtest.py -vv test_bsddb [Thread debugging using libthread_db enabled] [New Thread -1084317568 (LWP 19122)] test_bsddb test__no_deadlock_first (test.test_bsddb.TestBTree) ... ERROR Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1084317568 (LWP 19122)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () (gdb) r -E -tt ./Lib/test/regrtest.py -vv test_anydbm The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/jim/src/python/cvs2/dist/src/python -E -tt ./Lib/test/regrtest.py -vv test_anydbm [Thread debugging using libthread_db enabled] [New Thread -1084645248 (LWP 19132)] test_anydbm test_anydbm_creation (test.test_anydbm.AnyDBMTestCase) ... ERROR Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1084645248 (LWP 19132)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:07 Message: Logged In: YES user_id=413 I just rewrote the setup.py section that finds the header and library file for use when building the bsddb module. Previously it could pick different versions of the header + lib which would compile and link fine but fail at runtime. Its checked in to HEAD. Could you try that out and let me know if that fixes anything for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470 From noreply at sourceforge.net Mon Dec 13 13:13:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 13:14:01 2004 Subject: [ python-Bugs-1077040 ] Error building _bsddb extension Message-ID: Bugs item #1077040, was opened at 2004-12-01 12:19 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Oleg Broytmann (phd) >Assigned to: Gregory P. Smith (greg) Summary: Error building _bsddb extension Initial Comment: Trying to build Python 2.4 on Debian GNU/Linux 3.0 using gcc 3.3.4. BerkeleyDB version is 3.2, header is /usr/include/db.h, library in /usr/lib. Error: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fPIC -I. -I/usr/local/src/Python/Python-2.4/./Include -I/usr/local/include -I/usr/local/src/Python/Python-2.4/Include -I/usr/local/src/Python/Python-2.4 -c /usr/local/src/Python/Python-2.4/Modules/_bsddb.c -o build/temp.linux-i686-2.4/_bsddb.o running build_scripts /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DB_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1464: error: structure has no member named `pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1482: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1483: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DBC_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2928: error: structure has no member named `c_pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2943: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2944: error: structure has no member named `primaryDBType' ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:13 Message: Logged In: YES user_id=413 Yes this is easy to reproduce. At the moment the preferred workaround is to use a more recent version of BerkeleyDB <= 4.2 (4.3 support has not yet been committed to the 2.4 maintenance branch). I'll fix this so that 3.2 works again shortly. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-12 02:47 Message: Logged In: YES user_id=4799 #define DB_VERSION_MAJOR 3 #define DB_VERSION_MINOR 2 #define DB_VERSION_PATCH 9 #define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 3.2.9: (April 7, 2002)" ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 01:23 Message: Logged In: YES user_id=250749 What are the DB_VERSION_MAJOR and DB_VERSION_MINOR macros defined to in your /usr/include/db.h? The primaryDBType symbol is only referenced in code compiled for DB versions 3.3 and higher, and the pget symbol is referenced in code compiled for DB 3.2 and higher. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 From noreply at sourceforge.net Mon Dec 13 13:15:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 13:15:50 2004 Subject: [ python-Bugs-1033390 ] build doesn't pick up bsddb w/Mandrake 9.2 Message-ID: Bugs item #1033390, was opened at 2004-09-23 06:58 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Gregory P. Smith (greg) Summary: build doesn't pick up bsddb w/Mandrake 9.2 Initial Comment: Mandrake 9.2 installs bsddb 4.1 under /usr/lib, and apparently Python 2.4a3's setup.py doesn't pick it up -- adding /usr/lib to the list of directories where bsddb 4 is being searched for, and rerunning make, seems to fix the problem. (Problem does not appear on Mandrake 9.1, where I had installed sleepycat's stuff under /usr/local/BerkeleyDB.4.1 "by hand"; nor on MacOSX, where I had a fink-installed one in /sw/lib; no similar problem with any other module on any of these platforms, except bsddb). ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:15 Message: Logged In: YES user_id=413 Could you try this again using python CVS HEAD. I just committed a rework of setup.py's bsddb library+include file finding code that hopefully does the right thing for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1033390&group_id=5470 From noreply at sourceforge.net Mon Dec 13 13:17:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 13:17:44 2004 Subject: [ python-Bugs-994100 ] seg fault when calling bsddb.hashopen() Message-ID: Bugs item #994100, was opened at 2004-07-19 14:21 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Gregory P. Smith (greg) Summary: seg fault when calling bsddb.hashopen() Initial Comment: Fresh 2.3.4 build (didn't even install!) on Mandrake 8.1-ish system using Berkeley DB 3.3 yields this output when trying to create a new hash db: Python 2.3.4 (#1, Jul 19 2004, 16:02:09) [GCC 3.0.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__file__ '/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc' >>> bsddb.hashopen("foo.db", "c") Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 22763)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x404e284b in newDBObject (arg=0x0, flags=0) at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697 #2 0x404ee808 in DB_construct (self=0x0, args=0x401a602c, kwargs=0x0) at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322 #3 0x080f718a in PyCFunction_Call (func=0x4047344c, arg=0x401a602c, kw=0x0) at Objects/methodobject.c:93 #4 0x080b122d in call_function (pp_stack=0xbffff31c, oparg=0) at Python/ceval.c:3439 #5 0x080af680 in eval_frame (f=0x8195a0c) at Python/ceval.c:2116 #6 0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60, globals=0x404859bc, locals=0x0, args=0x818e13c, argcount=2, kws=0x818e144, kwcount=0, defs=0x404868f8, defcount=8, closure=0x0) at Python/ceval.c:2663 #7 0x080b2ea1 in fast_function (func=0x40486454, pp_stack=0xbffff4bc, n=2, na=2, nk=0) at Python/ceval.c:3529 #8 0x080b1119 in call_function (pp_stack=0xbffff4bc, oparg=2) at Python/ceval.c:3458 #9 0x080af680 in eval_frame (f=0x818dfec) at Python/ceval.c:2116 #10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920, globals=0x401bd79c, locals=0x401bd79c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2663 #11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920, globals=0x401bd79c, locals=0x401bd79c) at Python/ceval.c:537 #12 0x080d34ab in run_node (n=0x401a6a88, filename=0x80f9fe8 "", globals=0x401bd79c, locals=0x401bd79c, flags=0xbffff6cc) at Python/pythonrun.c:1267 #13 0x080d185c in PyRun_InteractiveOneFlags (fp=0x4019cf60, filename=0x80f9fe8 "", flags=0xbffff6cc) at Python/pythonrun.c:757 #14 0x080d164e in PyRun_InteractiveLoopFlags (fp=0x4019cf60, filename=0x80f9fe8 "", flags=0xbffff6cc) at Python/pythonrun.c:690 #15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, filename=0x80f9fe8 "", closeit=0, flags=0xbffff6cc) at Python/pythonrun.c:653 #16 0x0805508c in Py_Main (argc=1, argv=0xbffff7a4) at Modules/main.c:415 #17 0x08054a99 in main (argc=1, argv=0xbffff7a4) at Modules/python.c:23 #18 0x400825b0 in __libc_start_main () from /lib/libc.so.6 ldd tells me this is how it's linked: % ldd build/lib.linux-i686-2.3/_bsddb.so libdb-3.3.so => /lib/libdb-3.3.so (0x40022000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000) libc.so.6 => /lib/libc.so.6 (0x400ba000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) What's the oldest Berkeley DB usable with the bsddb package? According to the README file versions 3.1 through 4.1 are supported. According to Modules/_bsddb.c versions 3.2 through 4.2 are supported. According to comments in setup.py 3.1 is only partially supported. I'm wondering if maybe the bar has been raised even higher and 3.3 is no longer supported. Skip ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:17 Message: Logged In: YES user_id=413 I just committed a rewrite of the bsddb library+include file finding portion of python's setup.py. Could you try python CVS head on the system you had this problem on? It should now pick a properly paired header file and library version. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-07-19 19:22 Message: Logged In: YES user_id=44345 I rebuilt it with 3.3, but noticed something I had missed when it compiled before: gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.3.2/include -I. -I/home/skip/src/Python-2.3.4/./Include -I/usr/local/include -I/home/skip/src/Python-2.3.4/Include -I/home/skip/src/Python-2.3.4 -c /home/skip/src/Python-2.3.4/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/lib -ldb-3.3 -o build/lib.linux-i686-2.3/_bsddb.so Note that it searches /usr/local/BerkeleyDB.3.2/include for include files, but fails to search /usr/local/BerkeleyDB.3.2/lib for so files. (There are none there, just a .a file.) Consequently, it includes the 3.2 header files and links against the 3.3 so files. Definitely a recipe for disaster. Here's the proof: >>> from bsddb import db >>> print db.DB_VERSION_STRING Sleepycat Software: Berkeley DB 3.2.9: (January 24, 2001) >>> print 'bsddb.db.version(): %s' % (db.version(), ) bsddb.db.version(): (3, 3, 11) >>> print 'bsddb.db.__version__: %s' % db.__version__ bsddb.db.__version__: 4.2.0.2 >>> print 'bsddb.db.cvsid: %s' % db.cvsid bsddb.db.cvsid: $Id: _bsddb.c,v 1.17.6.4 2004/03/16 07:47:45 greg Exp $ I manually compiled without the -I flag and relinked. Opening a new db file worked like a charm. It would thus appear to be a combination of an incomplete 3.2 installation coupled with maybe some subtle breakage in setup.py. I'll leave it for you to close. I don't know if it's worth comparing information from the header files and the shared library during import. It certainly would have helped here though. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-07-19 15:05 Message: Logged In: YES user_id=413 it -should- work with 3.2 and later. that said, its been a while since i've tested using 3.2 or 3.3. Can you do one more thing for me against your _bsddb.so that appearred to be linked with 3.3? from bsddb import db print db.DB_VERSION_STRING print 'bsddb.db.version(): %s' % (db.version(), ) print 'bsddb.db.__version__: %s' % db.__version__ print 'bsddb.db.cvsid: %s' % db.cvsid just to make sure that the header files it compiled with match the version the dynamic loader decided to link it with. i've seen problems with that in the past. i'll built it against 3.2 and 3.3 later tonight and run the testsuites locally. if it doesn't work with those without an obvious reason+fix i'll just mark them as unsupported. 4.0 has been around for a long time now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-07-19 14:43 Message: Logged In: YES user_id=44345 I downloaded and installed BerkDB 4.2.52, then rebuilt bsddb using it. The results are more promising: % ./python Python 2.3.4 (#1, Jul 19 2004, 16:02:09) [GCC 3.0.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__file__ '/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc' >>> bsddb.hashopen("junk.db", "c") {} >>> You have new mail in /var/spool/mail/skip % ldd build/lib.linux-i686-2.3/_bsddb.so libdb-4.2.so => /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so (0x40016000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400d4000) libc.so.6 => /lib/libc.so.6 (0x400dc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470 From noreply at sourceforge.net Mon Dec 13 13:40:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 13:40:43 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) >Assigned to: Martin v. L?wis (loewis) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Mon Dec 13 13:41:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 13:41:48 2004 Subject: [ python-Bugs-1083895 ] functions replaced by subprocess should point to its docs Message-ID: Bugs item #1083895, was opened at 2004-12-12 11:06 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) >Assigned to: Peter ?strand (astrand) Summary: functions replaced by subprocess should point to its docs Initial Comment: We should either move or copy the "Replacing Older Functions with the subprocess Module" section to the documentation of the functions that are replaced by subprocess. See http://mail.python.org/pipermail/python-dev/2004-December/050266.html, for non-subprocess specific rationale. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083895&group_id=5470 From noreply at sourceforge.net Mon Dec 13 14:01:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 14:01:57 2004 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-13 13:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 09:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 17:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 16:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Mon Dec 13 14:13:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 14:13:38 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Martin v. L?wis (loewis) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 08:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Mon Dec 13 14:16:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 14:16:47 2004 Subject: [ python-Bugs-1083177 ] Change in signal function in the signal module Message-ID: Bugs item #1083177, was opened at 2004-12-11 07:58 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary H. Loechelt (loechelt) Assigned to: Anthony Baxter (anthonybaxter) Summary: Change in signal function in the signal module Initial Comment: The signal function of the signal module handles arguments differently in Python 2.4 than in Python 2.3. I am running on an HP-UX 11 workstation. If I set a handler for a signal that cannot be trapped, like KILL (signal 9), the signal function accepts the argument in Python 2.3 but ignores the operation. However, if I do the same thing in Python 2.4, the signal function rejects the argument and raises a RuntimeError. I am not sure if this change in behavior is intentional or not. It makes sense in one way to complain about an invalid argument (as in Python 2.4) rather than just ignore the operation (as in Python 2.3). However, I did not find this change in either the documentation or the release notes, and it caught me by surprise. Granted, the stricter argument checking probably caught a sloppy line of coding. Still, some kind of user warning would have been nice if this was an intentional change. I am enclosing a simple Python script which illustrates the problem. It finishes normally when using Python 2.3 and raises a RuntimeError when using Python 2.4: Traceback (most recent call last): File "set_signals.py", line 7, in ? signal.signal(signal.SIGKILL, dummy) RuntimeError: (22, 'Invalid argument') Gary H. Loechelt ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-14 00:16 Message: Logged In: YES user_id=29957 This is a deliberate change - "errors should not pass silently". I agree that it should get better visibility. Perhaps an entry in amk's what's new document in the section on Porting to 2.4 would be appropriate. AMK? (I've added a comment to the document as a reminder) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-11 14:32 Message: Logged In: YES user_id=80475 On WinME, I appropriately get an AttributeError consistently for Py2.2, Py2.3, and Py2.4. Anthony, you've made the most recent updates to the signalmodule. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083177&group_id=5470 From noreply at sourceforge.net Mon Dec 13 14:19:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 14:19:54 2004 Subject: [ python-Bugs-1078245 ] Python2.4: building '_socket' extension fails with `INET_ADD Message-ID: Bugs item #1078245, was opened at 2004-12-03 22:16 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.4: building '_socket' extension fails with `INET_ADD Initial Comment: HI! I'm trying to build Python2.4 on a rather old Debian machine. Building _socket fails (see below) although I tried to use configure --disable-ipv6 I've added #define INET_ADDRSTRLEN 16 to Modules/socketmodule.h which made it work. There were no problems compiling Python2.2 on the very same machine. Ciao, Michael. ------------------------------ snip ------------------------------ building '_socket' extension gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/tmp/Python-2.4/./Include -I/user/W3311/local/include -I/usr/local/include -I/tmp/Python-2.4/Include -I/tmp/Python-2.4 -c /tmp/Python-2.4/Modules/socketmodule.c -o build/t emp.linux-i686-2.4/socketmodule.o /tmp/Python-2.4/Modules/socketmodule.c: In function `socket_inet_ntop': /tmp/Python-2.4/Modules/socketmodule.c:3350: `INET_ADDRSTRLEN' undeclared (first use this function) /tmp/Python-2.4/Modules/socketmodule.c:3350: (Each undeclared identifier is reported only once /tmp/Python-2.4/Modules/socketmodule.c:3350: for each function it appears in.) /tmp/Python-2.4/Modules/socketmodule.c:3350: size of array `ip' has non-integer type ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-14 00:19 Message: Logged In: YES user_id=29957 How old a debian release is this? It sounds like it's a just a broken system header, and I'm not entirely convinced that adding this to the already-large collection of #ifdefs in socketmodule is a path to happiness. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078245&group_id=5470 From noreply at sourceforge.net Mon Dec 13 14:46:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 14:46:10 2004 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: Bugs item #1075984, was opened at 2004-11-30 13:13 Message generated for change (Comment added) made by kerofin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: Memory fault pyexpat.so on SGI Initial Comment: I build the latest RC1 of python 2.4. System SGI Fuel IP35, Irix 6.5.26m cc -version MIPSpro Compilers: Version 7.3.1.3m - make tests passes test_pyexpat without error - running this code leads to a core dump -- code --- import xml.dom.minidom doc = xml.dom.minidom.parseString(fstream) <<< core dump >>> --- runing python -v test.py # /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc matches /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py import xml.dom.expatbuilder # precompiled from /opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc import xml.parsers # directory /opt/python24c1/lib/python2.4/xml/parsers # /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/__init__.py import xml.parsers # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc # /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py import xml.parsers.expat # precompiled from /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so", 2); Memory fault(coredump) - running this code from an interactive session leads not to a coredump I need some assistance howto provide further debug information. --maik./ ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 13:46 Message: Logged In: YES user_id=471223 pyexpat initializes using its internal copy of expat. libexpat.so is still mapped in (after pyexpat has initilized), but gdb finds the python copy of XML_ErrorString and other functions. I suspect that this will be a problem if the system version of expat is newer than Python's. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-13 13:01 Message: Logged In: YES user_id=6656 1) Good sleuthing. 2) Argh! 3) What happens if you import pyexpat before pygtk? ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-13 09:29 Message: Logged In: YES user_id=471223 I've looked at the program that was dumping core and the sequence is this: 1) Program imports pygtk, which links in the GTK libraries 2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so 3) Program imports pyexpat. 4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so. 5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core. ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 17:01 Message: Logged In: YES user_id=471223 Maybe it compiled against its own copy of expat, but pulled in the system's copy when run? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-10 16:52 Message: Logged In: YES user_id=6656 Uh, Python includes its own copy of expat, and I really thought we were supposed to prefer our own version over anything found on the system... ---------------------------------------------------------------------- Comment By: Stephen Watson (kerofin) Date: 2004-12-10 16:46 Message: Logged In: YES user_id=471223 I also got a core dump importing pyexpat on Solaris (SPARC) and somebody else reported it on a *BSD system. It appears to be a problem with older versions of expat not being tested for. I used gdb to trace it down to line 1972 in pyexpat.c where it attempts to define the first constant from 1.95.8. I had expat 1.95.7. After upgrading to 1.95.8 it worked fine, as did the *BSD system. I think Python needs to check the expat version, as it does elsewhere in the file, before defining those constants. I am still puzzelled over how it managed to compile pyexpat.c in the first place... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470 From noreply at sourceforge.net Mon Dec 13 16:26:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 16:26:43 2004 Subject: [ python-Bugs-1084457 ] ossaudiodev no longer undocumented Message-ID: Bugs item #1084457, was opened at 2004-12-13 10:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: ossaudiodev no longer undocumented Initial Comment: The ossaudiodev module can be removed from the list of undocumented multimedia modules, since documentation now exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470 From noreply at sourceforge.net Mon Dec 13 16:38:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 16:39:12 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 04:07 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Martin v. L?wis (loewis) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 09:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 06:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Mon Dec 13 16:45:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 16:45:55 2004 Subject: [ python-Bugs-1082874 ] Unable to see Python binary Message-ID: Bugs item #1082874, was opened at 2004-12-10 07:26 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Prabal Rakshit (prabal_rakshit) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to see Python binary Initial Comment: After extracting the Python-2.3.3.tar we could get the appropriate folder structure. We then executed the configure script. Therafter when we execute the make command the Python binary is not created in /usr/local/bin. Any pointers?? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2004-12-13 10:45 Message: Logged In: YES user_id=11365 Are you running "make install" after "make" ? You could try explicitly giving an installation prefix: ./configure --prefix=/usr/local Otherwise you can look for newly created files like this: find /usr -mmin -5 Hope this helps. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2004-12-10 16:19 Message: Logged In: YES user_id=49843 The 'make install' target will copy the built binary to '/usr/local/bin'. Did you try 'make install' yet? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082874&group_id=5470 From noreply at sourceforge.net Mon Dec 13 19:12:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 19:18:26 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Martin v. L?wis (loewis) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 13:12 Message: Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 10:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 08:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Mon Dec 13 20:04:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 20:04:27 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-22 23:34 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2004-12-13 10:04 Message: Logged In: YES user_id=86216 I will look into this problem and why test_shutil failed until someone hacked the regression test so it passes under Cygwin now. Unfortunately, it may be a while before I find adequate time to debug this problem. ;,( Peter, Since you have already devised a test case, would you be willing to go to the next step and fire up gdb? Any help is greatly appreciated. Thanks. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-12 00:36 Message: Logged In: YES user_id=344921 Reassigned to jlt63. See http://cygwin.com/ml/cygwin/2004-12/msg00135.html and http://sources.redhat.com/ml/newlib/2004/msg00559.html for details. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 00:05 Message: Logged In: YES user_id=250749 As a Cygwin specific issue, I'd suggest reassigning the bug to Jason Tishler (jlt63) who maintains the Cygwin port. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-05 05:43 Message: Logged In: YES user_id=344921 This seems to be a Cygwin bug: p.stdout.read() only returns a partial result. Another p.stdout.read() is necessary to retrieve all data. fileobject.read should return all data, though. It doesn't, because fread() is behaving strange: It returns a short read, but neither feof() nor ferror() is set. This is wrong: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered." One strange thing is that this only happens if close-on-exec is used for the error pipe. Perhaps a race condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Mon Dec 13 20:04:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 20:04:39 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 11:07 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Martin v. L?wis (loewis) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Antoine Pitrou (pitrou) Date: 2004-12-13 20:04 Message: Logged In: YES user_id=133955 I'm gonna ask a stupid question (I'm quite a beginner in Python). Why isn't there a %f-life formatting code for doing just what you wrote - printing the float in full precision in non-exponent format ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 19:12 Message: Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 16:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 14:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 13:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Mon Dec 13 20:21:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 20:21:27 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-23 09:34 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2004-12-13 20:21 Message: Logged In: YES user_id=344921 I don't think gdb is necessary: we already know the problem: newlib doesn't loop around read() until all data is read. Some Cygwin people seems to think that this is not a bug, but I don't agree. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-12-13 20:04 Message: Logged In: YES user_id=86216 I will look into this problem and why test_shutil failed until someone hacked the regression test so it passes under Cygwin now. Unfortunately, it may be a while before I find adequate time to debug this problem. ;,( Peter, Since you have already devised a test case, would you be willing to go to the next step and fire up gdb? Any help is greatly appreciated. Thanks. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-12 10:36 Message: Logged In: YES user_id=344921 Reassigned to jlt63. See http://cygwin.com/ml/cygwin/2004-12/msg00135.html and http://sources.redhat.com/ml/newlib/2004/msg00559.html for details. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 10:05 Message: Logged In: YES user_id=250749 As a Cygwin specific issue, I'd suggest reassigning the bug to Jason Tishler (jlt63) who maintains the Cygwin port. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-05 15:43 Message: Logged In: YES user_id=344921 This seems to be a Cygwin bug: p.stdout.read() only returns a partial result. Another p.stdout.read() is necessary to retrieve all data. fileobject.read should return all data, though. It doesn't, because fread() is behaving strange: It returns a short read, but neither feof() nor ferror() is set. This is wrong: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered." One strange thing is that this only happens if close-on-exec is used for the error pipe. Perhaps a race condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Mon Dec 13 20:58:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 20:58:11 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: stas Z (childsplay) Assigned to: M.-A. Lemburg (lemburg) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-13 20:58 Message: Logged In: YES user_id=38388 Thanks. I've noticed that the C lib doesn't seem to like "UTF-8" but works well with "UTF8" (no hyphen). Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.30; previous revision: 1.29 done Checking in Tools/i18n/makelocalealias.py; /cvsroot/python/python/dist/src/Tools/i18n/makelocalealias.py,v <-- makelocalealias.py new revision: 1.2; previous revision: 1.1 done Please check again with the updated version. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-11 17:18 Message: Logged In: YES user_id=638376 I've looked at the CVS/locale.py but is the utf8 entry missing? Don't know about the X alias mapping, but I suspect that there should also be an utf8 entry also for nb_NO/nn_NO. (Just as there is for no_NO) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 22:58 Message: Logged In: YES user_id=38388 Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.29; previous revision: 1.28 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 14:16 Message: Logged In: YES user_id=38388 Well, if the alias mapping is good enough for X, then it's good enough for me :-) I think we ought to update the alias table with the current data of the X locale.alias file. This file also includes the mappings that childsplay mentioned. There also seems to be a bug in the encoding alias table: "utf" is no longer recognized by setlocale(). This should be changed to "utf8". I'll fix that and post an update here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Mon Dec 13 23:19:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 13 23:20:00 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Martin v. L?wis (loewis) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 17:19 Message: Logged In: YES user_id=80475 Various slightly unsatisfactory answers: * It started out that way because that's what C did. * It stayed that way because no one has requested it * It may be that outside of XMLRPC there are very few valid use cases. * Future needs can be met by the decimal module. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2004-12-13 14:04 Message: Logged In: YES user_id=133955 I'm gonna ask a stupid question (I'm quite a beginner in Python). Why isn't there a %f-life formatting code for doing just what you wrote - printing the float in full precision in non-exponent format ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 13:12 Message: Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 10:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 08:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Tue Dec 14 00:41:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 00:41:30 2004 Subject: [ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin Message-ID: Bugs item #1084766, was opened at 2004-12-13 18:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 From noreply at sourceforge.net Tue Dec 14 06:11:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 06:11:46 2004 Subject: [ python-Bugs-1084906 ] list initialization bug Message-ID: Bugs item #1084906, was opened at 2004-12-14 00:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084906&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: py_py (pingpy) Assigned to: Nobody/Anonymous (nobody) Summary: list initialization bug Initial Comment: Python 2.3.4 running on Linux Redhat 9.1 The following initialization produces an unwanted (I think) side effect, a,b=2*[[0]*2] It seems that both a and b point to the same address For example, a[1]=1 gives me a=[0,1] but produces, as a side effect, b=[0,1] !!!! However, the following works a,b = [[0]*2,[0]*2] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084906&group_id=5470 From noreply at sourceforge.net Tue Dec 14 08:01:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 08:01:34 2004 Subject: [ python-Bugs-1084906 ] list initialization bug Message-ID: Bugs item #1084906, was opened at 2004-12-14 00:11 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084906&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: py_py (pingpy) Assigned to: Nobody/Anonymous (nobody) Summary: list initialization bug Initial Comment: Python 2.3.4 running on Linux Redhat 9.1 The following initialization produces an unwanted (I think) side effect, a,b=2*[[0]*2] It seems that both a and b point to the same address For example, a[1]=1 gives me a=[0,1] but produces, as a side effect, b=[0,1] !!!! However, the following works a,b = [[0]*2,[0]*2] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-14 02:01 Message: Logged In: YES user_id=80475 Thanks for the report; however, this is correct behavior. Learning about shallow vcrsus deep copies is a key to understanding the language. Start by reading the FAQ: http://www.python.org/doc/faq/programming.html#how-do-i-create-a-multidimensional-list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084906&group_id=5470 From noreply at sourceforge.net Tue Dec 14 08:20:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 08:20:53 2004 Subject: [ python-Bugs-1084457 ] ossaudiodev no longer undocumented Message-ID: Bugs item #1084457, was opened at 2004-12-13 10:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: ossaudiodev no longer undocumented Initial Comment: The ossaudiodev module can be removed from the list of undocumented multimedia modules, since documentation now exists. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-14 02:20 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084457&group_id=5470 From noreply at sourceforge.net Tue Dec 14 13:02:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 13:02:49 2004 Subject: [ python-Bugs-1085069 ] gethostbyaddr on redhat for multiple hostnames Message-ID: Bugs item #1085069, was opened at 2004-12-14 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085069&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Kirby (davekirby) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr on redhat for multiple hostnames Initial Comment: When running socket.gethostbyaddr against a host with multiple hostnames assigned to it, the behaviour does not work as advertised under Red Hat linux (tested with Fedora Core 2 and Red Hat 8 - other versions of Linux have not been tested). calling socket.gethostbyaddr from Windows or Mac OS X against a test machine set up with multiple hosts gives the correct result: >>> socket.gethostbyaddr('1.2.3.4') ('testhost2', ['testhost7', 'testhost', 'testhost1', 'testhost3', 'testhost4', 'testhost6', 'testhost5'], ['1.2.3.4']) >>> (The real IP address and hostnames have been changed for security). running the same thing from Linux only gives a single hostname, and the alias list is empty. Repeated calls to the same function cycles through the hostnames (or picks them at random): >>> socket.gethostbyaddr('1.2.3.4') ('testhost', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost1', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost3', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost4', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost6', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost5', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost2', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost7', [], ['1.2.3.4']) >>> socket.gethostbyaddr('1.2.3.4') ('testhost', [], ['1.2.3.4']) This behaviour has been seen with Python 2.2.1, 2.3.3 and 2.4-RC2. This is probably a bug in the underlying C function. According to the Linux man page, the POSIX gethostbyaddr has been superceded by getipnodebyaddr. This behaviour should at least be documented, and if possible fixed by using the new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085069&group_id=5470 From noreply at sourceforge.net Tue Dec 14 13:46:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 13:46:14 2004 Subject: [ python-Bugs-1085096 ] Fix stale link in PEP Message-ID: Bugs item #1085096, was opened at 2004-12-14 07:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085096&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Nobody/Anonymous (nobody) Summary: Fix stale link in PEP Initial Comment: As reported to webmaster by Laura Creighton: In PEP 754 IEEE 754 Floating Point Special Values http://www.analytics.washington.edu/statcomp/projects/rzope/fpconst/ is stale. SHould be http://research.warnes.net/projects/rzope/fpconst/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085096&group_id=5470 From noreply at sourceforge.net Tue Dec 14 13:58:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 13:58:11 2004 Subject: [ python-Bugs-1085096 ] Fix stale link in PEP Message-ID: Bugs item #1085096, was opened at 2004-12-14 13:46 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085096&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Nobody/Anonymous (nobody) Summary: Fix stale link in PEP Initial Comment: As reported to webmaster by Laura Creighton: In PEP 754 IEEE 754 Floating Point Special Values http://www.analytics.washington.edu/statcomp/projects/rzope/fpconst/ is stale. SHould be http://research.warnes.net/projects/rzope/fpconst/ ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-14 13:58 Message: Logged In: YES user_id=469548 She probably sent it to the PEP editors as well: David Goodger fixed it a couple of days ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085096&group_id=5470 From noreply at sourceforge.net Tue Dec 14 14:35:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 14:35:58 2004 Subject: [ python-Bugs-1071516 ] test_subprocess fails on cygwin Message-ID: Bugs item #1071516, was opened at 2004-11-22 23:34 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None >Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok ====================================================================== FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' ====================================================================== FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' ---------------------------------------------------------------------- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2004-12-14 04:35 Message: Logged In: YES user_id=86216 I'm happy to report the following newlib patch: http://sources.redhat.com/ml/newlib-cvs/2004- q4/msg00031.html fixes the report problem and test_subprocess passes under Cygwin CVS as of 20041214. test_subprocess should pass under Cygwin 1.5.13 (when released). Peter, thanks for helping to solve this problem. I really appreciate your help *and* perseverance. :,) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-13 10:21 Message: Logged In: YES user_id=344921 I don't think gdb is necessary: we already know the problem: newlib doesn't loop around read() until all data is read. Some Cygwin people seems to think that this is not a bug, but I don't agree. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-12-13 10:04 Message: Logged In: YES user_id=86216 I will look into this problem and why test_shutil failed until someone hacked the regression test so it passes under Cygwin now. Unfortunately, it may be a while before I find adequate time to debug this problem. ;,( Peter, Since you have already devised a test case, would you be willing to go to the next step and fire up gdb? Any help is greatly appreciated. Thanks. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-12 00:36 Message: Logged In: YES user_id=344921 Reassigned to jlt63. See http://cygwin.com/ml/cygwin/2004-12/msg00135.html and http://sources.redhat.com/ml/newlib/2004/msg00559.html for details. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 00:05 Message: Logged In: YES user_id=250749 As a Cygwin specific issue, I'd suggest reassigning the bug to Jason Tishler (jlt63) who maintains the Cygwin port. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-12-05 05:43 Message: Logged In: YES user_id=344921 This seems to be a Cygwin bug: p.stdout.read() only returns a partial result. Another p.stdout.read() is necessary to retrieve all data. fileobject.read should return all data, though. It doesn't, because fread() is behaving strange: It returns a short read, but neither feof() nor ferror() is set. This is wrong: "Upon successful completion, fread() shall return the number of elements successfully read which is less than nitems only if a read error or end-of-file is encountered." One strange thing is that this only happens if close-on-exec is used for the error pipe. Perhaps a race condition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 From noreply at sourceforge.net Tue Dec 14 16:05:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 16:05:57 2004 Subject: [ python-Bugs-1085168 ] Uninstaller unclear about the app it's uninstalling Message-ID: Bugs item #1085168, was opened at 2004-12-14 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Uninstaller unclear about the app it's uninstalling Initial Comment: The "Uninstall Python" link added to the start mrnu Python 2.4 folder asks "Are you sure you wish to uninstall this product?". This should really ask whether you wish to uninstall Python 2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470 From noreply at sourceforge.net Tue Dec 14 16:13:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 16:13:13 2004 Subject: [ python-Bugs-1085172 ] Uninstaller should restore file associations if possible Message-ID: Bugs item #1085172, was opened at 2004-12-14 15:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: Uninstaller should restore file associations if possible Initial Comment: On installing on Windows, the Python installer associates .py and .pyw files to the new installation of python. The installer should cache the previous associations, and in the event of uninstallation restore them to their previous values if the application the are associated with still exists. This allows for easier migration back to 2.3 in this case, but also for easier back migration in the case of installing a beta version of python 2.5 or whatever in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 From noreply at sourceforge.net Tue Dec 14 17:11:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 17:11:28 2004 Subject: [ python-Bugs-1076515 ] shutil.move clobbers read-only files. Message-ID: Bugs item #1076515, was opened at 2004-12-01 00:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Martin v. L?wis (loewis) Summary: shutil.move clobbers read-only files. Initial Comment: The summary states it fine. shutil.move happily overwrites read- only files. It looks like it indiscriminately catches OSError, and never bothers to check whether it's a permission error. It'd be nice if permission errors raised an exception that was a subclass of OSError, then it'd be cake to fix this (at least for *nices; I'm not sure about the Windows implications). According to tracker #810879, clobbering read-only files isn't the desired behavior for shutil.copyfile, so I doubt it's desired for shutil.move. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 17:21 Message: Logged In: YES user_id=469548 Your analysis is not correct. On Unix, you need write permission to the *directory* to rename. So the os.rename() call simply succeeds on a read-only file if you have write access to its parent directory. I think we could shield from this by always using the fallback implementation (copy2+unlink(src)), but I'm not sure what the implications of that would be (qua performance and cross-platform issues). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 From noreply at sourceforge.net Tue Dec 14 17:18:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 17:18:53 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 16:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Nobody/Anonymous (nobody) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Tue Dec 14 19:11:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 19:11:51 2004 Subject: [ python-Bugs-1085283 ] binascii.b2a_qp oddities Message-ID: Bugs item #1085283, was opened at 2004-12-14 13:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: binascii.b2a_qp oddities Initial Comment: [Python 2.5a0 (#9, Dec 8 2004, 12:37:01); the behaviours go way back.] binascii.b2a_qp has several quirks discovered when reimplementing. (1) It lets low bytes pass through unescaped -- e.g. binascii.b2a_qp('\x08') == '\x08' -- unless quotetabs is True. This looks to be an error in program logic at lines ~1165 and ~1234, unless this is intended (although quopri's internal version quotes them). This doesn't seem RFC 1521 compatible on my reading of section 5 (admittedly I only read it for the first time last week. :-) (2) It determines whether to enforce \n or \r\n by scanning the string for the first occurrence [which should be mentioned in the docs]. binascii.c does this by calling strchr, which stops at the first \x00. This means that: >>> s0 = "The quick " + chr(0) + "brown fox.\r\n" >>> s1 = "The quick " + chr(1) + "brown fox.\r\n" >>> binascii.b2a_qp(s0) 'The quick \x00brown fox.\n' >>> binascii.b2a_qp(s1) 'The quick \x01brown fox.\r\n' and related strangenesses. (3) The code escapes the period "." if and only if it's the second character in a line. I'm not sure why; the only mention I can find in 1521 is in appendix B of escaping a period ALONE on a line in some situations, which binascii.b2a_qp doesn't do in any event. This behaviour may be prescribed by some other spec but is strange enough to be mentioned in the docs if it's intentional. A new strictly RFC1521-compliant qp encoding would be a good thing if backwards compatibility prevents changing some of these. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&group_id=5470 From noreply at sourceforge.net Tue Dec 14 19:12:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 19:17:45 2004 Subject: [ python-Bugs-1085283 ] binascii.b2a_qp oddities Message-ID: Bugs item #1085283, was opened at 2004-12-14 13:11 Message generated for change (Settings changed) made by dsm001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 2 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: binascii.b2a_qp oddities Initial Comment: [Python 2.5a0 (#9, Dec 8 2004, 12:37:01); the behaviours go way back.] binascii.b2a_qp has several quirks discovered when reimplementing. (1) It lets low bytes pass through unescaped -- e.g. binascii.b2a_qp('\x08') == '\x08' -- unless quotetabs is True. This looks to be an error in program logic at lines ~1165 and ~1234, unless this is intended (although quopri's internal version quotes them). This doesn't seem RFC 1521 compatible on my reading of section 5 (admittedly I only read it for the first time last week. :-) (2) It determines whether to enforce \n or \r\n by scanning the string for the first occurrence [which should be mentioned in the docs]. binascii.c does this by calling strchr, which stops at the first \x00. This means that: >>> s0 = "The quick " + chr(0) + "brown fox.\r\n" >>> s1 = "The quick " + chr(1) + "brown fox.\r\n" >>> binascii.b2a_qp(s0) 'The quick \x00brown fox.\n' >>> binascii.b2a_qp(s1) 'The quick \x01brown fox.\r\n' and related strangenesses. (3) The code escapes the period "." if and only if it's the second character in a line. I'm not sure why; the only mention I can find in 1521 is in appendix B of escaping a period ALONE on a line in some situations, which binascii.b2a_qp doesn't do in any event. This behaviour may be prescribed by some other spec but is strange enough to be mentioned in the docs if it's intentional. A new strictly RFC1521-compliant qp encoding would be a good thing if backwards compatibility prevents changing some of these. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085283&group_id=5470 From noreply at sourceforge.net Tue Dec 14 19:43:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 19:43:35 2004 Subject: [ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info Message-ID: Bugs item #1085300, was opened at 2004-12-14 13:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walrus (unclewalrus) Assigned to: Nobody/Anonymous (nobody) Summary: Mac Library Modules 1.1.1 Bad Info Initial Comment: Document states that OS X's TextEdit only saves RTF files. This is incorrect; you can make a plaintext file by choosing 'Make Plain Text' from the Format menu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 From noreply at sourceforge.net Tue Dec 14 19:50:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 19:50:07 2004 Subject: [ python-Bugs-1085304 ] Make array.array pickle-able Message-ID: Bugs item #1085304, was opened at 2004-12-14 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085304&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Fleury (nidoizo) Assigned to: Nobody/Anonymous (nobody) Summary: Make array.array pickle-able Initial Comment: Make array.array pickle-able. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085304&group_id=5470 From noreply at sourceforge.net Tue Dec 14 19:50:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 19:50:50 2004 Subject: [ python-Bugs-1085304 ] Make array.array pickle-able Message-ID: Bugs item #1085304, was opened at 2004-12-14 13:50 Message generated for change (Settings changed) made by nidoizo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085304&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Fleury (nidoizo) >Assigned to: Raymond Hettinger (rhettinger) Summary: Make array.array pickle-able Initial Comment: Make array.array pickle-able. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085304&group_id=5470 From noreply at sourceforge.net Tue Dec 14 20:48:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 14 20:48:56 2004 Subject: [ python-Bugs-1080811 ] full test with all unicode text files Message-ID: Bugs item #1080811, was opened at 2004-12-07 19:53 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 Category: None Group: Not a Bug Status: Closed Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: full test with all unicode text files Initial Comment: samall bug? while performing full test on pythonthon core with all required files (unicode). This can be found when "python -u regrtest.py -uall" is executed - perhaps some encodings are not preserved - test_codecmaps_kr fails with message: "JOHAB.TXT not found, download from http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT " this file exists on my system and is placed in lib/test, as required. when its running as standalone test everything is OK. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-14 20:48 Message: Logged In: YES user_id=89016 You can download the files to the PCbuild directory and run the rt.bat script from there. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-12 10:55 Message: Logged In: YES user_id=115179 works like a harm - but i dont know why 255 tests OK. 35 tests skipped: test__locale test_aepack test_al test_applesingle test_cd test_cl test_commands test_curses test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_imgfile test_ioctl test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_sunaudiodev test_threadsignals test_timing Those skips are all expected on win32. :) nice python ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2004-12-10 09:54 Message: Logged In: YES user_id=115179 my system is windows 2000 pro sp4 with latest fixes from ms, polish language, python from cvs (head), msvc 7.1 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-09 20:06 Message: Logged In: YES user_id=89016 I can't reproduce this on Linux. Putting JOHAB.TXT (and the other files) into the current directory (dist from a CVS checkout) and running "python Lib/test/regrtest.py" works. Putting all the files into Lib/test and running regrtest.py from there works too. Which version of Python are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080811&group_id=5470 From noreply at sourceforge.net Wed Dec 15 03:42:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 03:43:06 2004 Subject: [ python-Feature Requests-1073198 ] Extension to optparse: options with facultative value Message-ID: Feature Requests item #1073198, was opened at 2004-11-25 09:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: pollastri (pollastri) >Assigned to: Greg Ward (gward) Summary: Extension to optparse: options with facultative value Initial Comment: When parsing command line options, I found very useful to have an option with a facultative value, able to do the following: 1-tell to me if the option was or was not seen on the command line, return the value None if the option was not seen; 2-if the option only was specified, return a default value. 3-if the option with a value was specified on the command line, return the specified value; A way to reach this goal can be the addition of a new value for the options actions in module optparse, it may be something like "store_with_default". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470 From noreply at sourceforge.net Wed Dec 15 03:45:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 03:45:48 2004 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 11:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Tim Peters (tim_one) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Wed Dec 15 03:49:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 03:49:33 2004 Subject: [ python-Feature Requests-1075902 ] ignore element format character for PyArg_ParseTuple Message-ID: Feature Requests item #1075902, was opened at 2004-11-30 05:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Sean Proctor (sproctor) Assigned to: Nobody/Anonymous (nobody) Summary: ignore element format character for PyArg_ParseTuple Initial Comment: Some kind of option to indicate there is an element, but we don't care about its value would be nice. It could be _. then an example would be: PyArg_ParseTuple (tuple, "_i", &my_int); This indicates that there is another value before the int, but we don't care about it one way or the other. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-14 21:49 Message: Logged In: YES user_id=80475 Am closing this RFE. It has a -1 from three developers. The benefits, if any, are minor and do not warrant the time to implement, test, document, etc. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-09 18:21 Message: Logged In: YES user_id=21627 So just call the variable _: PyObject *_; PyArg_ParseTuple(tuple, "Oi", &_, &my_int); Given that this is possible today already, I expect that this RFE will be considered so minor that it won't be implemented anytime soon. It increases the learning curve for a nearly-unnoticable convenience. ---------------------------------------------------------------------- Comment By: Sean Proctor (sproctor) Date: 2004-12-09 00:37 Message: Logged In: YES user_id=43755 that would turn my example into PyArg_ParseTuple (tuple, "Oi", _, &my_int); I don't particularly care. I thought it was a good suggestion. To me _ looks like a blank. I wouldn't really want to use it in a format string for something besides an any/none scenario. Your reasoning about preserving format characters seems really weak. You've never had a tuple where you didn't care about the value of each element? Somewhat separate topic. Could you say "PyArg_ParseTuple (tuple, "Oi", NULL, &my_int);" ? I guess that would be a less elegant way of doing what I intended. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-09 00:04 Message: Logged In: YES user_id=31435 If you want to make C code look like ML, declare PyObject** _; and use _ in the argument list. I'm -1 on this: the case has almost never arisen in my experience, and the limited pool of format characters should be preserved for high-value uses. ---------------------------------------------------------------------- Comment By: Sean Proctor (sproctor) Date: 2004-12-08 22:35 Message: Logged In: YES user_id=43755 If I use O, then I need to have a variable to store it in. I think it's less readable. Like with pattern matching in ML, you can use a variable instead of _, but it's not obvious that you aren't going to use that value. With some kind of place holder, this is made clear, and I don't need to create a variable to store a value that I don't care about. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 16:42 Message: Logged In: YES user_id=21627 What's wrong with using O as the format character? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1075902&group_id=5470 From noreply at sourceforge.net Wed Dec 15 04:09:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 04:09:53 2004 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 11:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Nobody/Anonymous (nobody) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-14 22:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Wed Dec 15 07:17:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 07:17:32 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 18:25 Message generated for change (Comment added) made by salyee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 15:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 18:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Wed Dec 15 09:50:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 09:50:44 2004 Subject: [ python-Bugs-1071248 ] Documented grammar for List displays incorrect (testlist) Message-ID: Bugs item #1071248, was opened at 2004-11-22 21:26 Message generated for change (Comment added) made by grubert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: Documented grammar for List displays incorrect (testlist) Initial Comment: In section 5.2.4 of the Python Reference Manual for Pythons 2.4 and 2.3 the definition testlist ::= test ( "," test )* [ "," ] should be testlist ::= test [ ( "," test )+ [ "," ] ] to conform with the definition of testlist_safe in the Grammar definition file. In other words, a trailing comma is not permitted if there is only one test in testlist. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2004-12-15 09:50 Message: Logged In: YES user_id=147070 but >>> testlist = 1, >>> testlist (1,) so testlist = 1 does not produce a list testlist ::= one "," ( another "," )* [and [","]] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 From noreply at sourceforge.net Wed Dec 15 12:37:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 12:38:05 2004 Subject: [ python-Bugs-1071248 ] Documented grammar for List displays incorrect (testlist) Message-ID: Bugs item #1071248, was opened at 2004-11-22 15:26 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenard Lindstrom (kermode) >Assigned to: Jeremy Hylton (jhylton) Summary: Documented grammar for List displays incorrect (testlist) Initial Comment: In section 5.2.4 of the Python Reference Manual for Pythons 2.4 and 2.3 the definition testlist ::= test ( "," test )* [ "," ] should be testlist ::= test [ ( "," test )+ [ "," ] ] to conform with the definition of testlist_safe in the Grammar definition file. In other words, a trailing comma is not permitted if there is only one test in testlist. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2004-12-15 03:50 Message: Logged In: YES user_id=147070 but >>> testlist = 1, >>> testlist (1,) so testlist = 1 does not produce a list testlist ::= one "," ( another "," )* [and [","]] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 From noreply at sourceforge.net Wed Dec 15 12:38:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 12:38:43 2004 Subject: [ python-Feature Requests-1085304 ] Make array.array pickle-able Message-ID: Feature Requests item #1085304, was opened at 2004-12-14 13:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085304&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Fleury (nidoizo) Assigned to: Raymond Hettinger (rhettinger) Summary: Make array.array pickle-able Initial Comment: Make array.array pickle-able. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085304&group_id=5470 From noreply at sourceforge.net Wed Dec 15 13:15:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 13:15:52 2004 Subject: [ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools Message-ID: Bugs item #1085744, was opened at 2004-12-15 22:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ****** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data))))" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 From noreply at sourceforge.net Wed Dec 15 13:17:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 13:18:11 2004 Subject: [ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools Message-ID: Bugs item #1085744, was opened at 2004-12-15 22:15 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Raymond Hettinger (rhettinger) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ****** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data))))" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2004-12-15 22:17 Message: Logged In: YES user_id=1038590 Kicking in your direction Raymond, since this can badly affect the performance of itertools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 From noreply at sourceforge.net Wed Dec 15 16:04:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 16:04:24 2004 Subject: [ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools Message-ID: Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ****** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data))))" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing, Guido considers it an abuse (since * unwinds its components on to ceval's stack). Likewise, there is nothing unique to itertools here. All of the timings can be shown to have similar results if generators are used instead of itertools. This issue is really how consumers handle unsized iterable inputs. You cover three different consumers, ''.join(it), list(it), and tuple(it) which all take different approaches to unsized iterable inputs. So, it is no surprise that the three have different performance characteristics. str.join() is its own little bundle of joy whose behavior is dictated by its need to make multiple passes over the input. Improving its handling of unsized iterable inputs is a thorny subject. You're welcome to post a patch. The best way to analyze what is going on is to disregard the timings and instead draw little diagrams of what is memory at any given time. Also, draw a data migration path -- you want the algorithm to move the elements as few times as possible. Be sure to handle cases like dict.iteritems() which know their length but are not a list or tuple. Also, handle cases where the inputs are created on the fly (not already held in memory as in your example): ''.join(str(i%10) for i in xrange(n)). FYI, there was an interesting bug report on this subject a year ago. IIRC, the OP saw that memory consumption was greater with an iterable input than if the iterable had been first wrapped in list(). I don't see anything out of whack for the creation of lists and tuples from unsized iterables. There are simply two different overallocation algorithms; consequently, there will always be situations where one outperforms the other. For your giant sized examples, the tuple growth strategy of fixed sized overallocations does poorly against the list strategy of increasingly large overallocations. In contrast, tuples can do better for certain small sizes. If you think there are critical use cases for tuple(it) where for a large, unsized it, then you can proposed a variable length strategy like that used for lists. If such use cases exist, I suspect they don't fit real well with Guido's intended philosophy on tuple use. Am closing this as a bug report. It is more a mixture of questions (explain this timing) and feature requests. Feel free to send me emails to explore this further. I've been through this all before and it is a substantial analysis project. If you go down this path, you may well find some room for improvements (str.join) in particular. Also, be sure to separate the issues. It is not all helpful to simultaneously cover itertools, *args, lists vs tuples, unsized iterators, str.join, list.extend, and a proposals to make terators report their length. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1038590 Kicking in your direction Raymond, since this can badly affect the performance of itertools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 From noreply at sourceforge.net Wed Dec 15 16:16:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 16:16:26 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 09:25 Message generated for change (Comment added) made by tds33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 15:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 06:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 09:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Wed Dec 15 16:33:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 16:33:48 2004 Subject: [ python-Bugs-1085861 ] subprocess.Popen feature request Message-ID: Bugs item #1085861, was opened at 2004-12-15 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen feature request Initial Comment: I asked on comp.lang.python for a "kill" method in the Popen class. The answer was "the kill method is missing since it is not portable to Windows". However I got this message from Fredrik Lund """ I suggest filing a "bug" report about this. the Unix version is trivial, as you noticed, and it shouldn't take many minutes to add a TerminateProcess helper to _subprocess. """ So, I am following his suggestion ;-) Michele Simionato ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 From noreply at sourceforge.net Wed Dec 15 18:14:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 18:14:14 2004 Subject: [ python-Bugs-1085744 ] Bad interaction between PySequence_Fast and itertools Message-ID: Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: Bad interaction between PySequence_Fast and itertools Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ****** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data))))" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 12:14 Message: Logged In: YES user_id=80475 P.S. In your example, you can get an immediate improvement in performance by having Py_SequenceFast use PySequence_List instead of PySequence_Tuple. If you want to work on some Py2.5 optimizations along these lines, look at replacing the somewhat arbitrary over-allocation strategy in PySequence_Tuple. If you're super-motivated, see if you can improve on the algorithm for str.join. Since these are just strategy changes, they will improve some cases at the expense of others. The goal is to find the one that does the best, most of the time; not horribly in worst situations; and makes the fewest demands on memory. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing, Guido considers it an abuse (since * unwinds its components on to ceval's stack). Likewise, there is nothing unique to itertools here. All of the timings can be shown to have similar results if generators are used instead of itertools. This issue is really how consumers handle unsized iterable inputs. You cover three different consumers, ''.join(it), list(it), and tuple(it) which all take different approaches to unsized iterable inputs. So, it is no surprise that the three have different performance characteristics. str.join() is its own little bundle of joy whose behavior is dictated by its need to make multiple passes over the input. Improving its handling of unsized iterable inputs is a thorny subject. You're welcome to post a patch. The best way to analyze what is going on is to disregard the timings and instead draw little diagrams of what is memory at any given time. Also, draw a data migration path -- you want the algorithm to move the elements as few times as possible. Be sure to handle cases like dict.iteritems() which know their length but are not a list or tuple. Also, handle cases where the inputs are created on the fly (not already held in memory as in your example): ''.join(str(i%10) for i in xrange(n)). FYI, there was an interesting bug report on this subject a year ago. IIRC, the OP saw that memory consumption was greater with an iterable input than if the iterable had been first wrapped in list(). I don't see anything out of whack for the creation of lists and tuples from unsized iterables. There are simply two different overallocation algorithms; consequently, there will always be situations where one outperforms the other. For your giant sized examples, the tuple growth strategy of fixed sized overallocations does poorly against the list strategy of increasingly large overallocations. In contrast, tuples can do better for certain small sizes. If you think there are critical use cases for tuple(it) where for a large, unsized it, then you can proposed a variable length strategy like that used for lists. If such use cases exist, I suspect they don't fit real well with Guido's intended philosophy on tuple use. Am closing this as a bug report. It is more a mixture of questions (explain this timing) and feature requests. Feel free to send me emails to explore this further. I've been through this all before and it is a substantial analysis project. If you go down this path, you may well find some room for improvements (str.join) in particular. Also, be sure to separate the issues. It is not all helpful to simultaneously cover itertools, *args, lists vs tuples, unsized iterators, str.join, list.extend, and a proposals to make terators report their length. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1038590 Kicking in your direction Raymond, since this can badly affect the performance of itertools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 From noreply at sourceforge.net Wed Dec 15 19:02:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 19:02:50 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 04:25 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 13:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 10:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 01:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 04:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Wed Dec 15 21:58:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 21:58:33 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Comment added) made by axel_kaiser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-15 21:58 Message: Logged In: YES user_id=1176563 Sorry, the attachment was not appended. By the way, the problem occurs without any external modules/libraries. It just juses python-source. The problem might be connected with the use of module array. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 19:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 16:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 10:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Wed Dec 15 22:05:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 22:05:42 2004 Subject: [ python-Bugs-944119 ] Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty Message-ID: Bugs item #944119, was opened at 2004-04-28 18:05 Message generated for change (Settings changed) made by levis501 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470 Category: None Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve Levis (levis501) Assigned to: Nobody/Anonymous (nobody) Summary: Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty Initial Comment: The attached python file reproduces a bug whereby Python does not receive alarm signals from FreeBSD 4.9. This also appears to be the case in FreeBSD 4.8, and may be related to the addition of HyperThreading in FreeBSD 4.8. If Python (either 2.2.3 or 2.3.3) is configured with -?without-threads before compiling, the bug does not exist. ---------------------------------------------------------------------- >Comment By: Steve Levis (levis501) Date: 2004-12-15 13:05 Message: Logged In: YES user_id=309698 The system in question has been upgraded to FreeBSD 5.2 and this problem no longer exists. Thanks aimacintyre and lukem. ---------------------------------------------------------------------- Comment By: Luke Mewburn (lukem) Date: 2004-08-21 18:08 Message: Logged In: YES user_id=135998 Please try the patch I provided in patch 975056; it fixes up various signal lossage on NetBSD & FreeBSD caused by python's intermixed use of signal(3) and sigaction(3). python wants non-SA_RESTART-able signals, yet signal(3) on *BSD traditionally sets SA_RESTART, and the mechanism that python uses to unset SA_RESTART when using sigaction(3) is flawed. It's quite possible that the os.read() non-interruptability you're noticing on FreeBSD is being caused by this issue. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-23 00:58 Message: Logged In: YES user_id=250749 There are a few things I haven't been able to figure out with this problem, but I think this is what's going on: - on FreeBSD the read(2) call is not interruptable, as ptys appear not to be considered "slow devices" by the kernel (whether this behavior is *BSD specific I don't really know; ordinary files and pipes aresimilarly affected so forkpty() is just the messenger here); - Python's signal handling is documented to behave such that signal handlers only get invoked between Python VM opcodes. As the os.read() call is a single VM instruction, the nett effect is that the signal handler will not execute until the os.read() call/instruction completes... which it never does. This also affects other signals, such as SIGINT :-( The signal handler being invoked between opcodes explains why the C version works and the Python version doesn't. Using select.select() (or select.poll()) is one way of avoiding this trap, as both select(2) and poll(2) are interruptable (in addition to supporting timeouts directly). I expect this approach would also be considered to be generally portable. I haven't dug into why a single-threaded build avoids the Python VM opcode scheduling - I can only speculate that because the VM doesn't have any thread locking, it can actually execute the signal handler while the os.read() call is still pending. I don't expect there to be a practical solution to this, and so I'm suggesting that the bug be closed as "Won't fix" (read "Can't fix"). ---------------------------------------------------------------------- Comment By: Steve Levis (levis501) Date: 2004-05-18 12:55 Message: Logged In: YES user_id=309698 I've uploaded failure_demo.c, which can be compiled with gcc -o failure_demo failure_demo.c -lutil. Written in C, the signal is properly delivered, and the test does not fail on either FreeBSD 4.7 or 4.9. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-18 02:05 Message: Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-18 02:03 Message: Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. ---------------------------------------------------------------------- Comment By: Steve Levis (levis501) Date: 2004-05-05 10:08 Message: Logged In: YES user_id=309698 Ooops, again! I ran on the standard kernel but had python compiled --without-threads, so of course it worked. So, to make a long story short, the bug exists -- ignore my last post. ---------------------------------------------------------------------- Comment By: Steve Levis (levis501) Date: 2004-05-05 09:59 Message: Logged In: YES user_id=309698 I was apparently not running on a standard FreeBSD kernel. It's working now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470 From noreply at sourceforge.net Wed Dec 15 22:08:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 22:08:31 2004 Subject: [ python-Bugs-518846 ] exception cannot be new-style class Message-ID: Bugs item #518846, was opened at 2002-02-17 12:09 Message generated for change (Comment added) made by robey1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [magnus@gills magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 13:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-24 18:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 13:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 10:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 09:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 16:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception, a __metaclass__ = type should not have any effect on the exceptions you declare. So I'm not sure what your problem is? Here's another idea for a patch: a new-style class is allowed as long as it also inherits from Exception. (This is possible!) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 15:49 Message: Logged In: YES user_id=31392 I don't realize there was agreement on this. (I didn't follow the discussion closely.) I don't understand why exceptions need to pass an isinstance() test on Exception. It didn't used to be this way, and it makes it hard to convert a module using __metaclass__ = type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-05 15:44 Message: Logged In: YES user_id=21627 I thought the agreement was that this is not a bug: You cannot really expect exceptions to work unless you inherit from Exception. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 15:38 Message: Logged In: YES user_id=31392 Martin, I think the attached patch is sufficient. It checks object type's for Py_TPFLAGS_HEAPTYPE. I believe this is the current way to spell "new-style class" although the spelling is odd if that's the meaning <0.2 wink>. If this patch makes sense to you, I'll flesh it out with some test cases and check it in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-17 15:44 Message: Logged In: YES user_id=21627 Interesting. I think we need to deprecate, then remove string exception before allowing arbitrary objects as exceptions. Or we could allow strings to be caught either by __builtin__.str, or by an identical string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 From noreply at sourceforge.net Wed Dec 15 22:27:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 22:27:14 2004 Subject: [ python-Bugs-1085744 ] PySequence_Tuple not as fast as PySequence_List Message-ID: Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core >Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) >Summary: PySequence_Tuple not as fast as PySequence_List Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ****** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data))))" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 16:27 Message: Logged In: YES user_id=80475 Attaching a small patch for PySequence_Tuple. Try it out and let me know if you find it to be an improvement. It also adds a bit of error checking that should have been there anyway. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 12:14 Message: Logged In: YES user_id=80475 P.S. In your example, you can get an immediate improvement in performance by having Py_SequenceFast use PySequence_List instead of PySequence_Tuple. If you want to work on some Py2.5 optimizations along these lines, look at replacing the somewhat arbitrary over-allocation strategy in PySequence_Tuple. If you're super-motivated, see if you can improve on the algorithm for str.join. Since these are just strategy changes, they will improve some cases at the expense of others. The goal is to find the one that does the best, most of the time; not horribly in worst situations; and makes the fewest demands on memory. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing, Guido considers it an abuse (since * unwinds its components on to ceval's stack). Likewise, there is nothing unique to itertools here. All of the timings can be shown to have similar results if generators are used instead of itertools. This issue is really how consumers handle unsized iterable inputs. You cover three different consumers, ''.join(it), list(it), and tuple(it) which all take different approaches to unsized iterable inputs. So, it is no surprise that the three have different performance characteristics. str.join() is its own little bundle of joy whose behavior is dictated by its need to make multiple passes over the input. Improving its handling of unsized iterable inputs is a thorny subject. You're welcome to post a patch. The best way to analyze what is going on is to disregard the timings and instead draw little diagrams of what is memory at any given time. Also, draw a data migration path -- you want the algorithm to move the elements as few times as possible. Be sure to handle cases like dict.iteritems() which know their length but are not a list or tuple. Also, handle cases where the inputs are created on the fly (not already held in memory as in your example): ''.join(str(i%10) for i in xrange(n)). FYI, there was an interesting bug report on this subject a year ago. IIRC, the OP saw that memory consumption was greater with an iterable input than if the iterable had been first wrapped in list(). I don't see anything out of whack for the creation of lists and tuples from unsized iterables. There are simply two different overallocation algorithms; consequently, there will always be situations where one outperforms the other. For your giant sized examples, the tuple growth strategy of fixed sized overallocations does poorly against the list strategy of increasingly large overallocations. In contrast, tuples can do better for certain small sizes. If you think there are critical use cases for tuple(it) where for a large, unsized it, then you can proposed a variable length strategy like that used for lists. If such use cases exist, I suspect they don't fit real well with Guido's intended philosophy on tuple use. Am closing this as a bug report. It is more a mixture of questions (explain this timing) and feature requests. Feel free to send me emails to explore this further. I've been through this all before and it is a substantial analysis project. If you go down this path, you may well find some room for improvements (str.join) in particular. Also, be sure to separate the issues. It is not all helpful to simultaneously cover itertools, *args, lists vs tuples, unsized iterators, str.join, list.extend, and a proposals to make terators report their length. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1038590 Kicking in your direction Raymond, since this can badly affect the performance of itertools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 From noreply at sourceforge.net Wed Dec 15 22:59:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 22:59:31 2004 Subject: [ python-Bugs-518846 ] exception cannot be new-style class Message-ID: Bugs item #518846, was opened at 2002-02-17 21:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [magnus@gills magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 22:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 22:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 03:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 22:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 19:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 18:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-06 02:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception, a __metaclass__ = type should not have any effect on the exceptions you declare. So I'm not sure what your problem is? Here's another idea for a patch: a new-style class is allowed as long as it also inherits from Exception. (This is possible!) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-06 01:49 Message: Logged In: YES user_id=31392 I don't realize there was agreement on this. (I didn't follow the discussion closely.) I don't understand why exceptions need to pass an isinstance() test on Exception. It didn't used to be this way, and it makes it hard to convert a module using __metaclass__ = type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-06 01:44 Message: Logged In: YES user_id=21627 I thought the agreement was that this is not a bug: You cannot really expect exceptions to work unless you inherit from Exception. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-06 01:38 Message: Logged In: YES user_id=31392 Martin, I think the attached patch is sufficient. It checks object type's for Py_TPFLAGS_HEAPTYPE. I believe this is the current way to spell "new-style class" although the spelling is odd if that's the meaning <0.2 wink>. If this patch makes sense to you, I'll flesh it out with some test cases and check it in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-18 00:44 Message: Logged In: YES user_id=21627 Interesting. I think we need to deprecate, then remove string exception before allowing arbitrary objects as exceptions. Or we could allow strings to be caught either by __builtin__.str, or by an identical string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 From noreply at sourceforge.net Wed Dec 15 23:10:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 23:10:04 2004 Subject: [ python-Bugs-1086096 ] two strings holding the same value have different id Message-ID: Bugs item #1086096, was opened at 2004-12-15 17:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: two strings holding the same value have different id Initial Comment: I'v run into a problem with a program that expects a string to be either 'resource' or 'test': type = ... if type is "resource": do_something() elif type is "test": do_something_else() The above comparison using 'is' works fine with python 2.3, but fails with python 2.4. Unfortunately I wasn't able to isolate the problem. To reproduce: Install qmtest from http://www.qmtest.com on windows xp with python 2.4 (I don't know yet whether other platforms are affected, too). Then follow the instructions from http://www.codesourcery.com/public/qmtest/qm-2.2/manual.html up to section 2.2 'Starting the Graphical Interface'. In the browser, click on the 'exec1' test, and you'll get an 'UnboundLocalError' because the application logic didn't expect some comparison to fail. The failed comparison in question is 't is "test"', which returns 'False' even though t == "test". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 From noreply at sourceforge.net Wed Dec 15 23:27:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 23:29:01 2004 Subject: [ python-Bugs-1086096 ] two strings holding the same value have different id Message-ID: Bugs item #1086096, was opened at 2004-12-15 17:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: two strings holding the same value have different id Initial Comment: I'v run into a problem with a program that expects a string to be either 'resource' or 'test': type = ... if type is "resource": do_something() elif type is "test": do_something_else() The above comparison using 'is' works fine with python 2.3, but fails with python 2.4. Unfortunately I wasn't able to isolate the problem. To reproduce: Install qmtest from http://www.qmtest.com on windows xp with python 2.4 (I don't know yet whether other platforms are affected, too). Then follow the instructions from http://www.codesourcery.com/public/qmtest/qm-2.2/manual.html up to section 2.2 'Starting the Graphical Interface'. In the browser, click on the 'exec1' test, and you'll get an 'UnboundLocalError' because the application logic didn't expect some comparison to fail. The failed comparison in question is 't is "test"', which returns 'False' even though t == "test". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-15 17:27 Message: Logged In: YES user_id=31435 Sorry, the only bug I see here is in the code you posted using "is" to try to determine whether two strings are equal. "is" tests for object identity, not for equality, and whether two immutable objects are really the same object isn't in general defined by Python. You should use "==" to check two strings for equality. The only time it's reliable to use "is" for that purpose is when you've explicitly interned all strings being compared (via using the intern() builtin function). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 From noreply at sourceforge.net Wed Dec 15 23:35:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 23:35:07 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Nobody/Anonymous (nobody) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Wed Dec 15 23:39:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 23:39:09 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:39 Message: Logged In: YES user_id=21627 Can you create a small test case that demonstrates the problem? ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-15 21:58 Message: Logged In: YES user_id=1176563 Sorry, the attachment was not appended. By the way, the problem occurs without any external modules/libraries. It just juses python-source. The problem might be connected with the use of module array. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 19:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 16:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 10:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Wed Dec 15 23:41:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 15 23:41:34 2004 Subject: [ python-Bugs-1080634 ] PythonWin Tray Icon in system Tray on Windows platform Message-ID: Bugs item #1080634, was opened at 2004-12-07 14:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 Category: Windows >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin Tray Icon in system Tray on Windows platform Initial Comment: The python icon remains in the system Tray even if you close the application. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:41 Message: Logged In: YES user_id=21627 Pythonwin is not part of the Python project. Please report this to http://sourceforge.net/projects/pywin32 ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-08 16:31 Message: Logged In: YES user_id=1173293 PythonWin tray icons remains in the system tray once you close the application for Python-2.4.0-243 build on Windows platform. If you hover the mouse then only it goes off. If you open and close PythonWin application 10 times, you will see 10 tray icons. Any probable date, when this could get resolved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080634&group_id=5470 From noreply at sourceforge.net Thu Dec 16 00:14:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 00:14:40 2004 Subject: [ python-Bugs-1086127 ] Typo in module os documentation Message-ID: Bugs item #1086127, was opened at 2004-12-15 23:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in module os documentation Initial Comment: In the docs for module os ( http://docs.python.org/lib/os-path.html ): pathsep The character conventionally used by the operating system to separate search patch components (as in PATH), such as ":" for POSIX or ";" for Windows. Also available via os.path. Replace "patch" with "path". - Connelly Barnes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 From noreply at sourceforge.net Thu Dec 16 00:14:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 00:19:34 2004 Subject: [ python-Bugs-1086096 ] two strings holding the same value have different id Message-ID: Bugs item #1086096, was opened at 2004-12-15 17:10 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: two strings holding the same value have different id Initial Comment: I'v run into a problem with a program that expects a string to be either 'resource' or 'test': type = ... if type is "resource": do_something() elif type is "test": do_something_else() The above comparison using 'is' works fine with python 2.3, but fails with python 2.4. Unfortunately I wasn't able to isolate the problem. To reproduce: Install qmtest from http://www.qmtest.com on windows xp with python 2.4 (I don't know yet whether other platforms are affected, too). Then follow the instructions from http://www.codesourcery.com/public/qmtest/qm-2.2/manual.html up to section 2.2 'Starting the Graphical Interface'. In the browser, click on the 'exec1' test, and you'll get an 'UnboundLocalError' because the application logic didn't expect some comparison to fail. The failed comparison in question is 't is "test"', which returns 'False' even though t == "test". ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-12-15 18:14 Message: Logged In: YES user_id=7733 I fully agree with Tim. If the example code worked before, it was accidental. "is" tests identity. ``"resource" is "resource"`` may create two independent string objects. Use "==" instead. Closed the bug report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-15 17:27 Message: Logged In: YES user_id=31435 Sorry, the only bug I see here is in the code you posted using "is" to try to determine whether two strings are equal. "is" tests for object identity, not for equality, and whether two immutable objects are really the same object isn't in general defined by Python. You should use "==" to check two strings for equality. The only time it's reliable to use "is" for that purpose is when you've explicitly interned all strings being compared (via using the intern() builtin function). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086096&group_id=5470 From noreply at sourceforge.net Thu Dec 16 00:39:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 00:39:17 2004 Subject: [ python-Bugs-518846 ] exception cannot be new-style class Message-ID: Bugs item #518846, was opened at 2002-02-17 12:09 Message generated for change (Comment added) made by robey1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [magnus@gills magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 15:39 Message: Logged In: YES user_id=1179122 Let me try to rephrase the problem so that it's obvious that this is a bug, and not a feature: 'type(e)' on an exception will not work in 2.3, and cannot be made to work from within python code. There's no way to throw an exception (ie an object with Exception in its ancestor list) that 'type(e)' will work on. :( ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 13:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 13:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-24 18:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 13:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 10:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 09:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 16:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception, a __metaclass__ = type should not have any effect on the exceptions you declare. So I'm not sure what your problem is? Here's another idea for a patch: a new-style class is allowed as long as it also inherits from Exception. (This is possible!) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 15:49 Message: Logged In: YES user_id=31392 I don't realize there was agreement on this. (I didn't follow the discussion closely.) I don't understand why exceptions need to pass an isinstance() test on Exception. It didn't used to be this way, and it makes it hard to convert a module using __metaclass__ = type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-05 15:44 Message: Logged In: YES user_id=21627 I thought the agreement was that this is not a bug: You cannot really expect exceptions to work unless you inherit from Exception. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 15:38 Message: Logged In: YES user_id=31392 Martin, I think the attached patch is sufficient. It checks object type's for Py_TPFLAGS_HEAPTYPE. I believe this is the current way to spell "new-style class" although the spelling is odd if that's the meaning <0.2 wink>. If this patch makes sense to you, I'll flesh it out with some test cases and check it in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-17 15:44 Message: Logged In: YES user_id=21627 Interesting. I think we need to deprecate, then remove string exception before allowing arbitrary objects as exceptions. Or we could allow strings to be caught either by __builtin__.str, or by an identical string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 From noreply at sourceforge.net Thu Dec 16 00:47:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 00:47:39 2004 Subject: [ python-Bugs-1086127 ] Typo in module os documentation Message-ID: Bugs item #1086127, was opened at 2004-12-16 00:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in module os documentation Initial Comment: In the docs for module os ( http://docs.python.org/lib/os-path.html ): pathsep The character conventionally used by the operating system to separate search patch components (as in PATH), such as ":" for POSIX or ";" for Windows. Also available via os.path. Replace "patch" with "path". - Connelly Barnes ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:47 Message: Logged In: YES user_id=89016 Fixed in: Doc/lib/libos.tex 1.147 Doc/lib/libos.tex 1.146.2.1 Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086127&group_id=5470 From noreply at sourceforge.net Thu Dec 16 00:55:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 00:55:55 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Sebastian Hartte (dark-storm) >Assigned to: M.-A. Lemburg (lemburg) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Thu Dec 16 10:52:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 10:52:28 2004 Subject: [ python-Bugs-1077040 ] Error building _bsddb extension Message-ID: Bugs item #1077040, was opened at 2004-12-01 12:19 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Oleg Broytmann (phd) Assigned to: Gregory P. Smith (greg) Summary: Error building _bsddb extension Initial Comment: Trying to build Python 2.4 on Debian GNU/Linux 3.0 using gcc 3.3.4. BerkeleyDB version is 3.2, header is /usr/include/db.h, library in /usr/lib. Error: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fPIC -I. -I/usr/local/src/Python/Python-2.4/./Include -I/usr/local/include -I/usr/local/src/Python/Python-2.4/Include -I/usr/local/src/Python/Python-2.4 -c /usr/local/src/Python/Python-2.4/Modules/_bsddb.c -o build/temp.linux-i686-2.4/_bsddb.o running build_scripts /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DB_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1464: error: structure has no member named `pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1482: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:1483: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c: In function `DBC_pget': /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2928: error: structure has no member named `c_pget' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2943: error: structure has no member named `primaryDBType' /usr/local/src/Python/Python-2.4/Modules/_bsddb.c:2944: error: structure has no member named `primaryDBType' ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2004-12-16 01:52 Message: Logged In: YES user_id=413 fixed in python cvs both in HEAD and 2.4 (release24-maint branch). patch attached to this bug if you just want to apply it to your python 2.4 tarball. fwiw, its better to use a more recent version of berkeleydb if possible. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-12-13 04:13 Message: Logged In: YES user_id=413 Yes this is easy to reproduce. At the moment the preferred workaround is to use a more recent version of BerkeleyDB <= 4.2 (4.3 support has not yet been committed to the 2.4 maintenance branch). I'll fix this so that 3.2 works again shortly. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2004-12-12 02:47 Message: Logged In: YES user_id=4799 #define DB_VERSION_MAJOR 3 #define DB_VERSION_MINOR 2 #define DB_VERSION_PATCH 9 #define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 3.2.9: (April 7, 2002)" ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 01:23 Message: Logged In: YES user_id=250749 What are the DB_VERSION_MAJOR and DB_VERSION_MINOR macros defined to in your /usr/include/db.h? The primaryDBType symbol is only referenced in code compiled for DB versions 3.3 and higher, and the pget symbol is referenced in code compiled for DB 3.2 and higher. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077040&group_id=5470 From noreply at sourceforge.net Thu Dec 16 11:04:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 11:04:08 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 16:18 Message generated for change (Comment added) made by anamh0001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Nobody/Anonymous (nobody) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- >Comment By: anamh0001 (anamh0001) Date: 2004-12-16 10:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 22:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Thu Dec 16 11:32:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 11:33:30 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) >Assigned to: Nobody/Anonymous (nobody) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 05:32 Message: Logged In: YES user_id=80475 After more thought, I'm concerned that switching to full decimal notation will break the guarantee eval(repr(x))==x. Also, Skip's thoughts seem reasonable. Rather than switching to a non-compact format, it may be best to way for the spec to catchup with real implementations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 17:19 Message: Logged In: YES user_id=80475 Various slightly unsatisfactory answers: * It started out that way because that's what C did. * It stayed that way because no one has requested it * It may be that outside of XMLRPC there are very few valid use cases. * Future needs can be met by the decimal module. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2004-12-13 14:04 Message: Logged In: YES user_id=133955 I'm gonna ask a stupid question (I'm quite a beginner in Python). Why isn't there a %f-life formatting code for doing just what you wrote - printing the float in full precision in non-exponent format ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 13:12 Message: Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 10:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 08:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Thu Dec 16 11:36:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 11:36:20 2004 Subject: [ python-Bugs-1085861 ] subprocess.Popen feature request Message-ID: Bugs item #1085861, was opened at 2004-12-15 10:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen feature request Initial Comment: I asked on comp.lang.python for a "kill" method in the Popen class. The answer was "the kill method is missing since it is not portable to Windows". However I got this message from Fredrik Lund """ I suggest filing a "bug" report about this. the Unix version is trivial, as you noticed, and it shouldn't take many minutes to add a TerminateProcess helper to _subprocess. """ So, I am following his suggestion ;-) Michele Simionato ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 From noreply at sourceforge.net Thu Dec 16 11:36:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 11:36:42 2004 Subject: [ python-Bugs-1085861 ] subprocess.Popen feature request Message-ID: Bugs item #1085861, was opened at 2004-12-15 10:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 Category: Python Library >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen feature request Initial Comment: I asked on comp.lang.python for a "kill" method in the Popen class. The answer was "the kill method is missing since it is not portable to Windows". However I got this message from Fredrik Lund """ I suggest filing a "bug" report about this. the Unix version is trivial, as you noticed, and it shouldn't take many minutes to add a TerminateProcess helper to _subprocess. """ So, I am following his suggestion ;-) Michele Simionato ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085861&group_id=5470 From noreply at sourceforge.net Thu Dec 16 11:39:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 11:39:27 2004 Subject: [ python-Bugs-1085744 ] PySequence_Tuple not as fast as PySequence_List Message-ID: Bugs item #1085744, was opened at 2004-12-15 07:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Raymond Hettinger (rhettinger) Summary: PySequence_Tuple not as fast as PySequence_List Initial Comment: A little "my code is faster than your code" game on python-list showed up a pathological interaction between itertools.chain and str.join: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(chain(*data))" 10 loops, best of 3: 1.2 sec per loop ****** OUCH!! Some extra experiments show that creating a list from the result of chain is fast, but creating a tuple is horrendously slow: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(list(chain(*data)))" 10 loops, best of 3: 107 msec per loop C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(chain(*data)))" 10 loops, best of 3: 1.2 sec per loop Creating the tuple by means of a list is actually faster than creating the tuple directly: C:\>python -m timeit -s "data = [map(str, range(x)) for x in range(1000)]; from itertools import chain" "''.join(tuple(list(chain(*data))))" 10 loops, best of 3: 146 msec per loop A check with imap suggests the problem may be a more general interaction between PySequence_Fast and iterators which don't have __len__ methods: C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(list(imap(val, data)))" 10 loops, best of 3: 310 msec per loop C:\>python -m timeit -s "data = [y for x in range(1000) for y in map(str, range(x))]; from itertools import imap; val = lambda arg: arg" "''.join(imap(val, data))" 10 loops, best of 3: 1.4 sec per loop Looking at the code supports that, too - PySequence_Fast uses PySequence_Tuple, which is great when PyObject_Size gives a nice answer, but can lead to a lot of tuple resizing when it isn't (one resize per 10 items beyond 10 up to 500, then one resize per 100 items beyond 500). 2.4's optimised list extension means that this *really* hurts performance wise. The other aspect is whether or not some of the utilities in itertools could benefit from a __len__ method that returned a sensible answer if their inputs defined __len__ methods, and returned -1 otherwise (this would certainly work well with PySequence_Tuple, but I realise it's a slightly odd behaviour for a __len__ method). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 05:39 Message: Logged In: YES user_id=80475 Loaded the patch. See Objects/abstract.c 2.133 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 16:27 Message: Logged In: YES user_id=80475 Attaching a small patch for PySequence_Tuple. Try it out and let me know if you find it to be an improvement. It also adds a bit of error checking that should have been there anyway. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 12:14 Message: Logged In: YES user_id=80475 P.S. In your example, you can get an immediate improvement in performance by having Py_SequenceFast use PySequence_List instead of PySequence_Tuple. If you want to work on some Py2.5 optimizations along these lines, look at replacing the somewhat arbitrary over-allocation strategy in PySequence_Tuple. If you're super-motivated, see if you can improve on the algorithm for str.join. Since these are just strategy changes, they will improve some cases at the expense of others. The goal is to find the one that does the best, most of the time; not horribly in worst situations; and makes the fewest demands on memory. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 10:04 Message: Logged In: YES user_id=80475 Remain calm ;-) Also, please isolate the issues instead of clumping everything together. And this is likely best handled by email rather than SF (you're asking me to explain all of your timings rather than pointing to a buggy piece of code). The idea (feature request) to make iterators length transparent has already been explored and reached a dead end. I've implemented it already it the few situations where it can work (for example itertools.repeat(obj, n) and dict.iteritems() report their length). Most other situations run into logical inconsistencies due to mutable iterables being indistinguishable from iterators over those iterables. See Lib/test/test_iterlen.py for the gory details. Writing f(*it) is also its own issue -- for uses other than argument passing, Guido considers it an abuse (since * unwinds its components on to ceval's stack). Likewise, there is nothing unique to itertools here. All of the timings can be shown to have similar results if generators are used instead of itertools. This issue is really how consumers handle unsized iterable inputs. You cover three different consumers, ''.join(it), list(it), and tuple(it) which all take different approaches to unsized iterable inputs. So, it is no surprise that the three have different performance characteristics. str.join() is its own little bundle of joy whose behavior is dictated by its need to make multiple passes over the input. Improving its handling of unsized iterable inputs is a thorny subject. You're welcome to post a patch. The best way to analyze what is going on is to disregard the timings and instead draw little diagrams of what is memory at any given time. Also, draw a data migration path -- you want the algorithm to move the elements as few times as possible. Be sure to handle cases like dict.iteritems() which know their length but are not a list or tuple. Also, handle cases where the inputs are created on the fly (not already held in memory as in your example): ''.join(str(i%10) for i in xrange(n)). FYI, there was an interesting bug report on this subject a year ago. IIRC, the OP saw that memory consumption was greater with an iterable input than if the iterable had been first wrapped in list(). I don't see anything out of whack for the creation of lists and tuples from unsized iterables. There are simply two different overallocation algorithms; consequently, there will always be situations where one outperforms the other. For your giant sized examples, the tuple growth strategy of fixed sized overallocations does poorly against the list strategy of increasingly large overallocations. In contrast, tuples can do better for certain small sizes. If you think there are critical use cases for tuple(it) where for a large, unsized it, then you can proposed a variable length strategy like that used for lists. If such use cases exist, I suspect they don't fit real well with Guido's intended philosophy on tuple use. Am closing this as a bug report. It is more a mixture of questions (explain this timing) and feature requests. Feel free to send me emails to explore this further. I've been through this all before and it is a substantial analysis project. If you go down this path, you may well find some room for improvements (str.join) in particular. Also, be sure to separate the issues. It is not all helpful to simultaneously cover itertools, *args, lists vs tuples, unsized iterators, str.join, list.extend, and a proposals to make terators report their length. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1038590 Kicking in your direction Raymond, since this can badly affect the performance of itertools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085744&group_id=5470 From noreply at sourceforge.net Thu Dec 16 11:40:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 11:40:54 2004 Subject: [ python-Bugs-1080660 ] thread.error: release unlocked lock on Queue put Message-ID: Bugs item #1080660, was opened at 2004-12-07 09:48 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 Category: Threads Group: Python 2.3 >Status: Closed >Resolution: Later Priority: 5 Submitted By: John Speno (corvus) Assigned to: Nobody/Anonymous (nobody) Summary: thread.error: release unlocked lock on Queue put Initial Comment: System is Python 2.3.3 on Solaris 9. I'm using the classic Python thread model. Main thread puts stuff into a Queue.Queue() and worker threads get stuff out of it and do their thing. On occaision, I get an exception in the main thread when it tries to put something into the Queue. File "/usr/local/bin/poller.py", line 47, in fragnap_it work_queue.put((foo, bar, baz)) File "/usr/local/lib/python2.3/Queue.py", line 106, in put self.fsema.release() thread.error: release unlocked lock This error still happens intermittently, and I haven't been able to reduce it to a simple case. I can alter my applications to do something useful for debugging this problem when it happens, if you can figure out what "something useful" would be. Just let me know. The queue is unbounded, and I'm using blocking get/put. The main thread creates 20 worker threads, and 1 recorder thread. Then it puts upto 1500 items in the Queue.Queue named work_queue. The 20 worker threads take stuff out work_queue, process some using pure python code, or others by using subprocess.py. Results from the workers are put into another Queue.Queue named results_queue. The Recorder thread gets from the results_queue and writes stuff to a MySQL db. I've never seen the error happen when putting into the results_queue, only from the main thread putting into the work_queue. Thread defines in my python config.h are: #define HAVE_PTHREAD_H 1 #define HAVE_PTHREAD_SIGMASK 1 #define HAVE_THREAD_H 1 #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 #define SIZEOF_PTHREAD_T 4 #define WITH_THREAD 1 And all the thread related python tests (test_thread, test_threading, and test_queue) pass. ---------------------------------------------------------------------- Comment By: John Speno (corvus) Date: 2004-12-10 12:57 Message: Logged In: YES user_id=2138 Given that I can't reproduce it in a simple test, and it happens so rarely in my real applications, I'm okay with notice of it just being in google and here on sf. Maybe someday someone will encounter it again and we can make progress. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-10 12:45 Message: Logged In: YES user_id=31435 No, and there are no known bugs in Queue in 2.3.j. If John can't whittle it down to a test case that fails for others, I expect this bug is hopeless. We talked about it on c.l.py, and what he's seeing should be impossible. Presuming it's a Solaris-specific bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:35 Message: Logged In: YES user_id=80475 Tim, was this something you already fixed in Py2.4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080660&group_id=5470 From noreply at sourceforge.net Thu Dec 16 12:10:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 12:10:43 2004 Subject: [ python-Bugs-1085172 ] Uninstaller should restore file associations if possible Message-ID: Bugs item #1085172, was opened at 2004-12-14 10:13 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) >Assigned to: Martin v. L?wis (loewis) Summary: Uninstaller should restore file associations if possible Initial Comment: On installing on Windows, the Python installer associates .py and .pyw files to the new installation of python. The installer should cache the previous associations, and in the event of uninstallation restore them to their previous values if the application the are associated with still exists. This allows for easier migration back to 2.3 in this case, but also for easier back migration in the case of installing a beta version of python 2.5 or whatever in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 From noreply at sourceforge.net Thu Dec 16 13:33:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 13:34:07 2004 Subject: [ python-Bugs-1080864 ] locale.py doesn't recognize valid locale setting Message-ID: Bugs item #1080864, was opened at 2004-12-07 21:23 Message generated for change (Comment added) made by childsplay You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: stas Z (childsplay) Assigned to: M.-A. Lemburg (lemburg) Summary: locale.py doesn't recognize valid locale setting Initial Comment: stas@mobi:~$ locale LANG=nb_NO [...] stas@mobi:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getdefaultlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/locale.py", line 346, in getdefaultlocale return _parse_localename(localename) File "/usr/lib/python2.3/locale.py", line 280, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: nb_NO >>> ---------------------------------------------------------------------- >Comment By: stas Z (childsplay) Date: 2004-12-16 13:33 Message: Logged In: YES user_id=638376 Checked and it works ok, thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-13 20:58 Message: Logged In: YES user_id=38388 Thanks. I've noticed that the C lib doesn't seem to like "UTF-8" but works well with "UTF8" (no hyphen). Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.30; previous revision: 1.29 done Checking in Tools/i18n/makelocalealias.py; /cvsroot/python/python/dist/src/Tools/i18n/makelocalealias.py,v <-- makelocalealias.py new revision: 1.2; previous revision: 1.1 done Please check again with the updated version. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-11 17:18 Message: Logged In: YES user_id=638376 I've looked at the CVS/locale.py but is the utf8 entry missing? Don't know about the X alias mapping, but I suspect that there should also be an utf8 entry also for nb_NO/nn_NO. (Just as there is for no_NO) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 22:58 Message: Logged In: YES user_id=38388 Checking in Lib/locale.py; /cvsroot/python/python/dist/src/Lib/locale.py,v <-- locale.py new revision: 1.29; previous revision: 1.28 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-10 14:16 Message: Logged In: YES user_id=38388 Well, if the alias mapping is good enough for X, then it's good enough for me :-) I think we ought to update the alias table with the current data of the X locale.alias file. This file also includes the mappings that childsplay mentioned. There also seems to be a bug in the encoding alias table: "utf" is no longer recognized by setlocale(). This should be changed to "utf8". I'll fix that and post an update here. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-10 00:26 Message: Logged In: YES user_id=21627 getdefaultencoding might be "targeted" at the OS level - but the implementation certainly is not. On the OS level, the C library will often use a different encoding after locale.setlocale(locale.LC_ALL,"") is called, compared to what getdefaultencoding returns. The approach takien inside getdefaultencoding is inherently flawed, and cannot possibly work in all cases; getpreferredencoding fixes that flaw. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:56 Message: Logged In: YES user_id=38388 childsplay (I wish people would use real names on SF...): We can add the aliases you gave below, but we need some URLs to add as reference. Please provide this information, so that we can document that the aliases are in common use and why iso-8859-1 is their usually used encoding. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-09 10:42 Message: Logged In: YES user_id=38388 Martin: "default" as opposed to whatever locale setting is currently active for the program, i.e. the locale setting the program would see after a single call to setlocale(LC_ALL, "") right after the start of the program. getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, ""). The fact that the alias table may sometimes not give the correct encoding is not a fault of Python or the table - if the user wants to see a different encoding used as default encoding for the set locale, then the user should include that information in the LANG (or other) OS environment variable of the process running the Python program. Note that this is different than the "preferred" encoding which a user can set in a window manager (KDE or Gnome) or browser. Those settings are restricted to certain application spaces. getdefaultencoding() is targetted at the OS level setting which may be different from e.g. a KDE setting (think a program running in a shell vs. a KDE application run by a user). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-09 10:27 Message: Logged In: YES user_id=638376 I agree that "default" would probably be called "preferred". @loewis: a) I agree with your point of view but I as a developer I just want to get the current locale in use and locale.py serves that purpose in a platform independant way. The "never-ending maintenance problem" is the result of the locale horror we all have to live with until there's a final solution/standard for it. b) Agree, I now understand your "getdefaultlocale .. inherently broken" comment. But we still have a locale module that supports some of the valid locales but not all, which is (IMO) worse then having none at all. BTW: getting the current locale to get a platform independant language setting, should perhaps be part of gettext.py instead of locale.py? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 22:28 Message: Logged In: YES user_id=21627 MAL: that doesn't answer my question, though: In what sense does getdefaultlocale get a "default" locale? default as opposed to what custom setting? childsplay: the problem with adding additional aliases is a) we can never hope to get a complete list of locales, so this is a never-ending maintenance problem, and b) the dictionary might be wrong on some systems. E.g. sometimes, 'nb' might denote an ISO-8859-15 locale, or a UTF-8 locale (e.g. when UTF-8 becomes the standard encoding on Unix some day). If so, Python will silently compute an incorrect default - in particular wrt. the encoding of the "default" locale. ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 16:09 Message: Logged In: YES user_id=638376 This is what I've put into /python2.3/locale.py: locale_alias = {.... ....... 'bokm?l': 'nb_NO.ISO8859-1', 'nb': 'nb_NO.ISO8859-1', 'nb_no': 'nb_NO.ISO8859-1', 'nynorsk': 'nn_NO.ISO8859-1', 'nn': 'nn_NO.ISO8859-1', 'nn_no': 'nn_NO.ISO8859-1', .... .... } I have tested it on a number of apps and it fixes the problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 14:06 Message: Logged In: YES user_id=38388 Please provide some authorative source which describes the locale your are using (nb_NO) and the commonly used encoding for that locale (see the existing dictionary in locale.py). ---------------------------------------------------------------------- Comment By: stas Z (childsplay) Date: 2004-12-08 13:29 Message: Logged In: YES user_id=638376 The reason I use getdefaultlocale(), is to get a platform independant way of getting the systems locale setting. The biggest advantage is that on Windows a "Linux like" locale is returnt so that I can use the same language support stuff on all platforms. (Win,Linux,OSX). Besides, what's the problem of adding the missing locale? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 10:05 Message: Logged In: YES user_id=38388 The LANG (and other similar OS environment variables) define what the user wishes to see being used as locale in the applications that are started in that environment. See the setlocale man page for details. On some OSes such as Windows these settings are stored differently, which is why the locale module has provisions for finding these settings (thanks to Fredrik). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 08:04 Message: Logged In: YES user_id=21627 There is no "default locale setting" in most operating systems. In what sense is the value of the LANG environment variable a "default"? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-08 00:08 Message: Logged In: YES user_id=38388 Of course, I don't agree with you, Martin :-) locale.getdefaultlocale() does server a purpose, namely that of getting the default locale setting. The encoding information is an often used extension when setting the locale in the OS environment. If not set, the module provides common defaults. The locale "nb_NO" is not known to the module alias table. Which locale, language and encoding would that be ? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 23:13 Message: Logged In: YES user_id=21627 To get the default encoding for the current locale, you should use locale.getpreferredencoding(). You should not use getdefaultlocale becaus it is (IMO) inherently broken, and should not have been part of the standard library in the first place. ---------------------------------------------------------------------- Comment By: Jarek Zgoda (zgoda) Date: 2004-12-07 22:39 Message: Logged In: YES user_id=92222 getdefaultlocale() is often used to get default encoding for current system locale. And, if function is provided in standard library, why shouldn't one use it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 21:25 Message: Logged In: YES user_id=21627 Why do you want to use getdefaultlocale()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080864&group_id=5470 From noreply at sourceforge.net Thu Dec 16 14:00:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 14:00:32 2004 Subject: [ python-Bugs-518846 ] exception cannot be new-style class Message-ID: Bugs item #518846, was opened at 2002-02-17 21:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [magnus@gills magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:00 Message: Logged In: YES user_id=21627 This statement, as literally made, is incorrect: >>> class X(Exception): ... pass ... >>> e=X() >>> type(e) >>> raise e Traceback (most recent call last): File "", line 1, in ? __main__.X: <__main__.X instance at 0x401f2b4c> In this example, type(e) works, and x is an object which has Exception among its base classes. Still, I can throw x, despite your claim that I cannot. Even if I interpret your statement more literally (i.e. that you are talking about objects for which type(e) is a new-style class): Why do you think this statement explains there is a bug? As for why it is a new feature: it currently doesn't work, and anybody trying it will quickly find out that it doesn't work. The language reference says it doesn't work. The TypeError you get says it doesn't work. So that it doesn't work is clearly intentional; changing it will be a new feature. Notice that it is very difficult to implement this feature, as something needs to happen with strings and subtypes of str. Currently, string exceptions are caught by identity. If arbitrary objects can be used as exceptions, then strings should also be caught by type, not by identity; this is a backwards-incompatible change. A clean solution would be to deprecate string exceptions in 2.5, completely ban them in 2.6, and allow arbitrary objects to act as exceptions in 2.7. Please do read the entire thread of this RFE. ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-16 00:39 Message: Logged In: YES user_id=1179122 Let me try to rephrase the problem so that it's obvious that this is a bug, and not a feature: 'type(e)' on an exception will not work in 2.3, and cannot be made to work from within python code. There's no way to throw an exception (ie an object with Exception in its ancestor list) that 'type(e)' will work on. :( ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 22:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 22:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 03:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 22:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 19:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 18:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-06 02:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception, a __metaclass__ = type should not have any effect on the exceptions you declare. So I'm not sure what your problem is? Here's another idea for a patch: a new-style class is allowed as long as it also inherits from Exception. (This is possible!) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-06 01:49 Message: Logged In: YES user_id=31392 I don't realize there was agreement on this. (I didn't follow the discussion closely.) I don't understand why exceptions need to pass an isinstance() test on Exception. It didn't used to be this way, and it makes it hard to convert a module using __metaclass__ = type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-06 01:44 Message: Logged In: YES user_id=21627 I thought the agreement was that this is not a bug: You cannot really expect exceptions to work unless you inherit from Exception. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-06 01:38 Message: Logged In: YES user_id=31392 Martin, I think the attached patch is sufficient. It checks object type's for Py_TPFLAGS_HEAPTYPE. I believe this is the current way to spell "new-style class" although the spelling is odd if that's the meaning <0.2 wink>. If this patch makes sense to you, I'll flesh it out with some test cases and check it in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-18 00:44 Message: Logged In: YES user_id=21627 Interesting. I think we need to deprecate, then remove string exception before allowing arbitrary objects as exceptions. Or we could allow strings to be caught either by __builtin__.str, or by an identical string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 From noreply at sourceforge.net Thu Dec 16 14:07:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 14:08:00 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Nobody/Anonymous (nobody) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:07 Message: Logged In: YES user_id=21627 Can you please try the following things? 1. Run the script ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs) 2. Report the version of C:\WINDOWS\SYSTEM32\wscript.exe (5.6 is too imprecise - could it be that you have 5.6.0.8820?) 3. Install VBScript, from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943 -7E4B-4622-86EB-95A22B832CAA&displaylang=en ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 11:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Thu Dec 16 14:09:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 14:09:56 2004 Subject: [ python-Bugs-1085172 ] Uninstaller should restore file associations if possible Message-ID: Bugs item #1085172, was opened at 2004-12-14 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Martin v. L?wis (loewis) Summary: Uninstaller should restore file associations if possible Initial Comment: On installing on Windows, the Python installer associates .py and .pyw files to the new installation of python. The installer should cache the previous associations, and in the event of uninstallation restore them to their previous values if the application the are associated with still exists. This allows for easier migration back to 2.3 in this case, but also for easier back migration in the case of installing a beta version of python 2.5 or whatever in the future. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:09 Message: Logged In: YES user_id=21627 This is not possible to implement. If you want to not add associations for 2.4, you need to uncheck the "Register Extensions" feature in the installer UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 From noreply at sourceforge.net Thu Dec 16 14:56:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 14:56:58 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Comment added) made by axel_kaiser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-16 14:56 Message: Logged In: YES user_id=1176563 Okay, I finally was able to produce a small example. When I start python from the commandline with file "Lebenserwartung.py" python crashes. It doesn't crash when I remove the coding-line (1st line) of file "Sterbetafeln.py". (The example can't run properly due to missing files, but these don't influence the crashes) Best regards, Axel ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:39 Message: Logged In: YES user_id=21627 Can you create a small test case that demonstrates the problem? ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-15 21:58 Message: Logged In: YES user_id=1176563 Sorry, the attachment was not appended. By the way, the problem occurs without any external modules/libraries. It just juses python-source. The problem might be connected with the use of module array. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 19:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 16:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 10:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Thu Dec 16 15:34:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 15:34:45 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 15:34 Message: Logged In: YES user_id=89016 This sounds like it might be related to bug http://www.python.org/sf/1076985. Can you retry your scripts with the patch from http://www.python.org/sf/1076985? What happens if you replace the "cp1252" in the encoding header with "iso-8859- 1"? A quick workaround might be to wrap the long source lines in Sterbetafeln.py. ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-16 14:56 Message: Logged In: YES user_id=1176563 Okay, I finally was able to produce a small example. When I start python from the commandline with file "Lebenserwartung.py" python crashes. It doesn't crash when I remove the coding-line (1st line) of file "Sterbetafeln.py". (The example can't run properly due to missing files, but these don't influence the crashes) Best regards, Axel ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:39 Message: Logged In: YES user_id=21627 Can you create a small test case that demonstrates the problem? ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-15 21:58 Message: Logged In: YES user_id=1176563 Sorry, the attachment was not appended. By the way, the problem occurs without any external modules/libraries. It just juses python-source. The problem might be connected with the use of module array. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 19:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 16:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 10:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Thu Dec 16 16:21:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 16:21:20 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 16:18 Message generated for change (Comment added) made by anamh0001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Nobody/Anonymous (nobody) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- >Comment By: anamh0001 (anamh0001) Date: 2004-12-16 15:21 Message: Logged In: YES user_id=1178107 BUG FIXED -- solution below. 1) BTW I actually thought the installer was looking for c:\python24. So I created the folder before running the installer again. But it didnt work. When I ran the script. It returned this error: I used cscript. c:\x.vbs(2, 7) (null): The specified module could not be found. 2) The version of wscript and cscript is 5.6.0.8825 3) This is latest version because I read that installing the latest version of scripting host fixes installation problems. **** I managed to fix it. I registered scrrun.dll by typing: regsvr32 c:\windows\system32\scrrun.dll Thanks for all the help.. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 13:07 Message: Logged In: YES user_id=21627 Can you please try the following things? 1. Run the script ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs) 2. Report the version of C:\WINDOWS\SYSTEM32\wscript.exe (5.6 is too imprecise - could it be that you have 5.6.0.8820?) 3. Install VBScript, from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943 -7E4B-4622-86EB-95A22B832CAA&displaylang=en ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 10:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 22:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Thu Dec 16 17:14:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 17:14:50 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 17:18 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: anamh0001 (anamh0001) >Assigned to: Martin v. L?wis (loewis) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 16:21 Message: Logged In: YES user_id=1178107 BUG FIXED -- solution below. 1) BTW I actually thought the installer was looking for c:\python24. So I created the folder before running the installer again. But it didnt work. When I ran the script. It returned this error: I used cscript. c:\x.vbs(2, 7) (null): The specified module could not be found. 2) The version of wscript and cscript is 5.6.0.8825 3) This is latest version because I read that installing the latest version of scripting host fixes installation problems. **** I managed to fix it. I registered scrrun.dll by typing: regsvr32 c:\windows\system32\scrrun.dll Thanks for all the help.. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:07 Message: Logged In: YES user_id=21627 Can you please try the following things? 1. Run the script ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs) 2. Report the version of C:\WINDOWS\SYSTEM32\wscript.exe (5.6 is too imprecise - could it be that you have 5.6.0.8820?) 3. Install VBScript, from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943 -7E4B-4622-86EB-95A22B832CAA&displaylang=en ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 11:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Thu Dec 16 17:28:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 17:28:29 2004 Subject: [ python-Feature Requests-1085304 ] Make array.array pickle-able Message-ID: Feature Requests item #1085304, was opened at 2004-12-14 13:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085304&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nicolas Fleury (nidoizo) Assigned to: Raymond Hettinger (rhettinger) Summary: Make array.array pickle-able Initial Comment: Make array.array pickle-able. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 11:28 Message: Logged In: YES user_id=80475 Fixed. See Modules/arraymodule 2.97 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1085304&group_id=5470 From noreply at sourceforge.net Thu Dec 16 17:32:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 17:32:43 2004 Subject: [ python-Bugs-1085168 ] Uninstaller unclear about the app it's uninstalling Message-ID: Bugs item #1085168, was opened at 2004-12-14 10:05 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) >Assigned to: Martin v. L?wis (loewis) Summary: Uninstaller unclear about the app it's uninstalling Initial Comment: The "Uninstall Python" link added to the start mrnu Python 2.4 folder asks "Are you sure you wish to uninstall this product?". This should really ask whether you wish to uninstall Python 2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470 From noreply at sourceforge.net Thu Dec 16 17:36:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 17:36:54 2004 Subject: [ python-Bugs-1086555 ] refcount problem in syslog Message-ID: Bugs item #1086555, was opened at 2004-12-16 11:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: refcount problem in syslog Initial Comment: Refcount problem in syslog.openlog, dating back awhile: Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import syslog [25538 refs] >>> syslog.openlog('a') [25539 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25575 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25574 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25573 refs] [etc..] >>> syslog.openlog(0) Fatal Python error: /home/doug/cvsroot/python/dist/src/Modules/syslogmodule.c:62 object at 0x402d75d8 has negative ref count -4 Aborted ISTM there's a misplaced Py_XDECREF in syslog_openlog. It's fine as long as no log is open, but after that each failed PyArg_ParseTuple costs you a ref. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 From noreply at sourceforge.net Thu Dec 16 17:48:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 17:48:15 2004 Subject: [ python-Bugs-1085168 ] Uninstaller unclear about the app it's uninstalling Message-ID: Bugs item #1085168, was opened at 2004-12-14 16:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470 Category: Installation >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Martin v. L?wis (loewis) Summary: Uninstaller unclear about the app it's uninstalling Initial Comment: The "Uninstall Python" link added to the start mrnu Python 2.4 folder asks "Are you sure you wish to uninstall this product?". This should really ask whether you wish to uninstall Python 2.4 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 17:48 Message: Logged In: YES user_id=21627 This dialog is directly generated by Installer; the MSI package cannot influence the text displayed. Closing it as a third-party (Microsoft) bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085168&group_id=5470 From noreply at sourceforge.net Thu Dec 16 17:54:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 17:58:27 2004 Subject: [ python-Bugs-1086555 ] refcount problem in syslog Message-ID: Bugs item #1086555, was opened at 2004-12-16 11:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: refcount problem in syslog Initial Comment: Refcount problem in syslog.openlog, dating back awhile: Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import syslog [25538 refs] >>> syslog.openlog('a') [25539 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25575 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25574 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25573 refs] [etc..] >>> syslog.openlog(0) Fatal Python error: /home/doug/cvsroot/python/dist/src/Modules/syslogmodule.c:62 object at 0x402d75d8 has negative ref count -4 Aborted ISTM there's a misplaced Py_XDECREF in syslog_openlog. It's fine as long as no log is open, but after that each failed PyArg_ParseTuple costs you a ref. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 11:54 Message: Logged In: YES user_id=80475 See if the attached patch solves your problem. Also, please run the full test suite. (I'm on Windows and cannot exercise this code.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 From noreply at sourceforge.net Thu Dec 16 19:02:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 19:03:01 2004 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-16 13:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Thu Dec 16 19:51:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 19:52:00 2004 Subject: [ python-Bugs-1086555 ] refcount problem in syslog Message-ID: Bugs item #1086555, was opened at 2004-12-16 11:36 Message generated for change (Comment added) made by dsm001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: refcount problem in syslog Initial Comment: Refcount problem in syslog.openlog, dating back awhile: Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import syslog [25538 refs] >>> syslog.openlog('a') [25539 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25575 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25574 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25573 refs] [etc..] >>> syslog.openlog(0) Fatal Python error: /home/doug/cvsroot/python/dist/src/Modules/syslogmodule.c:62 object at 0x402d75d8 has negative ref count -4 Aborted ISTM there's a misplaced Py_XDECREF in syslog_openlog. It's fine as long as no log is open, but after that each failed PyArg_ParseTuple costs you a ref. ---------------------------------------------------------------------- >Comment By: DSM (dsm001) Date: 2004-12-16 13:51 Message: Logged In: YES user_id=1175690 Patch works after correcting typo (*new_S_ident_0 should be *new_S_ident_o); openlog() and closelog() both seem to refcount as expected; and passes make test without difficulty. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 11:54 Message: Logged In: YES user_id=80475 See if the attached patch solves your problem. Also, please run the full test suite. (I'm on Windows and cannot exercise this code.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 From noreply at sourceforge.net Thu Dec 16 20:21:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 20:21:54 2004 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 19:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Thu Dec 16 21:25:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 16 21:25:31 2004 Subject: [ python-Bugs-1086675 ] optparse docs missing section on Extending Message-ID: Bugs item #1086675, was opened at 2004-12-16 20:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086675&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: optparse docs missing section on Extending Initial Comment: In Python 2.3 the module docs for optparse include a fifth section, 6.20.5 Extending optparse. This section is no longer present in the docs for Python 2.4. It is still present in the current Optik docs (http://optik.sourceforge.net/doc/1.5/extending.html) so my guess is this is an inadvertent omission. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086675&group_id=5470 From noreply at sourceforge.net Fri Dec 17 00:52:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 00:52:41 2004 Subject: [ python-Bugs-1086555 ] refcount problem in syslog Message-ID: Bugs item #1086555, was opened at 2004-12-16 11:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: refcount problem in syslog Initial Comment: Refcount problem in syslog.openlog, dating back awhile: Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import syslog [25538 refs] >>> syslog.openlog('a') [25539 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25575 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25574 refs] >>> syslog.openlog(0) Traceback (most recent call last): File "", line 1, in ? TypeError: ident string [, logoption [, facility]] [25573 refs] [etc..] >>> syslog.openlog(0) Fatal Python error: /home/doug/cvsroot/python/dist/src/Modules/syslogmodule.c:62 object at 0x402d75d8 has negative ref count -4 Aborted ISTM there's a misplaced Py_XDECREF in syslog_openlog. It's fine as long as no log is open, but after that each failed PyArg_ParseTuple costs you a ref. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 18:52 Message: Logged In: YES user_id=80475 Fixed. See Modules/sysmodule.c 2.20 Thanks for submitting the bug report and testing the patch. ---------------------------------------------------------------------- Comment By: DSM (dsm001) Date: 2004-12-16 13:51 Message: Logged In: YES user_id=1175690 Patch works after correcting typo (*new_S_ident_0 should be *new_S_ident_o); openlog() and closelog() both seem to refcount as expected; and passes make test without difficulty. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 11:54 Message: Logged In: YES user_id=80475 See if the attached patch solves your problem. Also, please run the full test suite. (I'm on Windows and cannot exercise this code.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086555&group_id=5470 From noreply at sourceforge.net Fri Dec 17 01:00:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 01:00:19 2004 Subject: [ python-Bugs-1071248 ] Documented grammar for List displays incorrect (testlist) Message-ID: Bugs item #1071248, was opened at 2004-11-22 12:26 Message generated for change (Comment added) made by kermode You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenard Lindstrom (kermode) Assigned to: Jeremy Hylton (jhylton) Summary: Documented grammar for List displays incorrect (testlist) Initial Comment: In section 5.2.4 of the Python Reference Manual for Pythons 2.4 and 2.3 the definition testlist ::= test ( "," test )* [ "," ] should be testlist ::= test [ ( "," test )+ [ "," ] ] to conform with the definition of testlist_safe in the Grammar definition file. In other words, a trailing comma is not permitted if there is only one test in testlist. ---------------------------------------------------------------------- >Comment By: Lenard Lindstrom (kermode) Date: 2004-12-16 16:00 Message: Logged In: YES user_id=663274 Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> [x for x in 1,] File "", line 1 [x for x in 1,] ^ SyntaxError: invalid syntax >>> [x for x in 1,2,] [1, 2] >>> for x in 1,: ... print x ... 1 >>> ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2004-12-15 00:50 Message: Logged In: YES user_id=147070 but >>> testlist = 1, >>> testlist (1,) so testlist = 1 does not produce a list testlist ::= one "," ( another "," )* [and [","]] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071248&group_id=5470 From noreply at sourceforge.net Fri Dec 17 01:11:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 01:13:04 2004 Subject: [ python-Bugs-1086675 ] optparse docs missing section on Extending Message-ID: Bugs item #1086675, was opened at 2004-12-16 15:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086675&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Greg Ward (gward) Summary: optparse docs missing section on Extending Initial Comment: In Python 2.3 the module docs for optparse include a fifth section, 6.20.5 Extending optparse. This section is no longer present in the docs for Python 2.4. It is still present in the current Optik docs (http://optik.sourceforge.net/doc/1.5/extending.html) so my guess is this is an inadvertent omission. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086675&group_id=5470 From noreply at sourceforge.net Fri Dec 17 05:07:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 05:08:00 2004 Subject: [ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility Message-ID: Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Friesner (jfriesne) Assigned to: Nobody/Anonymous (nobody) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 From noreply at sourceforge.net Fri Dec 17 13:12:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 13:12:34 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Comment added) made by axel_kaiser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- >Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-17 13:12 Message: Logged In: YES user_id=1176563 That's it!!! I applied the patch to codecs.py and now it works without crash! Thanks a lot! Let's close this thread. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 15:34 Message: Logged In: YES user_id=89016 This sounds like it might be related to bug http://www.python.org/sf/1076985. Can you retry your scripts with the patch from http://www.python.org/sf/1076985? What happens if you replace the "cp1252" in the encoding header with "iso-8859- 1"? A quick workaround might be to wrap the long source lines in Sterbetafeln.py. ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-16 14:56 Message: Logged In: YES user_id=1176563 Okay, I finally was able to produce a small example. When I start python from the commandline with file "Lebenserwartung.py" python crashes. It doesn't crash when I remove the coding-line (1st line) of file "Sterbetafeln.py". (The example can't run properly due to missing files, but these don't influence the crashes) Best regards, Axel ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:39 Message: Logged In: YES user_id=21627 Can you create a small test case that demonstrates the problem? ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-15 21:58 Message: Logged In: YES user_id=1176563 Sorry, the attachment was not appended. By the way, the problem occurs without any external modules/libraries. It just juses python-source. The problem might be connected with the use of module array. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 19:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 16:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 10:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Fri Dec 17 13:59:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 13:59:09 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: M.-A. Lemburg (lemburg) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 13:59 Message: Logged In: YES user_id=38388 Walter, the fix to .read() looks OK, but the implementation of .readline() is not correct: there are far more line break characters in Unicode than just \n. The correct way to check would be by using .splitlines() which does know about all the possible line break characters in Unicode, plus it also handles line ends such as \r\n and just \r correctly. If .splitlines() returns a list with more than one entry you know that you've hit a line end and you can push the remaining entries entries back onto the .charbuffer. Another nit: you should bump the default for readsize to 72 - the average line size used in text files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 17 15:18:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 15:21:20 2004 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-16 18:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-17 14:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Fri Dec 17 19:12:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 19:12:52 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: M.-A. Lemburg (lemburg) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-17 19:12 Message: Logged In: YES user_id=89016 Here is a second version of the patch (fix_readline_and_read2.diff) that implements all those changes. With this we get "universal newline" support for free. Note that there is still one corner case: If the byte stream is temporarily exhausted and the last character read is a \r, and the next character read (once the stream contains new data) is an \n, this will result in two lines instead of one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 13:59 Message: Logged In: YES user_id=38388 Walter, the fix to .read() looks OK, but the implementation of .readline() is not correct: there are far more line break characters in Unicode than just \n. The correct way to check would be by using .splitlines() which does know about all the possible line break characters in Unicode, plus it also handles line ends such as \r\n and just \r correctly. If .splitlines() returns a list with more than one entry you know that you've hit a line end and you can push the remaining entries entries back onto the .charbuffer. Another nit: you should bump the default for readsize to 72 - the average line size used in text files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 17 20:22:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 20:22:12 2004 Subject: [ python-Bugs-1087216 ] datetime module documentation missing critical detail Message-ID: Bugs item #1087216, was opened at 2004-12-17 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 From noreply at sourceforge.net Fri Dec 17 20:56:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 20:56:39 2004 Subject: [ python-Bugs-1087216 ] datetime module documentation missing critical detail Message-ID: Bugs item #1087216, was opened at 2004-12-17 14:22 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-17 14:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo]]]]) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 1000000. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 From noreply at sourceforge.net Fri Dec 17 21:23:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 21:23:10 2004 Subject: [ python-Bugs-1087216 ] datetime module documentation missing critical detail Message-ID: Bugs item #1087216, was opened at 2004-12-17 13:22 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. ---------------------------------------------------------------------- >Comment By: Mike Meyer (mwm) Date: 2004-12-17 14:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-17 13:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo]]]]) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 1000000. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 From noreply at sourceforge.net Fri Dec 17 21:30:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 21:33:25 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-17 15:30 Message: Logged In: YES user_id=31435 FWIW, I'd leave this alone. The XML-RPC spec is braindead when it comes to floats, and any implementation that didn't accept scientific notation would have to go out of its way to cripple the facilities all languages with a string->double function supply. Raymond, under any IEEE-conforming string->double implementation, eval(repr(x))==x will hold provided that repr (x) be roughly correct to at least 17 significant decimal digits, and that x is finite. It doesn't matter whether the string uses exponent notation. OTOH, IIRC Python got in trouble once with some old Solaris string->double C routine that went insane if the string had "too many" characters. Indeed, making bad assumptions about maximum string length seems a lot more likely to me than that someone has a string- >double routine that can't deal with exponents. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 05:32 Message: Logged In: YES user_id=80475 After more thought, I'm concerned that switching to full decimal notation will break the guarantee eval(repr(x))==x. Also, Skip's thoughts seem reasonable. Rather than switching to a non-compact format, it may be best to way for the spec to catchup with real implementations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 17:19 Message: Logged In: YES user_id=80475 Various slightly unsatisfactory answers: * It started out that way because that's what C did. * It stayed that way because no one has requested it * It may be that outside of XMLRPC there are very few valid use cases. * Future needs can be met by the decimal module. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2004-12-13 14:04 Message: Logged In: YES user_id=133955 I'm gonna ask a stupid question (I'm quite a beginner in Python). Why isn't there a %f-life formatting code for doing just what you wrote - printing the float in full precision in non-exponent format ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 13:12 Message: Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 10:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 08:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Fri Dec 17 21:46:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 21:46:53 2004 Subject: [ python-Bugs-518846 ] exception cannot be new-style class Message-ID: Bugs item #518846, was opened at 2002-02-17 12:09 Message generated for change (Comment added) made by robey1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Heino (magnusheino) Assigned to: Guido van Rossum (gvanrossum) Summary: exception cannot be new-style class Initial Comment: [magnus@gills magnus]$ python2.2 Python 2.2 (#1, Jan 26 2002, 14:27:24) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class foo(object): ... pass ... >>> raise foo() Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: exceptions must be strings, classes, or instances, not foo >>> ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-17 12:46 Message: Logged In: YES user_id=1179122 (I wish we could do this in email instead of cluttering up an already-messy bug...) Forget about throwing non-Exception-based objects: it's a red herring. The bug to focus on is the title: "exception cannot be new-style class". Bottom line: This subclass of Exception can not be raised in python 2.3: class MyException (Exception, object): pass pje's comment below from (2002-07-11 13:12) is a nice summary of how to solve it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 05:00 Message: Logged In: YES user_id=21627 This statement, as literally made, is incorrect: >>> class X(Exception): ... pass ... >>> e=X() >>> type(e) >>> raise e Traceback (most recent call last): File "", line 1, in ? __main__.X: <__main__.X instance at 0x401f2b4c> In this example, type(e) works, and x is an object which has Exception among its base classes. Still, I can throw x, despite your claim that I cannot. Even if I interpret your statement more literally (i.e. that you are talking about objects for which type(e) is a new-style class): Why do you think this statement explains there is a bug? As for why it is a new feature: it currently doesn't work, and anybody trying it will quickly find out that it doesn't work. The language reference says it doesn't work. The TypeError you get says it doesn't work. So that it doesn't work is clearly intentional; changing it will be a new feature. Notice that it is very difficult to implement this feature, as something needs to happen with strings and subtypes of str. Currently, string exceptions are caught by identity. If arbitrary objects can be used as exceptions, then strings should also be caught by type, not by identity; this is a backwards-incompatible change. A clean solution would be to deprecate string exceptions in 2.5, completely ban them in 2.6, and allow arbitrary objects to act as exceptions in 2.7. Please do read the entire thread of this RFE. ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 15:39 Message: Logged In: YES user_id=1179122 Let me try to rephrase the problem so that it's obvious that this is a bug, and not a feature: 'type(e)' on an exception will not work in 2.3, and cannot be made to work from within python code. There's no way to throw an exception (ie an object with Exception in its ancestor list) that 'type(e)' will work on. :( ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 13:59 Message: Logged In: YES user_id=21627 Whatever the solution to this problem, it is for sure that 2.4.x won't see it, because it will be a new feature. ---------------------------------------------------------------------- Comment By: Robey Pointer (robey1) Date: 2004-12-15 13:08 Message: Logged In: YES user_id=1179122 This caused me an hour of debugging a few nights ago. When using unified types, it's very confusing to find that not only does Exception not follow new-style object semantics, but it *can't*. Doing the obvious hack: class MyException (Exception, object): pass does not work! The interpreter (2.3) refuses to let you raise a unified-type object. And if you subclass exclusively from Exception, type(obj) returns 'instance' instead of the class (due to being an old-style object). Please fix this for 2.4! ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-24 18:05 Message: Logged In: YES user_id=752496 Reproduced the bug in Py2.3. I think that this is a bug, at least because we "encourage" users to derive exceptions from Exception, so they should be able to not do it. The moment we say that they "must" derive from Exception, this can be closed (of course, this is my *very* personal opinion, ;) ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2002-07-11 13:12 Message: Logged In: YES user_id=56214 Just to make things even more interesting, the current 'raise' code *will* let you raise a new-style instance that derives from 'tuple'... of course, what it actually raises is the first element of said tuple-like thing. It seems to me that the very first thing that should be checked is whether the first argument to 'raise' is an instance of Exception, and if so, take its type and go from there. This would support both old and new-style instances of Exception subclasses, and I believe is the recommended approach to using 'raise'. (I.e., raise an instance of something that subclasses Exception.) All the other items like strings, tuples, etc., should be checked *after* a check for the "standard" approach, yes? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 10:07 Message: Logged In: YES user_id=89016 test.py is a little script that executes various test cases. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2002-07-11 09:12 Message: Logged In: YES user_id=89016 What about the following patch (diff.txt): It allows new style objects as exceptions and makes catching exceptions by basetype possible: class newint(int): pass try: raise newint(42) except int, exc: print exc With this patch subinstances of str become raisable and will be caught be type not identity. This could be changed to explicitely forbid str subinstances. And raise type(None), None becomes ambiguous: It is interpreted as raise type(None) i.e. it raises the type(None) object as an exception, not the object None (which is of type type(None)) As soon as Exception is a new style class we could limit the allowed objects to (sub)instances of Exception. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 16:07 Message: Logged In: YES user_id=6380 Sorry, HEAPTYPE is not the proper way to check for a new-style class; it would exclude any new-style classes defined by C code. I also think that if you want to do this it should done properly, and allow "raise C, C()" as well. At best there's agreement that it's not worth trying to fix Python to allow new-style classes as exceptions when we're also trying to encourage that exceptions derive from Exception. If your module declares its exceptions as deriving from Exception, a __metaclass__ = type should not have any effect on the exceptions you declare. So I'm not sure what your problem is? Here's another idea for a patch: a new-style class is allowed as long as it also inherits from Exception. (This is possible!) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 15:49 Message: Logged In: YES user_id=31392 I don't realize there was agreement on this. (I didn't follow the discussion closely.) I don't understand why exceptions need to pass an isinstance() test on Exception. It didn't used to be this way, and it makes it hard to convert a module using __metaclass__ = type. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-05 15:44 Message: Logged In: YES user_id=21627 I thought the agreement was that this is not a bug: You cannot really expect exceptions to work unless you inherit from Exception. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-04-05 15:38 Message: Logged In: YES user_id=31392 Martin, I think the attached patch is sufficient. It checks object type's for Py_TPFLAGS_HEAPTYPE. I believe this is the current way to spell "new-style class" although the spelling is odd if that's the meaning <0.2 wink>. If this patch makes sense to you, I'll flesh it out with some test cases and check it in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-17 15:44 Message: Logged In: YES user_id=21627 Interesting. I think we need to deprecate, then remove string exception before allowing arbitrary objects as exceptions. Or we could allow strings to be caught either by __builtin__.str, or by an identical string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 From noreply at sourceforge.net Fri Dec 17 22:05:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 22:05:52 2004 Subject: [ python-Bugs-1087216 ] datetime module documentation missing critical detail Message-ID: Bugs item #1087216, was opened at 2004-12-17 13:22 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-17 15:05 Message: Logged In: YES user_id=44345 Pydoc generates documentation based upon what it finds in docstrings and function signatures. It can't get at the signatures of functions written in C. In Python 2.4 pydoc generates a link to a local or online version of the docs for the subject module: NAME datetime - Fast implementation of the datetime type. FILE /Users/skip/local/lib/python2.5/lib-dynload/datetime.so MODULE DOCS http://www.python.org/doc/current/lib/module-datetime.html CLASSES __builtin__.object date datetime ... I think that's the best that can be done short of macroizing the hell out of C extension modules to allow function signatures to be captured as attributes attached to the functions, similar to what GNU Emacs did many years ago. Correct me if I'm wrong, but I don't think we want to go down that path (take a peek at the Emacs source if you are in doubt). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2004-12-17 14:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-17 13:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo]]]]) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 1000000. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 From noreply at sourceforge.net Fri Dec 17 22:19:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 22:19:09 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sebastian Hartte (dark-storm) >Assigned to: Walter D?rwald (doerwalter) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 22:19 Message: Logged In: YES user_id=38388 Looks good, please check it in with one correction: "".join() should be u"".join(). Thanks, Walter ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-17 19:12 Message: Logged In: YES user_id=89016 Here is a second version of the patch (fix_readline_and_read2.diff) that implements all those changes. With this we get "universal newline" support for free. Note that there is still one corner case: If the byte stream is temporarily exhausted and the last character read is a \r, and the next character read (once the stream contains new data) is an \n, this will result in two lines instead of one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 13:59 Message: Logged In: YES user_id=38388 Walter, the fix to .read() looks OK, but the implementation of .readline() is not correct: there are far more line break characters in Unicode than just \n. The correct way to check would be by using .splitlines() which does know about all the possible line break characters in Unicode, plus it also handles line ends such as \r\n and just \r correctly. If .splitlines() returns a list with more than one entry you know that you've hit a line end and you can push the remaining entries entries back onto the .charbuffer. Another nit: you should bump the default for readsize to 72 - the average line size used in text files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Fri Dec 17 23:28:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 23:29:12 2004 Subject: [ python-Bugs-1087216 ] datetime module documentation missing critical detail Message-ID: Bugs item #1087216, was opened at 2004-12-17 14:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-17 17:28 Message: Logged In: YES user_id=80475 It looks like the docstrings could be a bit more informative: >>> print datetime.date.__doc__ Basic date type. Compare that with: >>> print collections.deque.__doc__ deque(iterable) --> deque object Build an ordered collection accessible from endpoints only. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-17 16:05 Message: Logged In: YES user_id=44345 Pydoc generates documentation based upon what it finds in docstrings and function signatures. It can't get at the signatures of functions written in C. In Python 2.4 pydoc generates a link to a local or online version of the docs for the subject module: NAME datetime - Fast implementation of the datetime type. FILE /Users/skip/local/lib/python2.5/lib-dynload/datetime.so MODULE DOCS http://www.python.org/doc/current/lib/module-datetime.html CLASSES __builtin__.object date datetime ... I think that's the best that can be done short of macroizing the hell out of C extension modules to allow function signatures to be captured as attributes attached to the functions, similar to what GNU Emacs did many years ago. Correct me if I'm wrong, but I don't think we want to go down that path (take a peek at the Emacs source if you are in doubt). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2004-12-17 15:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-17 14:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo]]]]) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 1000000. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 From noreply at sourceforge.net Fri Dec 17 23:32:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 17 23:32:53 2004 Subject: [ python-Bugs-1084279 ] status of small floats in xml-rpc ? Message-ID: Bugs item #1084279, was opened at 2004-12-13 05:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: status of small floats in xml-rpc ? Initial Comment: Hi, I've been reading through the xmlrpclib.py code to see that floats are marshalled the following way: def dump_double(self, value, write): write("") write(repr(value)) write("\n") dispatch[FloatType] = dump_double Using repr() means that small or big floats, for example, will be output using the exponent notation: >>> repr(2**-15) '3.0517578125e-05' Unfortunately, the XML-RPC specification does not allow this notation: "At this time, only decimal point notation is allowed, a plus or a minus, followed by any number of numeric characters, followed by a period and any number of numeric characters. Whitespace is not allowed. The range of allowable values is implementation-dependent, is not specified." (http://www.xmlrpc.com/spec) Thus floats marshalled using xmlrpclib may not be readable using other XML-RPC implementations. (I don't have any concrete data about this though) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-17 15:30 Message: Logged In: YES user_id=31435 FWIW, I'd leave this alone. The XML-RPC spec is braindead when it comes to floats, and any implementation that didn't accept scientific notation would have to go out of its way to cripple the facilities all languages with a string->double function supply. Raymond, under any IEEE-conforming string->double implementation, eval(repr(x))==x will hold provided that repr (x) be roughly correct to at least 17 significant decimal digits, and that x is finite. It doesn't matter whether the string uses exponent notation. OTOH, IIRC Python got in trouble once with some old Solaris string->double C routine that went insane if the string had "too many" characters. Indeed, making bad assumptions about maximum string length seems a lot more likely to me than that someone has a string- >double routine that can't deal with exponents. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-16 05:32 Message: Logged In: YES user_id=80475 After more thought, I'm concerned that switching to full decimal notation will break the guarantee eval(repr(x))==x. Also, Skip's thoughts seem reasonable. Rather than switching to a non-compact format, it may be best to way for the spec to catchup with real implementations. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 17:19 Message: Logged In: YES user_id=80475 Various slightly unsatisfactory answers: * It started out that way because that's what C did. * It stayed that way because no one has requested it * It may be that outside of XMLRPC there are very few valid use cases. * Future needs can be met by the decimal module. ---------------------------------------------------------------------- Comment By: Antoine Pitrou (pitrou) Date: 2004-12-13 14:04 Message: Logged In: YES user_id=133955 I'm gonna ask a stupid question (I'm quite a beginner in Python). Why isn't there a %f-life formatting code for doing just what you wrote - printing the float in full precision in non-exponent format ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 13:12 Message: Logged In: YES user_id=80475 The thought was "be liberal in what you accept and be strict on was is emitted." Still, the question is valid. For C, it looks like strtod() is at the root of everything converting from floats. The spec lays no limits on the input format (exponents vs full decimal representation). Instead, it just checks that the result is inside the range of representable values and did not underflow. Some experiments with MSC6 confirm that the full range may be entered as regular decimals. Experiments with Perl show the same result. I suspect all TCL and Ruby also have strtod() at the core. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-13 10:38 Message: Logged In: YES user_id=44345 I understand what you''re doing, but I wonder if in the process interoperability with other XML-RPC implementations might actually get worse. While the spec doesn't support exponential notation, most programming languages do, and probably happily accept "1.234e-147" as a floating point input. Python seems not to have problems accepting floating point inputs with huge numbers of zeroes before or after the decimal point, but other languages may not be quite so forgiving. I think we need to be a bit careful before changing our implementation. At the very least we should probably verify the acceptance of non_e_repr-generated strings by a few other languages commonly used with XML-RPC (C, Perl, Tcl, Ruby?). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 08:13 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-13 07:40 Message: Logged In: YES user_id=80475 I loaded a recipe for a helper function that meets the spec: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/358361 Inserting and applying the helper function ought to be backwards compatible (the new encoding is readable by previous versions). Martin, do you agree with approach and concur that it should be backported? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084279&group_id=5470 From noreply at sourceforge.net Sat Dec 18 05:33:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 05:33:33 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-11 15:06 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-17 20:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 06:22:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 06:22:53 2004 Subject: [ python-Feature Requests-1087418 ] long int bitwise ops speedup (patch included) Message-ID: Feature Requests item #1087418, was opened at 2004-12-18 00:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: long int bitwise ops speedup (patch included) Initial Comment: The 'inner loop' for applying bitwise ops to longs is quite inefficient. The improvement in the attached diff is - 'a' is never shorter than 'b' (result: only test 1 loop index condition instead of 3) - each operation ( & | ^ ) has its own loop, instead of switch inside loop - I found that, when this is done, a lot of things can be simplified, resulting in further speedup, and the resulting code is not very much longer than before (my libpython2.4.dll .text got 140 bytes longer). Operations on longs of a few thousand bits appear to be 2 ... 2.5 times faster with this patch. I'm not 100% sure the code is right, but it passes test_long.py, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 From noreply at sourceforge.net Sat Dec 18 08:56:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 08:56:51 2004 Subject: [ python-Bugs-1081045 ] readline module doesn't build on MacOSX Message-ID: Bugs item #1081045, was opened at 2004-12-07 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL= /sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS= -L/sw/lib CONFIG_ARGS= '--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-17 23:56 Message: Logged In: YES user_id=357491 I was able to reproduce the problem of the environment variable returning None for a short time (it for some reason stopped doing that and started to do what I expected). While I could, though, I was able to get the right values using distutils.sysconfig.get_config_var(). The attached file adds a little bit more debugging output and also switches over to using distutils.sysconfig.get_config_var() instead of sys.getenv(). Let me know if that fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=357491 I have uploaded a patch to add some debugging output. Can you run make and let me know what it outputs (might need to touch a file to trigger the need for setup.py to execute)? I need to know exactly what the environment variables are set to when they are parsed and what setup.py ends up with for its library and include directories. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 18:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 From noreply at sourceforge.net Sat Dec 18 10:06:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 10:06:04 2004 Subject: [ python-Bugs-1083793 ] Python 2.4 crashes Message-ID: Bugs item #1083793, was opened at 2004-12-12 10:25 Message generated for change (Settings changed) made by axel_kaiser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Axel Kaiser (axel_kaiser) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 crashes Initial Comment: The new Python 2.4 crashes when starting some of my programs. This happens under win xp as well as under win nt. The crashes are reproduceble, but I didn't succeed in finding the exact place where it happens. In the attachment you find a Dr. Watson logfile. I hope it helps. Otherwise I think I will be able to help with more information. Thanks in advance Axel Kaiser Germany ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-17 13:12 Message: Logged In: YES user_id=1176563 That's it!!! I applied the patch to codecs.py and now it works without crash! Thanks a lot! Let's close this thread. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 15:34 Message: Logged In: YES user_id=89016 This sounds like it might be related to bug http://www.python.org/sf/1076985. Can you retry your scripts with the patch from http://www.python.org/sf/1076985? What happens if you replace the "cp1252" in the encoding header with "iso-8859- 1"? A quick workaround might be to wrap the long source lines in Sterbetafeln.py. ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-16 14:56 Message: Logged In: YES user_id=1176563 Okay, I finally was able to produce a small example. When I start python from the commandline with file "Lebenserwartung.py" python crashes. It doesn't crash when I remove the coding-line (1st line) of file "Sterbetafeln.py". (The example can't run properly due to missing files, but these don't influence the crashes) Best regards, Axel ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:39 Message: Logged In: YES user_id=21627 Can you create a small test case that demonstrates the problem? ---------------------------------------------------------------------- Comment By: Axel Kaiser (axel_kaiser) Date: 2004-12-15 21:58 Message: Logged In: YES user_id=1176563 Sorry, the attachment was not appended. By the way, the problem occurs without any external modules/libraries. It just juses python-source. The problem might be connected with the use of module array. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-15 19:02 Message: Logged In: YES user_id=80475 Any objections to marking this as Invalid and closing the bug? ---------------------------------------------------------------------- Comment By: Wolfgang Langner (tds33) Date: 2004-12-15 16:16 Message: Logged In: YES user_id=600792 The FILE pointer is specific to your c-lib. Different versions of the ms c-lib have incompatible implementations of this structure. To work arround such problems use python to get the right FILE* Example (not tested): /* use pythons std c library to produce a FILE object to avoid mess with different c libs in debug or release mode and different versions used to compile python */ PyObject* pyFile = PyFile_FromString(fileName, "r"); FILE* const file = PyFile_AsFile(pyFile); assert(0 != file); const int succ = PyRun_SimpleFile(file, fileName); // now remove py file object Py_XDECREF(pyFile); ---------------------------------------------------------------------- Comment By: salyee (salyee) Date: 2004-12-15 07:17 Message: Logged In: YES user_id=1178573 I have the same or similar problem. While python24.dll(Python 2.4 for Windows) uses msvcr71.dll for CRT, host C++ program embeding Python 2.4 as a script engine, in my project, is compiled by VC++ 6.0 (msvcrt.dll). So, the following code snip makes a crash. FILE* fp = fopen("somecode.py", "rt"); // uses msvcrt.dll PyRun_SimpleFile(fp, "somecode.py); // uses msvcr71.dll inside. Cause of a crash. In my case, I must use VC++ 6.0 and I want clients of my program to install Python 2.4 from www.python.org. How do I solve this problem ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-12 10:56 Message: Logged In: YES user_id=80475 The attachment didn't make it. Be sure to check the upload box or it won't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083793&group_id=5470 From noreply at sourceforge.net Sat Dec 18 11:45:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 11:48:33 2004 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-17 03:02 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-18 19:45 Message: Logged In: YES user_id=671362 FYI, I can reproduce this with : - Python 2.4 & readline 4.3 under SuSE 9.1 - Python 2.5(snapshot as of 2004-12-17) & readline 4.3 under SuSE 9.1 - Python 2.4 & readline 4.3.5(?) under Cygwin ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-17 23:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Sat Dec 18 12:48:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 12:48:17 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-12 00:06 Message generated for change (Comment added) made by dvch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 12:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 05:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 14:29:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 14:29:50 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-11 18:06 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) >Assigned to: Raymond Hettinger (rhettinger) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 06:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-17 23:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 15:08:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 15:08:44 2004 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 17:47 Message generated for change (Comment added) made by bjoti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Tim Peters (tim_one) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- >Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 15:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-15 04:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Sat Dec 18 15:34:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 15:34:13 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-11 18:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Raymond Hettinger (rhettinger) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 09:34 Message: Logged In: YES user_id=80475 Please try out the attached patch and let me know if the full test_suite passes. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 06:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-17 23:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 16:33:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 16:33:16 2004 Subject: [ python-Bugs-1087551 ] inspect.py module Message-ID: Bugs item #1087551, was opened at 2004-12-18 21:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087551&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sprasanna199 (sprasanna199) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.py module Initial Comment: I tried to compile python 2.4 inspect.py module in Jython but it throwed an exception. The line 749 in the inspect.py module caused the exception which is start = lineno - 1 - context//2 The code corresponding to it was also shown. But when I modified that line to start = lineno - 1 - context/2 it worked. Regards, S.Prasanna Code: if context > 0: start = lineno - 1 - context//2 try: lines, lnum = findsource(frame) except IOError: lines = index = None else: start = max(start, 1) start = min(start, len(lines) - context) lines = lines[start:start+context] index = lineno - 1 - start else: lines = index = None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087551&group_id=5470 From noreply at sourceforge.net Sat Dec 18 17:04:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 17:04:12 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-12 00:06 Message generated for change (Comment added) made by dvch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Raymond Hettinger (rhettinger) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 17:04 Message: Logged In: YES user_id=729909 test_list and test_userlist succeed now, great, thanks. test_imp still fails as before :-( Detlef ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 15:34 Message: Logged In: YES user_id=80475 Please try out the attached patch and let me know if the full test_suite passes. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 12:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 05:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 17:21:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 17:21:32 2004 Subject: [ python-Bugs-1087551 ] inspect.py module Message-ID: Bugs item #1087551, was opened at 2004-12-18 10:33 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087551&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sprasanna199 (sprasanna199) >Assigned to: Samuele Pedroni (pedronis) Summary: inspect.py module Initial Comment: I tried to compile python 2.4 inspect.py module in Jython but it throwed an exception. The line 749 in the inspect.py module caused the exception which is start = lineno - 1 - context//2 The code corresponding to it was also shown. But when I modified that line to start = lineno - 1 - context/2 it worked. Regards, S.Prasanna Code: if context > 0: start = lineno - 1 - context//2 try: lines, lnum = findsource(frame) except IOError: lines = index = None else: start = max(start, 1) start = min(start, len(lines) - context) lines = lines[start:start+context] index = lineno - 1 - start else: lines = index = None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087551&group_id=5470 From noreply at sourceforge.net Sat Dec 18 19:05:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 19:05:20 2004 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 17:47 Message generated for change (Comment added) made by bjoti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) Assigned to: Tim Peters (tim_one) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- >Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 19:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 15:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-15 04:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Sat Dec 18 20:41:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 20:41:35 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-11 18:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Detlef Vollmann (dvch) >Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 14:41 Message: Logged In: YES user_id=80475 Applied the decimal fixup. It is no longer dependent on threads. See Lib/decimal.py 1.32 and 1.31.2.1 Am unassigning myself for the rest. It's not an especially high priority to teach regrtest.py about tests that should be skipped when there are no threads. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 11:04 Message: Logged In: YES user_id=729909 test_list and test_userlist succeed now, great, thanks. test_imp still fails as before :-( Detlef ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 09:34 Message: Logged In: YES user_id=80475 Please try out the attached patch and let me know if the full test_suite passes. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 06:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-17 23:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 20:59:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 20:59:21 2004 Subject: [ python-Bugs-1081045 ] readline module doesn't build on MacOSX Message-ID: Bugs item #1081045, was opened at 2004-12-07 20:19 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL= /sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS= -L/sw/lib CONFIG_ARGS= '--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-18 13:59 Message: Logged In: YES user_id=44345 That worked... Thanks... (check it in?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 01:56 Message: Logged In: YES user_id=357491 I was able to reproduce the problem of the environment variable returning None for a short time (it for some reason stopped doing that and started to do what I expected). While I could, though, I was able to get the right values using distutils.sysconfig.get_config_var(). The attached file adds a little bit more debugging output and also switches over to using distutils.sysconfig.get_config_var() instead of sys.getenv(). Let me know if that fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-10 13:44 Message: Logged In: YES user_id=357491 I have uploaded a patch to add some debugging output. Can you run make and let me know what it outputs (might need to touch a file to trigger the need for setup.py to execute)? I need to know exactly what the environment variables are set to when they are parsed and what setup.py ends up with for its library and include directories. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 20:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 From noreply at sourceforge.net Sat Dec 18 21:48:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 21:48:42 2004 Subject: [ python-Bugs-1081045 ] readline module doesn't build on MacOSX Message-ID: Bugs item #1081045, was opened at 2004-12-07 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 Category: Build Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: readline module doesn't build on MacOSX Initial Comment: Recent changes to either configure or setup.py seem to have conspired to prevent the readline module from building on MacOSX. I configured and built with LDFLAGS='-L/sw/lib' CPPFLAGS='-I/sw/include' ../ configure '--prefix=/Users/skip/local' make The relevant readline bits are in /sw/... but the module is not built. The following bits containing /sw grep out of the generated Makefile: INSTALL= /sw/bin/install -c CPPFLAGS= -I. -I$(srcdir)/Include -I/sw/include LDFLAGS= -L/sw/lib CONFIG_ARGS= '--prefix=/Users/skip/local' 'CPPFLAGS=-I/sw/include' 'LDFLAGS=-L/sw/lib' Assigning to Brett since he touched this most recently. Skip ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-18 12:48 Message: Logged In: YES user_id=357491 Checked in under rev. 1.209 in setup.py . ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-18 11:59 Message: Logged In: YES user_id=44345 That worked... Thanks... (check it in?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-17 23:56 Message: Logged In: YES user_id=357491 I was able to reproduce the problem of the environment variable returning None for a short time (it for some reason stopped doing that and started to do what I expected). While I could, though, I was able to get the right values using distutils.sysconfig.get_config_var(). The attached file adds a little bit more debugging output and also switches over to using distutils.sysconfig.get_config_var() instead of sys.getenv(). Let me know if that fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-10 11:44 Message: Logged In: YES user_id=357491 I have uploaded a patch to add some debugging output. Can you run make and let me know what it outputs (might need to touch a file to trigger the need for setup.py to execute)? I need to know exactly what the environment variables are set to when they are parsed and what setup.py ends up with for its library and include directories. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-07 18:46 Message: Logged In: YES user_id=44345 More on this... Sticking a print of lib_dirs just before setup.py checks for readline shows that /sw/lib is not in that list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081045&group_id=5470 From noreply at sourceforge.net Sat Dec 18 22:10:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 22:10:43 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-11 15:06 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-18 13:10 Message: Logged In: YES user_id=357491 test_imp is now skipped on platforms that don't have threading. Covered by rev. 1.5 in HEAD, rev. 1.4.14.1 for 2.4, and rev. 1.4.10.1 for 2.3 . This takes care of all the reported tests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 11:41 Message: Logged In: YES user_id=80475 Applied the decimal fixup. It is no longer dependent on threads. See Lib/decimal.py 1.32 and 1.31.2.1 Am unassigning myself for the rest. It's not an especially high priority to teach regrtest.py about tests that should be skipped when there are no threads. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 08:04 Message: Logged In: YES user_id=729909 test_list and test_userlist succeed now, great, thanks. test_imp still fails as before :-( Detlef ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 06:34 Message: Logged In: YES user_id=80475 Please try out the attached patch and let me know if the full test_suite passes. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 03:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-17 20:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sat Dec 18 22:22:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 22:22:31 2004 Subject: [ python-Bugs-980127 ] Possible error during LINKCC check in Configure.in Message-ID: Bugs item #980127, was opened at 2004-06-25 20:31 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980127&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Possible error during LINKCC check in Configure.in Initial Comment: Under OS X 10.3.4 (gcc 3.3), when I run ./configure, I get an error from ld about an undefined symbol:: checking LIBRARY... libpython$(VERSION).a checking LINKCC... ld: Undefined symbols: ___gxx_personality_v0 $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... I think that specific symbol comes up only when there is a linking error to the Standard C++ library, but I am not sure. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-18 13:22 Message: Logged In: YES user_id=357491 Closing this myself since the message does not seemed to be avoidable. Redirecting stdout to stderr and stderr to /dev/null still has the message showing up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980127&group_id=5470 From noreply at sourceforge.net Sat Dec 18 22:40:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 22:40:56 2004 Subject: [ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Later Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools for --enable-unicode=ucs4 Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-18 13:40 Message: Logged In: YES user_id=357491 This test still fails in 2.4 and so far in 2.5 . Does this still deserve a "later" resolution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 14:27 Message: Logged In: YES user_id=357491 Sorry, Jack. I didn't know that this was a Unicode issue. Oh well, at least the cause has been narrowed down. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 12:35 Message: Logged In: YES user_id=45365 Boo, hiss! :-) You're using --enable-unicode=ucs4 and you didn't tell me that when there's a unicode problem:-) My guess is that I'm somewhere grabbing the pointer from the Python unicode object and passing that straight to the Apple routines, which will fail miserably because they expect ucs2 (or utf16, or whatever it's called). Actually, I wouldn't be surprised if there are more places where I do that. Yes, looking at the data returned this looks like a very likely scenario. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 11:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 08:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-21 23:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-19 17:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply at sourceforge.net Sat Dec 18 23:49:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 18 23:49:24 2004 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 10:29 Message generated for change (Comment added) made by yenzenz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- Comment By: Jens Klein (yenzenz) Date: 2004-12-18 23:49 Message: Logged In: YES user_id=474612 +1 from me Archetypes (a Zope framework) runs also in a problem because of the missing alias. more infos: https://sourceforge.net/tracker/index.php? func=detail&aid=1068001&group_id=75272&atid=543430 ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-17 11:47 Message: Logged In: YES user_id=46639 The test was just a sequence of random high-bit characters: ?????????????? (lets see if the web interface lets that through). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-17 11:12 Message: Logged In: YES user_id=38388 Are you sure ? The decoded string you give does not look like anything readable... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Sun Dec 19 00:01:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 00:01:51 2004 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 10:29 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-19 00:01 Message: Logged In: YES user_id=38388 I have no problem adding aliases to the encodings package, but please provide some reference that this actually is a valid alias for the mac_roman encoding. There are quite a few other mac_* encodings to choose from as well, so the coice is not obvious to me. ---------------------------------------------------------------------- Comment By: Jens Klein (yenzenz) Date: 2004-12-18 23:49 Message: Logged In: YES user_id=474612 +1 from me Archetypes (a Zope framework) runs also in a problem because of the missing alias. more infos: https://sourceforge.net/tracker/index.php? func=detail&aid=1068001&group_id=75272&atid=543430 ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-17 11:47 Message: Logged In: YES user_id=46639 The test was just a sequence of random high-bit characters: ?????????????? (lets see if the web interface lets that through). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-17 11:12 Message: Logged In: YES user_id=38388 Are you sure ? The decoded string you give does not look like anything readable... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:04:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:04:32 2004 Subject: [ python-Bugs-1087735 ] mmap instance method access bug Message-ID: Bugs item #1087735, was opened at 2004-12-18 16:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087735&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: mmap instance method access bug Initial Comment: While one is able to get/set slices/items with slice/index notation (mmapi[s:e] or mmapi[s]), one cannot use the function equivalents, mmapi.__setslice__(), etc. This seems to be a bug, as nearly all other instances produced by the Python standard library allow instance.[special operator]() to be used. If I knew what was necessary to expose the function equivalents, I would offer a patch. Being that I don't, I won't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087735&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:09:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:09:25 2004 Subject: [ python-Bugs-1087737 ] Mac: make frameworkinstall skips docs, scripts Message-ID: Bugs item #1087737, was opened at 2004-12-19 01:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mac: make frameworkinstall skips docs, scripts Initial Comment: "make frameworkinstall" for a framework build of Python installs a symlink to the interpreter in /usr/local, but it doesn't do the same for the man page, scripts and maybe other auxiliary files. Either it needs to install these, or it needs to be documented that they aren't installed, preferably with an option to install them with an extra make. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:16:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:16:57 2004 Subject: [ python-Feature Requests-1087741 ] subclassable mmap Message-ID: Feature Requests item #1087741, was opened at 2004-12-18 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: subclassable mmap Initial Comment: As the subject says, it would be nice if mmaps were subclassable...like nearly every other Python object type. Note that pseudo-subclasses (copying the instance methods to a different class (not necessarily of the same type) instance) don't work completely due to python.org/sf/1087735 , and is probably a Python "anti-pattern". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087741&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:21:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:21:30 2004 Subject: [ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: Bugs item #763708, was opened at 2003-07-01 08:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Later Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools for --enable-unicode=ucs4 Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-12-19 01:21 Message: Logged In: YES user_id=45365 I'd like to keep this bug open, because the underlying problem is serious: the Python interfaces to the MacOSX APIs assume that the binary representation of "python unicode" is identical to the binary representation of "macosx unicode". This needs to be fixed at some point, but such a fix requires major surgery (especially if we want things to be efficient for the normal case, where the assumption indeed holds). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 22:40 Message: Logged In: YES user_id=357491 This test still fails in 2.4 and so far in 2.5 . Does this still deserve a "later" resolution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 23:27 Message: Logged In: YES user_id=357491 Sorry, Jack. I didn't know that this was a Unicode issue. Oh well, at least the cause has been narrowed down. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 21:35 Message: Logged In: YES user_id=45365 Boo, hiss! :-) You're using --enable-unicode=ucs4 and you didn't tell me that when there's a unicode problem:-) My guess is that I'm somewhere grabbing the pointer from the Python unicode object and passing that straight to the Apple routines, which will fail miserably because they expect ucs2 (or utf16, or whatever it's called). Actually, I wouldn't be surprised if there are more places where I do that. Yes, looking at the data returned this looks like a very likely scenario. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 20:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 17:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 08:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-20 02:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 22:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 13:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:22:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:22:06 2004 Subject: [ python-Bugs-1083645 ] Tests fail instead of skip Message-ID: Bugs item #1083645, was opened at 2004-12-12 00:06 Message generated for change (Comment added) made by dvch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 Category: Build Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Detlef Vollmann (dvch) Assigned to: Nobody/Anonymous (nobody) Summary: Tests fail instead of skip Initial Comment: On Linux, with threads disabled (--with-threads=no), the tests test_imp, test_list and test_userlist fail instead of skipping. ---------------------------------------------------------------------- >Comment By: Detlef Vollmann (dvch) Date: 2004-12-19 01:22 Message: Logged In: YES user_id=729909 I just tested the patch and it works fine: it correcly skips test_imp :-) Thanks Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 22:10 Message: Logged In: YES user_id=357491 test_imp is now skipped on platforms that don't have threading. Covered by rev. 1.5 in HEAD, rev. 1.4.14.1 for 2.4, and rev. 1.4.10.1 for 2.3 . This takes care of all the reported tests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 20:41 Message: Logged In: YES user_id=80475 Applied the decimal fixup. It is no longer dependent on threads. See Lib/decimal.py 1.32 and 1.31.2.1 Am unassigning myself for the rest. It's not an especially high priority to teach regrtest.py about tests that should be skipped when there are no threads. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 17:04 Message: Logged In: YES user_id=729909 test_list and test_userlist succeed now, great, thanks. test_imp still fails as before :-( Detlef ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-18 15:34 Message: Logged In: YES user_id=80475 Please try out the attached patch and let me know if the full test_suite passes. ---------------------------------------------------------------------- Comment By: Detlef Vollmann (dvch) Date: 2004-12-18 12:48 Message: Logged In: YES user_id=729909 Sorry, from the short output of 'make test' the problem seemed obvious: test_imp test test_imp failed -- expected imp.lock_held() to be True ... test_list ImportError: No module named thread ... test_userlist ImportError: No module named thread But after running the tests manually, I noticed that the latter two tests are complete test packs. The complete output is attached. Detlef ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-18 05:33 Message: Logged In: YES user_id=357491 Can you run these tests individually and save the output to see how they are failing? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083645&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:34:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:35:07 2004 Subject: [ python-Bugs-683938 ] HTMLParser attribute parsing bug Message-ID: Bugs item #683938, was opened at 2003-02-10 06:57 Message generated for change (Comment added) made by titus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683938&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser attribute parsing bug Initial Comment: HTMLParser (reportedly) fails to parse this construct: <a href="http://ss"title="pe">P</a> (Note that a required space between the two attributes of the "a" tag has been omitted). The W3C validator appearantly treats this differently, so there's no point in arguing the letter of the law. Assigned to me. ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-18 16:34 Message: Logged In: YES user_id=23486 In response to rdmurray's comment: in Python 2.4, at least, an exception is raised. Not sure why this bug is being kept open... but see bug 736428 and patch 755660 for related issues. ---------------------------------------------------------------------- Comment By: R. David Murray (rdmurray) Date: 2004-03-10 20:53 Message: Logged In: YES user_id=100308 I'm using python 2.3.3. I note that bug 699079, which addresses this same issue, was closed as "not a bug". As far as I can tell the current behavior of HTMLParser, unlike what was reported in that bug report, is to silently stop parsing. This is a problem, as it took me quite a while to track down why my application wasn't working, whereas if an exception had been generated I'd have figured it out right quick. If it's going to stop parsing when the error occurs, then I'd much rather it generate an exception. I can always trap the exception if I want to keep going. Since it apparently used to work that way, I'm hoping maybe a quick poke through CVS by someone knowledgeable with the code can restore the excption behavior, pending a more satisfactory resolution to the problem. ---------------------------------------------------------------------- Comment By: Steven Rosenthal (smroid) Date: 2003-05-13 22:12 Message: Logged In: YES user_id=159908 Two troublesome input examples: <table border=0 width="100%"cellspacing=0 cellpadding=0> <option selected value=> Here's a fix I came up with in HTMLParser.py: replace the definition of locatestarttagend with: locatestarttagend = re.compile(r""" <[a-zA-Z][-.a-zA-Z0-9:_]* # tag name \s* # whitespace after tag name (?: (?:[a-zA-Z_][-.:a-zA-Z0-9_]* # attribute name (?:\s*=\s* # value indicator (?:'[^']*' # LITA-enclosed value |\"[^\"]*\" # LIT-enclosed value |[^'\">\s]+ # bare value )? )? ) \s* # whitespace between attrs )* \s* # trailing whitespace """, re.VERBOSE) ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2003-03-31 02:44 Message: Logged In: YES user_id=9205 HTMLParser (and lots of other parsers I tried) has definitely limits when it comes to error recovering. I dont know if its good to put further development effort in HTMLParser as it will IMHO never reach the ability to cope with all the crappy HTML out there. If you really want to have a html parser in Python, I suggest you look at my htmlsax module packaged with linkchecker (linkchecker.sf.net) and webcleaner (webcleaner.sf.net), the parser is tested with lots of real world examples. The parser packaged with linkchecker has line counting, the one with webcleaner not. Cheers, Bastian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=683938&group_id=5470 From noreply at sourceforge.net Sun Dec 19 01:44:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 01:44:51 2004 Subject: [ python-Feature Requests-1043134 ] mimetypes.guess_extension('text/plain') == '.ksh' ??? Message-ID: Feature Requests item #1043134, was opened at 2004-10-08 08:44 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043134&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes.guess_extension('text/plain') == '.ksh' ??? Initial Comment: Instead of returning the first in the list of extensions it should return the most reasonable . here: to have a *.txt on disk after saveing? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-18 16:44 Message: Logged In: YES user_id=341410 While I agree with the original poster that returning '.txt' is preferable to the others in the list returned by mimetypes.guess_all_extensions() at least 9 times out of 10, being able to prioritize all of the types is not necessarily the easiest thing to do for all of the possible returned lists. Is using a custom comparison function along with the list returned by guess_all_extensions() sufficient? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-11 13:15 Message: Logged In: YES user_id=469548 common_types is for adding some non-standard types, not for determining which extension is most reasonable. I'll be happy to look at a decent patch, but I'm moving this to feature request until then. ---------------------------------------------------------------------- Comment By: Robert Kiendl (kxroberto) Date: 2004-10-10 01:44 Message: Logged In: YES user_id=972995 in mimetypes.py there is already a common_types = { '.jpg' : 'image/jpg', ... .txt could be added, mayby guess_extension should first reverse-take it out of there, not random ...? background: my intent was to save MIME attachment as (startable) temporary file. yet got wonderful .ksh's for textfiles, and had to fumble ... ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-09 08:26 Message: Logged In: YES user_id=469548 How would you suggest finding out what the most reasonable extension for a mime type is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043134&group_id=5470 From noreply at sourceforge.net Sun Dec 19 04:10:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 04:10:54 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 00:24 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-18 21:10 Message: Logged In: YES user_id=2772 If this is all accidental behavior, maybe something (marshal? the compiler?) could issue a warning when a special value is parsed, or marshal.dump()'d. Imagining something like: >>> 2e308 :1: OverflowWarning: behavior of special floating-point value undefined. inf Or else: >>> marshal.dumps(2e308) :1: RuntimeWarning: marshal of special floating-point value undefined. 's\x05\x00\x00\x002e308' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 11:33 Message: Logged In: YES user_id=31435 BTW, while nothing is guaranteed here, your best shot at working (albeit still by accident) portable code is to use expressions that don't tickle IEEE special values directly. For example, use pinf = 1e300 * 1e300 minf = -pinf nan = pinf - pinf That will work the same way from .py or .pyc. Whether pinf is actually +Infinity and nan is actually a NaN then remain platform-dependent accidents, but they will be on the majority platforms (Linux and Windows, using gcc or MSVC to compile Python). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 11:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-07 08:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 07:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 01:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Sun Dec 19 04:25:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 04:25:59 2004 Subject: [ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin Message-ID: Bugs item #1084766, was opened at 2004-12-13 17:41 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-18 21:25 Message: Logged In: YES user_id=2772 Duplicated here on a stale CVS version of 2.4. Here's some information from gdb: Starting program: /usr/src/cvs/python/dist/src/python -S -c '' < / [Thread debugging using libthread_db enabled] [New Thread -151074304 (LWP 6154)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074304 (LWP 6154)] 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 549 Py_INCREF(value); (gdb) where #0 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 #1 0x08075e13 in PyDict_SetItemString (v=0xf6fae79c, key=0x8109d60 "stdin", item=0x0) at Objects/dictobject.c:1988 #2 0x080d6988 in _PySys_Init () at Python/sysmodule.c:961 #3 0x080d3e17 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:190 #4 0x080d5815 in Py_Initialize () at Python/pythonrun.c:283 #5 0x08055159 in Py_Main (argc=4, argv=0xfefac1b4) at Modules/main.c:418 #6 0x08054e0f in main (argc=4, argv=0xfefac1b4) at Modules/python.c:23 The problem seems to be that PyFile_FromFile() returns NULL without tripping the PyErr_Occurred() test on my line 946 of sysmodule.c, because the call to fill_file_fields() returns NULL too. It looks like fill_file_fields is supposed to return NULL with an error set, but when dircheck() is called that early, PyExc_IOError is NULL, so no error is set. Maybe _PyExc_Init() must be moved earlier in startup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 From noreply at sourceforge.net Sun Dec 19 05:19:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 05:19:49 2004 Subject: [ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4) Message-ID: Bugs item #1075703, was opened at 2004-11-29 20:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 Category: Threads >Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Andi Vajda (andivajda) Assigned to: Nobody/Anonymous (nobody) Summary: PyGILState_Ensure() deadlocks (ver 2.4) Initial Comment: PyLucene (http://pylucene.osafoundation.org) wraps libgcj with python. Python objects are also wrapped by java objects. The ref count of the python is incremented in the wrapping java object constructor and is decremented in the wrapping java object's finalize() method. Yes, finalize() is not a reliable means of cleaning memory up but, so far, I wasn't able to figure out a better way to do this. The finalize() method runs in its own libgcj finalizer thread. It has to acquire the GIL before it can call Py_DECREF() is my understanding. The java finalize() calls this code in PyLucene: void finalizeObject(PyObject *object) { #if PY_VERSION_HEX >= 0x02040000 PyGILState_STATE state = PyGILState_Ensure(); Py_DECREF(object); PyGILState_Release(state); #endif } When compiled with python 2.4c1, this mostly works. Except that it deadlocks, every now and then. If I comment this code out, no deadlock. I also verified that the finalizer is called at most once per such object. I realize that reproducing this bug maybe hard, building PyLucene is not particularly easy, unless you have gcj ready. If you contact me, I'm more than willing to help in providing all that's needed to reproduce this. I've seen the deadlock on Mac OS X 10.3.6, my main development OS. For what it's worth, I also tried this with python 2.3.4 (including threadmodule.c patch made in September, related to GIL function usage). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-18 23:19 Message: Logged In: YES user_id=31435 Changed Group to 3rdParty. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-05 05:35 Message: Logged In: YES user_id=6656 Speaking as a Python developer, phew :) ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-04 23:15 Message: Logged In: YES user_id=1139346 I finally tracked down this bug to gcj bug 16478 which is fixed in gcj version >= 3.4.2. I am hence closing this python bug as invalid. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-03 22:42 Message: Logged In: YES user_id=1139346 I've been running the same test loop on Gentoo/2.6/python 2.4 and was not able to get it to deadlock so far. This bug could be limited to Mac OS X. ---------------------------------------------------------------------- Comment By: Andi Vajda (andivajda) Date: 2004-12-03 22:10 Message: Logged In: YES user_id=1139346 I verified this now with python 2.4 final. It still happens as tested on Mac OS X. I was also able to narrow it down to a unit test, that when run repeatedly will eventually lock up. It is attached. If you need assistance building PyLucene from sources, or want me to provide a binary, let me know. At the moment, to reproduce this bug, it is best to build PyLucene from subversion. See http://pylucene.osafoundation.org for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470 From noreply at sourceforge.net Sun Dec 19 07:19:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 07:19:35 2004 Subject: [ python-Bugs-778804 ] CGIHTTPServer cannot manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 02:00 Message generated for change (Comment added) made by titus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Eric S. Raymond (esr) Summary: CGIHTTPServer cannot manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-18 22:19 Message: Logged In: YES user_id=23486 same as bug 737202, which has an attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 10:06 Message: Logged In: YES user_id=80475 Eric, this was your change (2/9/2001). Will you take it from here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply at sourceforge.net Sun Dec 19 07:20:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 07:20:17 2004 Subject: [ python-Bugs-737202 ] CGIHTTPServer does not handle scripts in sub-dirs Message-ID: Bugs item #737202, was opened at 2003-05-13 10:54 Message generated for change (Comment added) made by titus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer does not handle scripts in sub-dirs Initial Comment: CGIHTTPServer does not handle scripts in sub directoreis correctly: When accessing eg. '/cgi-bin/scripts/bla', CGIHTTPServer returns 404 CGI script is not a plain file ('/cgi-bin/script') This tracked down to CGIHTTPRequestHandler.run_cgi() containing these lines: i = rest.find('/') if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script This will move the dir-part of the 'rest' into 'script', but leave the actual filename in 'rest'. The 'scriptname' thus does miss the filename. I assume this should become simply: script, rest = rest, '' scriptname = dir + '/' + script ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-18 22:20 Message: Logged In: YES user_id=23486 same as bug 778804, assigned to esr. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2003-05-23 06:21 Message: Logged In: YES user_id=376953 I rethought this: The reason for this type of split is to make it possible to pass parameters as part of the URL, like Zope does. So the snippet above should be changed to something like this: i = 0 while 1: # get the next path-element out of the url i = rest.find('/', i) if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translatepath(scriptname) if os.isdir(scriptname): # if scriptname is a directory, continue "walking" the url continue # scriptname is not a directory, stop "walking" the url break Patch is included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737202&group_id=5470 From noreply at sourceforge.net Sun Dec 19 17:35:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 17:35:41 2004 Subject: [ python-Bugs-1087975 ] example code not working Message-ID: Bugs item #1087975, was opened at 2004-12-19 17:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087975&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: perica (zivkovicperica) Assigned to: Nobody/Anonymous (nobody) Summary: example code not working Initial Comment: in chapter "9.11 Generator Expressions" in "Python Tutorial" this example is not working: >>> sum(i*i for i in range(10)) # sum of squares 285 I'm using Python 2.3.4 (GCC 3.4.2) on FreeBSD 5.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087975&group_id=5470 From noreply at sourceforge.net Sun Dec 19 17:35:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 17:35:47 2004 Subject: [ python-Bugs-1080440 ] float issue for NaN type in .pyc file Message-ID: Bugs item #1080440, was opened at 2004-12-07 06:24 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: float issue for NaN type in .pyc file Initial Comment: There is a difference in output between .pyc and .py file, while dealing with NaN float. In fact I am doing a float range validation as part of my requirement. The content of my sample program [test.py] aboveMax = 1.8e+308 belowMin = -1.8e+308 print aboveMax, belowMin While execution: command: python test.py output: 1.#INF -1.#INF This output is expected and good, however if I use compiled python file as below, command: python test.pyc output: 1.0 -1.0 This output is wrong, it does not show Nan floating point. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-19 16:35 Message: Logged In: YES user_id=6656 And, er, how do you do that? AFAIK, isnan is in SUS and C99 and recommended by IEEE-754 but isn't in plain old ANSI C... I also suspect that it's supported by all platforms we care about that, but certainly wouldn't swear to it. OTOH, pyport.h seems to have a Py_IS_NAN macro already. Maybe that would work, at least enough of the time to be useful... ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-19 03:10 Message: Logged In: YES user_id=2772 If this is all accidental behavior, maybe something (marshal? the compiler?) could issue a warning when a special value is parsed, or marshal.dump()'d. Imagining something like: >>> 2e308 :1: OverflowWarning: behavior of special floating-point value undefined. inf Or else: >>> marshal.dumps(2e308) :1: RuntimeWarning: marshal of special floating-point value undefined. 's\x05\x00\x00\x002e308' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 17:33 Message: Logged In: YES user_id=31435 BTW, while nothing is guaranteed here, your best shot at working (albeit still by accident) portable code is to use expressions that don't tickle IEEE special values directly. For example, use pinf = 1e300 * 1e300 minf = -pinf nan = pinf - pinf That will work the same way from .py or .pyc. Whether pinf is actually +Infinity and nan is actually a NaN then remain platform-dependent accidents, but they will be on the majority platforms (Linux and Windows, using gcc or MSVC to compile Python). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 17:13 Message: Logged In: YES user_id=31435 dileep_nirala: Yes, I understood the problem. That your test passed the first time was an accident. That your test failed the second time was also an accident. Nothing is defined about what happens in Python in the presence of NaNs. The most likely accident is that no spelling of an infinity, NaN, or negative 0.0 will survive when loaded from a .pyc file. That the literal "1.8e+308" gave you an infinity to begin with was also a platform-dependent accident. Python has no support for these things. Whatever support may *appear* to exist derives from more-or-less random behaviors dervied from the platform C compiler and runtime libraries. That won't be fixed unless someone unexpectedly volunteers a lot of new work in this area. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-07 14:51 Message: Logged In: YES user_id=6656 I know first hand how much of a pain this issue can be. However it's not clear what can be done about it. My vote would go towards complaining at compile time that the literals cannot be represented as a regular double, but even that isn't the easiest thing to do portably! ---------------------------------------------------------------------- Comment By: Dileep Nirala (dileep_nirala) Date: 2004-12-07 13:54 Message: Logged In: YES user_id=1173293 My test cases passes for the first time but fails second times onward since .pyc gets loaded since it's existing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-07 07:51 Message: Logged In: YES user_id=31435 Python guarantees nothing about behavior in the presence of NaNs, infinities, or signed zeroes. Anything you see then is a platform-dependent accident. This should be closed with a reference to PEP 42 (I don't have time to look it all up now -- "non-accidental" IEEE behavior is a longstanding feature request, but one unlikely to be resolved in the foreseeable future; the particular problem here is that the marshal format deals in accidental ways with infinities, NaNs, and signed zeroes, so accidents in .py files may not be reproduced from .pyc files) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080440&group_id=5470 From noreply at sourceforge.net Sun Dec 19 17:41:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 17:47:41 2004 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-16 18:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-19 16:41 Message: Logged In: YES user_id=6656 Do you want to fix it then? :) I can't imagine it's that hard, but it would be easier for someone who can test that their fix helps... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-18 10:45 Message: Logged In: YES user_id=671362 FYI, I can reproduce this with : - Python 2.4 & readline 4.3 under SuSE 9.1 - Python 2.5(snapshot as of 2004-12-17) & readline 4.3 under SuSE 9.1 - Python 2.4 & readline 4.3.5(?) under Cygwin ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-17 14:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Sun Dec 19 19:07:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 19:07:31 2004 Subject: [ python-Bugs-818315 ] Shared object modules in Windows have no __file__. Message-ID: Bugs item #818315, was opened at 2003-10-05 23:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818315&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Shared object modules in Windows have no __file__. Initial Comment: The subject basically says it. Whether it's math.so, operator.so, anything -- in *nix it has an __file__, in Windows it doesn't. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-19 19:07 Message: Logged In: YES user_id=21627 It's as alanmcintyre says: math is not a shared object in Windows. Closing this as invalid. ---------------------------------------------------------------------- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2004-11-06 21:19 Message: Logged In: YES user_id=1115903 In the case of the math module, I would assume that it doesn't have a __file__ attribute on Windows because it's a builtin and is rolled up into python2x.dll in the Windows distribution. This seems to match up with the 2.3 codumentation: "The __file__ attribute is not present for C modules that are statically linked into the interpreter; for extension modules loaded dynamically from a shared library, it is the pathname of the shared library file." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818315&group_id=5470 From noreply at sourceforge.net Sun Dec 19 19:09:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 19:09:58 2004 Subject: [ python-Bugs-793078 ] Easier-to-create alternative Python installer for Windows Message-ID: Bugs item #793078, was opened at 2003-08-22 12:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793078&group_id=5470 Category: Installation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Easier-to-create alternative Python installer for Windows Initial Comment: It is unfortunate that the standard Python installer requires proprietrary products (Wise) to build on Windows. It makes it difficult to recreate a Python installer for those who want a custom installer. While I appreciate the nice installer donated by Wise (http://starship.python.net/crew/mhammond/wise/wise.html) it would be great if there was a simpler solution. The ultimate solution would be to use the distutils setup to create an installer. It doesn't have to look as nice as the Wise one, as long as it can be created using all Open-source tools. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-19 19:09 Message: Logged In: YES user_id=21627 This bug is fixed in 2.4, which only requires Python (+pythonwin) to build the installer. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-08-25 09:42 Message: Logged In: YES user_id=11105 There *is* already a src\PCBuild\python.iss file, comments about what needs to be done are at the top of the file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-23 05:35 Message: Logged In: YES user_id=44345 I'm sure if you contributed an InnoSetup installer file it would be accepted. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793078&group_id=5470 From noreply at sourceforge.net Sun Dec 19 19:27:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 19:27:09 2004 Subject: [ python-Bugs-1087975 ] example code not working Message-ID: Bugs item #1087975, was opened at 2004-12-19 11:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087975&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: perica (zivkovicperica) Assigned to: Nobody/Anonymous (nobody) Summary: example code not working Initial Comment: in chapter "9.11 Generator Expressions" in "Python Tutorial" this example is not working: >>> sum(i*i for i in range(10)) # sum of squares 285 I'm using Python 2.3.4 (GCC 3.4.2) on FreeBSD 5.3 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 13:27 Message: Logged In: YES user_id=80475 It looks like you have a Python 2.4 tutorial in-hand but are working with an old version of python, 2.3.4 which did not have generator expressions. Here is a link to the tutorial that matches the version on your system (note it does not have a section 9.11): http://www.python.org/doc/2.3.4/tut/tut.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087975&group_id=5470 From noreply at sourceforge.net Sun Dec 19 20:31:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 20:31:21 2004 Subject: [ python-Bugs-1088039 ] CGIHTTPServer: directories/scripts with spaces in their name Message-ID: Bugs item #1088039, was opened at 2004-12-19 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088039&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: LT (sweetleon) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer: directories/scripts with spaces in their name Initial Comment: It looks like we're not properly quoting the path the script, and when the script or its directory has a space in its name - quite common on Windoze - it doesn't work. Here's the output: host - - [19/Dec/2004 11:07:01] command: C:\Python24\python.exe -u c:\Documents a nd Settings\User\My Documents\project\cgi-bin\webpage.py "" host - - [19/Dec/2004 11:07:01] C:\Python24\python.exe: can't open file 'c:\Docum ents': [Errno 2] No such file or directory ibm - - [19/Dec/2004 11:07:02] CGI script exit status 0x2 ibm - - [19/Dec/2004 11:07:02] code 404, message File not found ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088039&group_id=5470 From noreply at sourceforge.net Sun Dec 19 21:09:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 21:09:46 2004 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 10:29 Message generated for change (Comment added) made by yenzenz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- Comment By: Jens Klein (yenzenz) Date: 2004-12-19 21:09 Message: Logged In: YES user_id=474612 seems its a bit more difficult: encoding 'macintosh is registered by iana[1] (nice formatted in [2]) and is covered by RFC1345[3]. Name: macintosh [RFC1345,KXS2] MIBenum: 2027 Source: The Unicode Standard ver1.0, ISBN 0-201-56788-1, Oct 1991 Alias: mac Alias: csMacintosh [1]http://www.iana.org/assignments/character-sets [2]http://www.cs.tut.fi/~jkorpela/chars/sorted.html [3]http://www.faqs.org/rfcs/rfc1345.html so far the hard facts from specification view. in all these specs are mac_roman etc. not mentioned. So what? I found at [4] with the popular program 'recode' a hint of the alias. the aothor there uses the iana registered macintosh as an alias for mac_roman: DEFENCODING(( "MacRoman", /* JDK 1.1 */ /* This is the best table for MACINTOSH. The ones */ /* in glibc and FreeBSD-iconv are bad quality. */ "MACINTOSH", /* IANA */ "MAC", /* IANA */ "csMacintosh", /* IANA */ ), mac_roman, { mac_roman_mbtowc }, { mac_roman_wctomb, NULL }) [4]http://recode.progiciels-bpi.ca/showfile.html?name=fusion/recode-3.6/ libiconv/encodings.def Because of that (I trust recode somehow) i would propose to add macintosh as an alias for mac_roman. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-19 00:01 Message: Logged In: YES user_id=38388 I have no problem adding aliases to the encodings package, but please provide some reference that this actually is a valid alias for the mac_roman encoding. There are quite a few other mac_* encodings to choose from as well, so the coice is not obvious to me. ---------------------------------------------------------------------- Comment By: Jens Klein (yenzenz) Date: 2004-12-18 23:49 Message: Logged In: YES user_id=474612 +1 from me Archetypes (a Zope framework) runs also in a problem because of the missing alias. more infos: https://sourceforge.net/tracker/index.php? func=detail&aid=1068001&group_id=75272&atid=543430 ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-17 11:47 Message: Logged In: YES user_id=46639 The test was just a sequence of random high-bit characters: ?????????????? (lets see if the web interface lets that through). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-17 11:12 Message: Logged In: YES user_id=38388 Are you sure ? The decoded string you give does not look like anything readable... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Sun Dec 19 21:17:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 21:17:20 2004 Subject: [ python-Bugs-1087216 ] datetime module documentation missing critical detail Message-ID: Bugs item #1087216, was opened at 2004-12-17 14:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime module documentation missing critical detail Initial Comment: The datetime documentation - both pydoc and the manual - fail to specify the arguments used to create a date/time/datetime object. The manual implies that for date it's date(year, month, day), but that's about it. It would be nice if both could be extended to include examples. For date, say: datetime.date(2004, 12, 25) - create a date object for christmas, 2004. I can't give examples for time and datetime, because I'm not sure what the format is. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 15:17 Message: Logged In: YES user_id=80475 Added slightly more informative docstrings for date, time, and datetime. See Modules/datetimemodule.c 1.76 and 1.75.2.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-17 17:28 Message: Logged In: YES user_id=80475 It looks like the docstrings could be a bit more informative: >>> print datetime.date.__doc__ Basic date type. Compare that with: >>> print collections.deque.__doc__ deque(iterable) --> deque object Build an ordered collection accessible from endpoints only. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-12-17 16:05 Message: Logged In: YES user_id=44345 Pydoc generates documentation based upon what it finds in docstrings and function signatures. It can't get at the signatures of functions written in C. In Python 2.4 pydoc generates a link to a local or online version of the docs for the subject module: NAME datetime - Fast implementation of the datetime type. FILE /Users/skip/local/lib/python2.5/lib-dynload/datetime.so MODULE DOCS http://www.python.org/doc/current/lib/module-datetime.html CLASSES __builtin__.object date datetime ... I think that's the best that can be done short of macroizing the hell out of C extension modules to allow function signatures to be captured as attributes attached to the functions, similar to what GNU Emacs did many years ago. Correct me if I'm wrong, but I don't think we want to go down that path (take a peek at the Emacs source if you are in doubt). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2004-12-17 15:23 Message: Logged In: YES user_id=93910 You're right - I was just blind when reading the module documenation. It would still be nice if I could get that information from pydoc/help, though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-17 14:56 Message: Logged In: YES user_id=31435 I'm not sure which docs you're looking at. I'm looking at the Python docs , like here: http://docs.python.org/lib/datetime-date.html That seems very clear to me: """ class date(year, month, day) All arguments are required. Arguments may be ints or longs, in the following ranges: MINYEAR <= year <= MAXYEAR 1 <= month <= 12 1 <= day <= number of days in the given month and year If an argument outside those ranges is given, ValueError is raised. """ There are equally precise docs for all the datetime.* classes. For example, you mentioned time: """ class time(hour[, minute[, second[, microsecond[, tzinfo]]]]) All arguments are optional. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges: 0 <= hour < 24 0 <= minute < 60 0 <= second < 60 0 <= microsecond < 1000000. If an argument outside those ranges is given, ValueError is raised. All default to 0 except tzinfo, which defaults to None. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087216&group_id=5470 From noreply at sourceforge.net Sun Dec 19 21:20:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 21:21:54 2004 Subject: [ python-Bugs-1081824 ] Rewrite of docs for compiler.visitor Message-ID: Bugs item #1081824, was opened at 2004-12-08 21:06 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) >Assigned to: Jeremy Hylton (jhylton) Summary: Rewrite of docs for compiler.visitor Initial Comment: I was recently prompted to look at the docs for compiler.visitor (Lib Ref 19.4 Using Visitors to Walk ASTs). With all due respect it is not up to the standards of most of the docs. I have attempted a rewrite which is in the attachment. I suggest also that the entry for walk() on the main compiler doc page (19.1) should be updated to refer to 19.4 for details. HTH Kent ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470 From noreply at sourceforge.net Sun Dec 19 21:33:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 21:33:24 2004 Subject: [ python-Bugs-1066607 ] "Limitations" section of profiler docs is incorrect Message-ID: Bugs item #1066607, was opened at 2004-11-15 06:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066607&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: "Limitations" section of profiler docs is incorrect Initial Comment: >From the Python 2.4 What's New: "The profile module can now profile C extension functions." The "Limitations" section of the profiler documentation still indicates that time spent in C functions is assigned to the calling Python function. Thanks to Nick Bastin's work, this is no longer the case. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 15:33 Message: Logged In: YES user_id=80475 Fixed. See Doc/libprofile.tex 1.50 and 1.48.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066607&group_id=5470 From noreply at sourceforge.net Sun Dec 19 21:47:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 21:48:04 2004 Subject: [ python-Bugs-1079011 ] Incorrect error message (somewhat) Message-ID: Bugs item #1079011, was opened at 2004-12-04 14:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect error message (somewhat) Initial Comment: Comparing complex numbers with cmp yields: >>> cmp(1+3j, 1+3j) 0 >>> cmp(1+3j, 3+4j) Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= Well, I didn't use <, <=, > or >=. It's not a major bug, but it doesn't look too nice... would it be possible to return NotImplemented? Or would that be semantically incorrect? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 15:47 Message: Logged In: YES user_id=80475 Rewrote the error message. See Objects/complexobject.c 2.73 and 2.72.2.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:31 Message: Logged In: YES user_id=80475 That is incorrect be == and != are implemented. The message is slightly weird but still helpful. Any rewording I can think of makes the message more obtuse, so I recommend leaving it alone and closing this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:07:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:07:40 2004 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 14:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:09:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:09:15 2004 Subject: [ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin Message-ID: Bugs item #1084766, was opened at 2004-12-13 18:41 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 21] Is a directory ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-12-18 22:25 Message: Logged In: YES user_id=2772 Duplicated here on a stale CVS version of 2.4. Here's some information from gdb: Starting program: /usr/src/cvs/python/dist/src/python -S -c '' < / [Thread debugging using libthread_db enabled] [New Thread -151074304 (LWP 6154)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074304 (LWP 6154)] 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 549 Py_INCREF(value); (gdb) where #0 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 #1 0x08075e13 in PyDict_SetItemString (v=0xf6fae79c, key=0x8109d60 "stdin", item=0x0) at Objects/dictobject.c:1988 #2 0x080d6988 in _PySys_Init () at Python/sysmodule.c:961 #3 0x080d3e17 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:190 #4 0x080d5815 in Py_Initialize () at Python/pythonrun.c:283 #5 0x08055159 in Py_Main (argc=4, argv=0xfefac1b4) at Modules/main.c:418 #6 0x08054e0f in main (argc=4, argv=0xfefac1b4) at Modules/python.c:23 The problem seems to be that PyFile_FromFile() returns NULL without tripping the PyErr_Occurred() test on my line 946 of sysmodule.c, because the call to fill_file_fields() returns NULL too. It looks like fill_file_fields is supposed to return NULL with an error set, but when dircheck() is called that early, PyExc_IOError is NULL, so no error is set. Maybe _PyExc_Init() must be moved earlier in startup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1084766&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:24:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:24:29 2004 Subject: [ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the terminal mode. Message-ID: Bugs item #1088077, was opened at 2004-12-19 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] tty needs a way to restore the terminal mode. Initial Comment: tty provides a nice, simple interface for setting the terminal to raw or cbreak modes. However, it doesn't provide a way to put the terminal back in the mode it was in before that change. Every responsible application should leave the terminal in the mode it found it in - unless the application is called sttty, of course. tty needs a "setsane" function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:28:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:28:31 2004 Subject: [ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the terminal mode. Message-ID: Bugs item #1088077, was opened at 2004-12-19 15:24 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] tty needs a way to restore the terminal mode. Initial Comment: tty provides a nice, simple interface for setting the terminal to raw or cbreak modes. However, it doesn't provide a way to put the terminal back in the mode it was in before that change. Every responsible application should leave the terminal in the mode it found it in - unless the application is called sttty, of course. tty needs a "setsane" function. ---------------------------------------------------------------------- >Comment By: Mike Meyer (mwm) Date: 2004-12-19 15:28 Message: Logged In: YES user_id=93910 The patch to add the setsane method is in patch #1088078. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088077&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:35:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:35:54 2004 Subject: [ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info Message-ID: Bugs item #1085300, was opened at 2004-12-14 13:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walrus (unclewalrus) >Assigned to: Brett Cannon (bcannon) Summary: Mac Library Modules 1.1.1 Bad Info Initial Comment: Document states that OS X's TextEdit only saves RTF files. This is incorrect; you can make a plaintext file by choosing 'Make Plain Text' from the Format menu. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:35 Message: Logged In: YES user_id=80475 Brett, can you verify this and, if true, add an appropriate note to the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:38:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:39:04 2004 Subject: [ python-Bugs-1076819 ] test_shelve failures Message-ID: Bugs item #1076819, was opened at 2004-12-01 10:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: ====================================================================== FAIL: test_read (__main__.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestBinaryFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestProto2FileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:38 Message: Logged In: YES user_id=80475 Works for me on WinME and WinXP. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 03:53 Message: Logged In: YES user_id=250749 Test works for me on FreeBSD 4.8. Make sure that you can use anydbm - more details on what db module is actually invoked by anydbm might help shed some more light on the matter (use the file utility on a database created with anydbm.open()). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 10:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:44:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:44:54 2004 Subject: [ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off Message-ID: Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rick Graves (netvigator) >Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 From noreply at sourceforge.net Sun Dec 19 22:47:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 22:47:13 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 18:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) >Assigned to: Tim Peters (tim_one) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 19:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-06 18:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 18:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 04:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 05:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 05:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:04:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:05:05 2004 Subject: [ python-Bugs-1072410 ] mkarg undocumented Message-ID: Bugs item #1072410, was opened at 2004-11-24 07:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072410&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gunter Ohrner (interneci) Assigned to: Nobody/Anonymous (nobody) Summary: mkarg undocumented Initial Comment: Hi! As far as I can tell, commands.mkarg is completely undocumented in python 2.4rc1, in help(commands) as well as in help(mkarg). It's not even marked as deprecated, neither one is referred to a successing function. Is it a bug or did I miss something obvious? Greetings, Gunter ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:04 Message: Logged In: YES user_id=80475 This is intensionally not part of the API. mkarg() is used by some of the documented functions. mk2arg() is not used at but is being retained incase someone had found it and used it prior to the __all__ variable being added a few years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072410&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:12:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:12:08 2004 Subject: [ python-Bugs-1072853 ] thisid not intialized in pindent.py script Message-ID: Bugs item #1072853, was opened at 2004-11-24 18:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) >Assigned to: Tim Peters (tim_one) Summary: thisid not intialized in pindent.py script Initial Comment: Hi there, I am using python version 2.3.4. For some cases when using pindent.py with -c and -e option as follows, the variable "thisid" does not gets initialized before it hits line #310 ( current, firstkw, lastkw, topid = indent, thiskw, thiskw, thisid), this is traced all the way back to line #268 (for my case it fell in this else clause ... didn't try to look the exact scenario causing this) ... adding thisid = '' help fix the code for my scenario. If this fix is good for all scenario, please roll this over to main line code. Regards, Niraj ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:12 Message: Logged In: YES user_id=80475 Tim, cvs ann says this is your code. ---------------------------------------------------------------------- Comment By: Niraj Bajpai (nbajpai) Date: 2004-11-24 21:50 Message: Logged In: YES user_id=1165734 I am running on solaris-8 and command I used is as follows: pindent.py -c -e This is for some special cases (I do not know, haven't digged into) and does not happen for all the mis-formatted files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:14:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:14:29 2004 Subject: [ python-Bugs-1072642 ] dyld: ./python.exe multiple definitions of symbol _BC Message-ID: Bugs item #1072642, was opened at 2004-11-24 12:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072642&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marius (schamschula) Assigned to: Nobody/Anonymous (nobody) Summary: dyld: ./python.exe multiple definitions of symbol _BC Initial Comment: When installing Python 2.3.4 under Mac OS X 10.3.6 (Darwin 7.6.0) I get the following error: running build running build_ext dyld: ./python.exe multiple definitions of symbol _BC /usr/local/lib/libreadline.5.0.dylib(terminal.so) definition of _BC /usr/lib/libncurses.5.dylib(lib_termcap.o) definition of _BC make: *** [sharedmods] Error 133 Note: as the output states I have readline 5.0 installed. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:14 Message: Logged In: YES user_id=80475 Can this be closed now? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-12-01 22:45 Message: Logged In: YES user_id=139309 Try configuring like this: env MACOSX_DEPLOYMENT_TARGET=10.3 ./configure --enable- framework ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-25 08:23 Message: Logged In: YES user_id=6656 Hum. Is it possible to write a simple C program that links to both readline and ncurses in your setup? From the error messages I would guess not, but that may be too easy. PS: haven't had the courage to go near readline 5 yet :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072642&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:19:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:19:53 2004 Subject: [ python-Bugs-1072182 ] bad arg type to isspace in struct module Message-ID: Bugs item #1072182, was opened at 2004-11-23 18:35 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072182&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg McFarlane (gregm) >Assigned to: Raymond Hettinger (rhettinger) Summary: bad arg type to isspace in struct module Initial Comment: For characters greater than 0x7f, the calls to isspace() in Modules/structmodule.c can return random values. For example, on Solaris I got this (incorrect) output: >>> import struct >>> struct.calcsize('10d\xfed') 88 >>> After changing the three occurrences of "isspace((int)c)" to "isspace((unsigned char)c)", this was the (correct) output: >>> import struct >>> struct.calcsize('10d\xfed') Traceback (most recent call last): File "", line 1, in ? struct.error: bad char in struct format >>> Reason: the '\xfe' is taken as a signed char. The code (int)c converts this to a signed int (-2). The system isspace macro uses this as an index into the __ctype array. The array is only defined for the values 0 to 255 and so -2 is out-of-bounds. The value returned by isspace depends on what happens to be at that location in memory. NOTE: There may be other occurrences of this bug in other parts of the python code. Please check. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2004-11-23 23:52 Message: Logged In: YES user_id=265183 Looking at other instances of isspace and friends, I think this is the point of calling Py_CHARMASK, which is used to "Convert a possibly signed character to a nonnegative int" (depending on whether 'char' is signed or unsigned). In other words, I believe the three instances of isspace((int)c) in Modules/structmodule.c should be changed to isspace(Py_CHARMASK(c)). `grep isspace */*.c | grep -v CHARMASK` suggests some other potential bugs: - Modules/posixmodule.c:466 (os2_formatmsg): isspace(*lastc) - Modules/socketmodule.c:504 (set_error): isspace(*lastc) `egrep 'isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower|isprint|isprint|ispunct|isupper|isxdigit' */*.c | grep -v Py_CHARMASK` suggest the following further bugs: - Modules/_hotshot.c:1431 (get_version_string): isdigit((int)*rev) [unlikely to cause trouble, but wrong in the same way...] - Modules/_tkinter.c:639 (Tkapp_New): isupper((int)argv0[0]) - Modules/pyexpat.c:1800 (get_version_string): isdigit((int)*rev) [again unlikely a problem] - Modules/stropmodule.c:760 (strop_atoi): isalnum((int)end[-1]) ye - Parser/grammar.c:183 (translabel): isalpha((int)(lb->lb_str[1])) - Parser/tokenizer.c:232 (get_coding_spec): isalnum((int)t[0]) - Parser/atof.c:16 (atof): (c = *s++) != '\0' && isdigit(c) [same problem appears three times in the same function] - Python/compile.c:1721,1727 (parsestr): int quote = *s; ... isalpha(quote) - Python/dynload_aix.c:147 (aix_loaderror): isdigit(*message[i]) - Python/getargs.c:141 (vgetargs1): int c = *format++ (and later, isalpha(c)) - Python/getargcs.c:258 (vgetargs1): isalpha((int)(*format)) - Python/getargs.c:336 (converttuple): int c = *format++ (and later, isalpha(c)) - Python/getargs.c:1222 (vgetargskeyword): i = *format++ (and later, isalpha(i)) That's all that I could find. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072182&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:24:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:24:51 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 18:02 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) >Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-19 17:24 Message: Logged In: YES user_id=31435 Sorry, don't care enough to spend time on it (not a bug I've had, not one I expect to have, don't care if it never changes). Suggest not using /dev/full as an output device . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 19:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-06 18:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 18:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 04:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 05:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 05:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:27:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:27:33 2004 Subject: [ python-Bugs-1069409 ] C:\Python24\Lib\compileall.py returns False Message-ID: Bugs item #1069409, was opened at 2004-11-19 09:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069409&group_id=5470 >Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: PieterB (pieterb) >Assigned to: Kurt B. Kaiser (kbk) Summary: C:\Python24\Lib\compileall.py returns False Initial Comment: I tried running compileall.py from IDLE with Python 2.4c1 (WinXP, SP1). I get the following 'error': .... Listing C:\WINDOWS\System32\python24.zip ... Can't list C:\WINDOWS\System32\python24.zip Listing C:\Python24 ... Listing C:\Python24\DLLs ... Listing C:\Python24\lib ... Listing C:\Python24\lib\plat-win ... Can't list C:\Python24\lib\plat-win Listing C:\Python24\lib\lib-tk ... Compiling C:\Python24\lib\lib-tk\Canvas.py ... Compiling C:\Python24\lib\lib-tk\Dialog.py ... Compiling C:\Python24\lib\lib-tk\FileDialog.py ... Compiling C:\Python24\lib\lib-tk\ScrolledText.py ... Compiling C:\Python24\lib\lib-tk\Tix.py ... Compiling C:\Python24\lib\lib-tk\Tkdnd.py ... Compiling C:\Python24\lib\lib-tk\turtle.py ... Traceback (most recent call last): File "C:\Python24\Lib\compileall.py", line 157, in -toplevel- sys.exit(exit_status) SystemExit: False >>> Shouldn't an integer value (e.g. 0) be returned by sys.exit? It's nice that you can see where the script has ended, but I think it's good to be more elaborate that everything went OK. I think some users might think it's strange to get a Traceback when everything is ok. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:27 Message: Logged In: YES user_id=80475 I think this is just a fact of life when using IDLE to run scripts designed for command-line use. The script is question is fine and represents good coding style. The only question is whether IDLE should handle system exits differently. Kurt, please pronounce and close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069409&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:32:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:32:14 2004 Subject: [ python-Bugs-1072853 ] thisid not intialized in pindent.py script Message-ID: Bugs item #1072853, was opened at 2004-11-24 18:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) >Assigned to: Nobody/Anonymous (nobody) Summary: thisid not intialized in pindent.py script Initial Comment: Hi there, I am using python version 2.3.4. For some cases when using pindent.py with -c and -e option as follows, the variable "thisid" does not gets initialized before it hits line #310 ( current, firstkw, lastkw, topid = indent, thiskw, thiskw, thisid), this is traced all the way back to line #268 (for my case it fell in this else clause ... didn't try to look the exact scenario causing this) ... adding thisid = '' help fix the code for my scenario. If this fix is good for all scenario, please roll this over to main line code. Regards, Niraj ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-19 17:32 Message: Logged In: YES user_id=31435 ann says that because rev 1.10 mechanically converted the whole file from tab indents to 4-space indents. I've never looked at this code, and never even used it. I care about reindent.py, but not pindent.py (it's Guido's baby, BTW). Unassigned myself. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:12 Message: Logged In: YES user_id=80475 Tim, cvs ann says this is your code. ---------------------------------------------------------------------- Comment By: Niraj Bajpai (nbajpai) Date: 2004-11-24 21:50 Message: Logged In: YES user_id=1165734 I am running on solaris-8 and command I used is as follows: pindent.py -c -e This is for some special cases (I do not know, haven't digged into) and does not happen for all the mis-formatted files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1072853&group_id=5470 From noreply at sourceforge.net Sun Dec 19 23:45:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 19 23:45:57 2004 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 14:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:45 Message: Logged In: YES user_id=80475 Fred, I had thought you had made a job for this but it doesn't appear to be running on a regular basis. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-19 09:49 Message: Logged In: YES user_id=6656 I'd have thought it was an entirely reasonable use of the starship, but I guess you could ask on the crew list first if you want to be really polite... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 01:39 Message: Logged In: YES user_id=3066 Perhaps that's good enough, though I've generally done updates from the latest CVS. Would anyone object to my setting up a cronjob to perform the build on starship? It appears that sufficient software is installed on that machine to perform the build (and much faster than on anything I have). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-19 01:03 Message: Logged In: YES user_id=21627 For a daily build, it is IMO sufficient to use the anonymous CVS - it may be a few hours behind, but you'ld have to wait a full day anyway for the changes to show up. If somebody builds the documentation elsewhere, a cronjob on python.org could pick it up from "elsewhere", which would mean no access to python.org is necessary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-18 22:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-16 21:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 14:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 13:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Mon Dec 20 00:13:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 00:13:34 2004 Subject: [ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off Message-ID: Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Rejected >Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 18:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 From noreply at sourceforge.net Mon Dec 20 00:38:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 00:38:37 2004 Subject: [ python-Bugs-1074011 ] write failure ignored in Py_Finalize() Message-ID: Bugs item #1074011, was opened at 2004-11-26 23:02 Message generated for change (Comment added) made by wom-work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: write failure ignored in Py_Finalize() Initial Comment: [forwarded from http://bugs.debian.org/283108] Write errors on stdout may be ignored, and hence may result in loss of valuable user data. Here's a quick demo: $ ./close-bug foo $ ./close-bug > /dev/full && echo unreported write failure unreported write failure $ cat close-bug #!/usr/bin/python import sys def main (): try: print 'foo' sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () This particular failure comes from the following unchecked fflush of stdout in pythonrun.c: static void call_ll_exitfuncs(void) { while (nexitfuncs > 0) (*exitfuncs[--nexitfuncs])(); fflush(stdout); fflush(stderr); } Flushing the stream manually, python does raise an exception. Please note that simply adding a test for fflush failure is not sufficient. If you change the above to do this: if (fflush(stdout) != 0) { ...handle error... } It will appear to solve the problem. But here is a counterexample: import sys def main (): try: print "x" * 4095 print sys.stdout.close () except IOError, e: sys.stderr.write ('write failed: %s\n' % e) sys.exit (1) if __name__ == '__main__': main () If you run the above with stdout redirected to /dev/full, it will silently succeed (exit 0) in spite of a write failure. That's what happens on my debian unstable system. Instead of just checking the fflush return value, it should also check ferror: if (fflush(stdout) != 0 || ferror(stdout)) { ...handle error... } ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-19 23:38 Message: Logged In: YES user_id=203860 Tim, these bugs are quite difficult to trigger, but they can hide any kind of file error and lose arbitrarily large amounts of data. Here, the following program will run indefinitely: full = open('/dev/full', 'w') while 1: print >>full, 'x' * 1023 print >>full It seems to be essential that both the character that fills the file buffer (here it is 1024 bytes long) and the next are generated implicitly by print - otherwise the write error will be detected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-19 22:24 Message: Logged In: YES user_id=31435 Sorry, don't care enough to spend time on it (not a bug I've had, not one I expect to have, don't care if it never changes). Suggest not using /dev/full as an output device . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 21:47 Message: Logged In: YES user_id=80475 Tim, what do you think? ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-07 00:33 Message: Logged In: YES user_id=203860 OK, I can reproduce the remaining problem if I substitute 1023 for 4095. The culprit seems to be the unchecked fputs() in PyFile_WriteString, which is used for the spaces and newlines generated by the print statement but not for the objects. I think that's a separate bug. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-06 23:27 Message: Logged In: YES user_id=41497 Even with python-2.4 (built fresh from CVS this morning), I can still reproduce the problem on a Linux-2.6.9/ext3 system: /p/p/python-2.4/bin/python write-4096 > /dev/full && echo fail fail The size that provokes the failure depends on the I/O block size of your system, so you might need something as big as 131072 on some other type of system. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-12-06 23:11 Message: Logged In: YES user_id=203860 The second sample script works for me (in that it raises the expected exception) with or without my patch. If the error status of the file has been set by some other operation without Python noticing it then surely that's a bug in the code that calls that other operation. ---------------------------------------------------------------------- Comment By: Jim Meyering (meyering) Date: 2004-12-02 09:20 Message: Logged In: YES user_id=41497 Hi, I submitted the original report (and text above). The patch that just calls fflush is not enough, as the second sample script illustrates. Here's a patch that does a little better --- Python/sysmodule.c.~2.126.~ 2004-08-12 20:19:17.000000000 +0200 +++ Python/sysmodule.c 2004-12-02 09:59:09.058953816 +0100 @@ -927,6 +927,13 @@ settrace() -- set the global debug traci ) /* end of sys_doc */ ; +static int +_check_and_flush (FILE *stream) +{ + int prev_fail = ferror (stream); + return fflush (stream) || prev_fail ? EOF : 0; +} + PyObject * _PySys_Init(void) { @@ -941,8 +948,8 @@ _PySys_Init(void) sysdict = PyModule_GetDict(m); sysin = PyFile_FromFile(stdin, "", "r", NULL); - sysout = PyFile_FromFile(stdout, "", "w", NULL); - syserr = PyFile_FromFile(stderr, "", "w", NULL); + sysout = PyFile_FromFile(stdout, "", "w", _check_and_flush); + syserr = PyFile_FromFile(stderr, "", "w", _check_and_flush); if (PyErr_Occurred()) return NULL; #ifdef MS_WINDOWS With that patch, the failing script now evokes a diagnostic and nonzero exit. $ ./python write-4096 > /dev/full write failed: (0, 'Error') But, as you can see, the diagnostic leaves a lot to be desired. It should say ``write failes: [Errno 28] No space left on device''. It'll take a more significant change to propagate errno from the failing fputs/fwrite/etc. to where it can be used. Jim@meyering.net ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:51 Message: Logged In: YES user_id=203860 I can't see how to upload an attachment to this bug, so see patch 1075147. ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2004-11-29 10:43 Message: Logged In: YES user_id=203860 Each Python file object has a pointer to the function to be called on the C stream when close is called on the file object. Normally this is fclose, but Python doesn't want the standard streams closed so their file objects are created with the function pointer set to NULL, making close a no-op on the underlying files. I'm going to attach a patch that changes the function for stdout and stderr to be fflush, so that the streams stay open but write errors are detected at the time of an explicit close. I don't see the relevance of the exitfuncs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470 From noreply at sourceforge.net Mon Dec 20 01:01:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 01:01:11 2004 Subject: [ python-Bugs-1088119 ] Comments regarding 'macintosh' behaviour wrong for MacOS X Message-ID: Bugs item #1088119, was opened at 2004-12-20 00:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088119&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Matthew Farrow (jmfarrow) Assigned to: Nobody/Anonymous (nobody) Summary: Comments regarding 'macintosh' behaviour wrong for MacOS X Initial Comment: Comments in the documentation regarding the behaviour on the Macintosh appear to be referring to the behaviour under MacOS 9 and the behaviour under MacOS X is different. For example, the documentation (for at least 2.3.4 and 2.4) for os.path.expanduser states "On the Macintosh, this always returns path unchanged." Under MacOS X (the example below is for 10.3.7) this is not true: [ezri:~] jmfarrow% uname -a Darwin ezri.internal 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc [ezri:~] jmfarrow% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.expanduser("~jmfarrow") '/Users/jmfarrow' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088119&group_id=5470 From noreply at sourceforge.net Mon Dec 20 01:20:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 01:20:52 2004 Subject: [ python-Bugs-1069409 ] C:\Python24\Lib\compileall.py returns False Message-ID: Bugs item #1069409, was opened at 2004-11-19 09:01 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069409&group_id=5470 Category: IDLE Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Kurt B. Kaiser (kbk) Summary: C:\Python24\Lib\compileall.py returns False Initial Comment: I tried running compileall.py from IDLE with Python 2.4c1 (WinXP, SP1). I get the following 'error': .... Listing C:\WINDOWS\System32\python24.zip ... Can't list C:\WINDOWS\System32\python24.zip Listing C:\Python24 ... Listing C:\Python24\DLLs ... Listing C:\Python24\lib ... Listing C:\Python24\lib\plat-win ... Can't list C:\Python24\lib\plat-win Listing C:\Python24\lib\lib-tk ... Compiling C:\Python24\lib\lib-tk\Canvas.py ... Compiling C:\Python24\lib\lib-tk\Dialog.py ... Compiling C:\Python24\lib\lib-tk\FileDialog.py ... Compiling C:\Python24\lib\lib-tk\ScrolledText.py ... Compiling C:\Python24\lib\lib-tk\Tix.py ... Compiling C:\Python24\lib\lib-tk\Tkdnd.py ... Compiling C:\Python24\lib\lib-tk\turtle.py ... Traceback (most recent call last): File "C:\Python24\Lib\compileall.py", line 157, in -toplevel- sys.exit(exit_status) SystemExit: False >>> Shouldn't an integer value (e.g. 0) be returned by sys.exit? It's nice that you can see where the script has ended, but I think it's good to be more elaborate that everything went OK. I think some users might think it's strange to get a Traceback when everything is ok. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 19:20 Message: Logged In: YES user_id=149084 >From compileall.py:155 : if __name__ == '__main__': exit_status = not main() sys.exit(exit_status) IDLE traps the sys.exit() because quitting IDLE is usually not what the user wants to do when it's encountered in the user's program. compileall.py is exiting with a False status, equivalent to the conventional UNIX success return of zero. You could take it up with the compileall.py maintainer, but to me it's no biggie. In any case, IDLE is working as designed. You can actually run this by $ idle -r compileall.py It will end up in the IDLE shell when finished, just close the shell :-) Works on Windows, too, but the pathnames are more complicated because IDLE isn't currently installed correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:27 Message: Logged In: YES user_id=80475 I think this is just a fact of life when using IDLE to run scripts designed for command-line use. The script is question is fine and represents good coding style. The only question is whether IDLE should handle system exits differently. Kurt, please pronounce and close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069409&group_id=5470 From noreply at sourceforge.net Mon Dec 20 02:33:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 02:33:58 2004 Subject: [ python-Bugs-1080387 ] IDLE Themes and Keys Config not Robust Message-ID: Bugs item #1080387, was opened at 2004-12-06 21:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE Themes and Keys Config not Robust Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 20:33 Message: Logged In: YES user_id=149084 This bug was caused by adding the colorization of built-in keywords. The current design of the themes and keybindings in the configuration system saves the entire modified config file instead of just the changes. When IDLE tried to load your config-highlight.cfg it got out of sync and died miserably. An initial fix would be to fix the config system to load the default bindings (as intended) when there was a problem with the user binding. But to fully fix the problem and make the config system robust, it appears to be necessary to redesign it to save only the changes, as it does for config-main.cfg and config-extensions.cfg. That way any new color items would be loaded from the default config-highlight.def. That's a bit of work. Maybe someone will step up. I've attached a patch to config-highlight.def which should take care of the problem. On Windows it's easiest, no doubt, to just type in the four missing lines. Or just delete config-highlights.cfg and recreate it, whichever is less work. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 16:44 Message: Logged In: YES user_id=149084 Thanks for the report. I'll try to reproduce the problem myself. What is supposed to happen is if IDLE has a problem retreiving the theme, it's supposed to load the default theme from config-highlight.def and if that fails it's supposed to use a fallback theme written into the code itself. Clearly all this complexity isn't working too well, and the error messages aren't particularly helpful. ---------------------------------------------------------------------- Comment By: projecktzero (projecktzero) Date: 2004-12-07 09:35 Message: Logged In: YES user_id=1173237 I was able to reproduce the problem. I'm attaching the warning messages in a text file. ---------------------------------------------------------------------- Comment By: projecktzero (projecktzero) Date: 2004-12-07 08:08 Message: Logged In: YES user_id=1173237 >From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 00:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by "I deleted the color theme?" . What files or parts of files were removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080387&group_id=5470 From noreply at sourceforge.net Mon Dec 20 05:48:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 05:48:44 2004 Subject: [ python-Bugs-1088206 ] zlib decompressobj documentation typo Message-ID: Bugs item #1088206, was opened at 2004-12-20 04:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088206&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: zlib decompressobj documentation typo Initial Comment: In both Python 2.3.4 and 2.4 Python Library Reference 7.15 zlib -- Compression compatible with gzip The documentation that describes zlib.decompressobj, the method description for the decompress message looks like: decompress( string) [max_length] Decompress string, returning a ... when it should be: decompress( string [, max_length]) Decompress string, returning a ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088206&group_id=5470 From noreply at sourceforge.net Mon Dec 20 07:09:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 07:09:44 2004 Subject: [ python-Bugs-1088206 ] zlib decompressobj documentation typo Message-ID: Bugs item #1088206, was opened at 2004-12-19 23:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088206&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: zlib decompressobj documentation typo Initial Comment: In both Python 2.3.4 and 2.4 Python Library Reference 7.15 zlib -- Compression compatible with gzip The documentation that describes zlib.decompressobj, the method description for the decompress message looks like: decompress( string) [max_length] Decompress string, returning a ... when it should be: decompress( string [, max_length]) Decompress string, returning a ... ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-20 01:09 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088206&group_id=5470 From noreply at sourceforge.net Mon Dec 20 07:10:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 07:10:57 2004 Subject: [ python-Bugs-1088119 ] Comments regarding 'macintosh' behaviour wrong for MacOS X Message-ID: Bugs item #1088119, was opened at 2004-12-19 19:01 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088119&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Matthew Farrow (jmfarrow) >Assigned to: Brett Cannon (bcannon) Summary: Comments regarding 'macintosh' behaviour wrong for MacOS X Initial Comment: Comments in the documentation regarding the behaviour on the Macintosh appear to be referring to the behaviour under MacOS 9 and the behaviour under MacOS X is different. For example, the documentation (for at least 2.3.4 and 2.4) for os.path.expanduser states "On the Macintosh, this always returns path unchanged." Under MacOS X (the example below is for 10.3.7) this is not true: [ezri:~] jmfarrow% uname -a Darwin ezri.internal 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc [ezri:~] jmfarrow% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.expanduser("~jmfarrow") '/Users/jmfarrow' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088119&group_id=5470 From noreply at sourceforge.net Mon Dec 20 07:14:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 07:14:16 2004 Subject: [ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off Message-ID: Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by netvigator You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. ---------------------------------------------------------------------- >Comment By: Rick Graves (netvigator) Date: 2004-12-20 01:14 Message: Logged In: YES user_id=1167414 > Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ 1) Who is OP? 2) Is this ball in my court or someone else's? Thanks, netvigator aka Rick Graves ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 18:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 From noreply at sourceforge.net Mon Dec 20 11:18:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 11:18:26 2004 Subject: [ python-Bugs-835300 ] socket object method " makefile" has wrong doc Message-ID: Bugs item #835300, was opened at 2003-11-03 22:23 Message generated for change (Comment added) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Skip Montanaro (montanaro) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- >Comment By: Max Neunh?ffer (neunhoef) Date: 2004-12-20 11:18 Message: Logged In: YES user_id=350896 I can no longer understand what made me file this bug report. I vaguely remember having had the problem that no dup was done, but I am no longer sure what I have seen at the time. Sorry for the inconvenience! ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 20:00 Message: Logged In: YES user_id=129426 Why does this seem to be wrong? If I look at the code in socketmodule.c, it seems to me that sock_makefile does a dup() on the socket's fd, and returns a file based on the new fd.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 From noreply at sourceforge.net Mon Dec 20 11:38:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 11:38:07 2004 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 10:29 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-20 11:38 Message: Logged In: YES user_id=38388 Thanks for the research. Since the "macintosh" character set is defined in the RFC 1345 and the mac_roman encoding in ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT could you compare the two and check whether they are in fact the same mapping ? Note: Aliases for mappings are often implemented in a rather careless way - we want to make sure that things we alias are indeed correct aliases. Otherwise it's would be better to add a new codec for 'macintosh'. Thanks. ---------------------------------------------------------------------- Comment By: Jens Klein (yenzenz) Date: 2004-12-19 21:09 Message: Logged In: YES user_id=474612 seems its a bit more difficult: encoding 'macintosh is registered by iana[1] (nice formatted in [2]) and is covered by RFC1345[3]. Name: macintosh [RFC1345,KXS2] MIBenum: 2027 Source: The Unicode Standard ver1.0, ISBN 0-201-56788-1, Oct 1991 Alias: mac Alias: csMacintosh [1]http://www.iana.org/assignments/character-sets [2]http://www.cs.tut.fi/~jkorpela/chars/sorted.html [3]http://www.faqs.org/rfcs/rfc1345.html so far the hard facts from specification view. in all these specs are mac_roman etc. not mentioned. So what? I found at [4] with the popular program 'recode' a hint of the alias. the aothor there uses the iana registered macintosh as an alias for mac_roman: DEFENCODING(( "MacRoman", /* JDK 1.1 */ /* This is the best table for MACINTOSH. The ones */ /* in glibc and FreeBSD-iconv are bad quality. */ "MACINTOSH", /* IANA */ "MAC", /* IANA */ "csMacintosh", /* IANA */ ), mac_roman, { mac_roman_mbtowc }, { mac_roman_wctomb, NULL }) [4]http://recode.progiciels-bpi.ca/showfile.html?name=fusion/recode-3.6/ libiconv/encodings.def Because of that (I trust recode somehow) i would propose to add macintosh as an alias for mac_roman. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-19 00:01 Message: Logged In: YES user_id=38388 I have no problem adding aliases to the encodings package, but please provide some reference that this actually is a valid alias for the mac_roman encoding. There are quite a few other mac_* encodings to choose from as well, so the coice is not obvious to me. ---------------------------------------------------------------------- Comment By: Jens Klein (yenzenz) Date: 2004-12-18 23:49 Message: Logged In: YES user_id=474612 +1 from me Archetypes (a Zope framework) runs also in a problem because of the missing alias. more infos: https://sourceforge.net/tracker/index.php? func=detail&aid=1068001&group_id=75272&atid=543430 ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-11-17 11:47 Message: Logged In: YES user_id=46639 The test was just a sequence of random high-bit characters: ?????????????? (lets see if the web interface lets that through). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-17 11:12 Message: Logged In: YES user_id=38388 Are you sure ? The decoded string you give does not look like anything readable... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Mon Dec 20 11:57:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 12:00:30 2004 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-17 03:02 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-20 19:57 Message: Logged In: YES user_id=671362 I'm +1 for sanity checking rather than waiting for the GNU readline to return NULL in these functions. It's just adding a few lines of code right after PyArg_ParseTuple : if (entry_number < 0) { PyErr_SetString(PyExc_ValueError, "index cannot be a negative value"); return NULL; } Then you can work around the problem without worrying about the return value of remove_history nor replace_history_entry. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-20 01:41 Message: Logged In: YES user_id=6656 Do you want to fix it then? :) I can't imagine it's that hard, but it would be easier for someone who can test that their fix helps... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-18 19:45 Message: Logged In: YES user_id=671362 FYI, I can reproduce this with : - Python 2.4 & readline 4.3 under SuSE 9.1 - Python 2.5(snapshot as of 2004-12-17) & readline 4.3 under SuSE 9.1 - Python 2.4 & readline 4.3.5(?) under Cygwin ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-17 23:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Mon Dec 20 13:49:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 13:49:20 2004 Subject: [ python-Bugs-1076819 ] test_shelve failures Message-ID: Bugs item #1076819, was opened at 2004-12-01 16:22 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: ====================================================================== FAIL: test_read (__main__.TestAsciiFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestBinaryFileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ====================================================================== FAIL: test_read (__main__.TestProto2FileShelve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py", line 59, in test_read self.assert_(d.has_key(k)) AssertionError ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-12-20 13:49 Message: Logged In: YES user_id=192186 It was probably problem somewhere else in the system, I can not reproduce it right now, so some upgrade has probably fixed this issue. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:38 Message: Logged In: YES user_id=80475 Works for me on WinME and WinXP. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 09:53 Message: Logged In: YES user_id=250749 Test works for me on FreeBSD 4.8. Make sure that you can use anydbm - more details on what db module is actually invoked by anydbm might help shed some more light on the matter (use the file utility on a database created with anydbm.open()). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076819&group_id=5470 From noreply at sourceforge.net Mon Dec 20 13:59:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 14:00:00 2004 Subject: [ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off Message-ID: Bugs item #1074333, was opened at 2004-11-27 22:37 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-20 13:59 Message: Logged In: YES user_id=469548 OP = opening poster. So yes, the ball is in your court. :) ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-12-20 07:14 Message: Logged In: YES user_id=1167414 > Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ 1) Who is OP? 2) Is this ball in my court or someone else's? Thanks, netvigator aka Rick Graves ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-20 00:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 22:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-11-27 22:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 From noreply at sourceforge.net Mon Dec 20 14:07:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 14:07:34 2004 Subject: [ python-Bugs-1087551 ] inspect.py module Message-ID: Bugs item #1087551, was opened at 2004-12-18 16:33 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087551&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: sprasanna199 (sprasanna199) Assigned to: Samuele Pedroni (pedronis) Summary: inspect.py module Initial Comment: I tried to compile python 2.4 inspect.py module in Jython but it throwed an exception. The line 749 in the inspect.py module caused the exception which is start = lineno - 1 - context//2 The code corresponding to it was also shown. But when I modified that line to start = lineno - 1 - context/2 it worked. Regards, S.Prasanna Code: if context > 0: start = lineno - 1 - context//2 try: lines, lnum = findsource(frame) except IOError: lines = index = None else: start = max(start, 1) start = min(start, len(lines) - context) lines = lines[start:start+context] index = lineno - 1 - start else: lines = index = None ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-20 14:07 Message: Logged In: YES user_id=469548 This is not a bug in Python. The '//' operator was introduced in Python 2.2, while Jython is still tracking Python 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087551&group_id=5470 From noreply at sourceforge.net Mon Dec 20 14:40:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 14:40:53 2004 Subject: [ python-Bugs-835300 ] socket object method " makefile" has wrong doc Message-ID: Bugs item #835300, was opened at 2003-11-03 16:23 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Skip Montanaro (montanaro) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- Comment By: Max Neunh?ffer (neunhoef) Date: 2004-12-20 05:18 Message: Logged In: YES user_id=350896 I can no longer understand what made me file this bug report. I vaguely remember having had the problem that no dup was done, but I am no longer sure what I have seen at the time. Sorry for the inconvenience! ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 14:00 Message: Logged In: YES user_id=129426 Why does this seem to be wrong? If I look at the code in socketmodule.c, it seems to me that sock_makefile does a dup() on the socket's fd, and returns a file based on the new fd.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 From noreply at sourceforge.net Mon Dec 20 16:04:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 16:05:02 2004 Subject: [ python-Bugs-835300 ] socket object method " makefile" has wrong doc Message-ID: Bugs item #835300, was opened at 2003-11-03 15:23 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Skip Montanaro (montanaro) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-20 09:04 Message: Logged In: YES user_id=44345 I'm pretty sure I know why you filed this item. socket.py contains code to work around shortcomings on Windows and BeOS (neither were able to dup() sockets). At some point we incorporated that same code for other platforms for consistency reasons, thus underlying sockets are not really dup'd: >>> import socket >>> s = socket.socket() >>> s >>> t = s.dup() >>> t >>> t._sock >>> s._sock >>> id(s._sock) 136563280 >>> id(t._sock) 136563280 Most of the time this doesn't affect anything, but I believe it does in certain cases. ---------------------------------------------------------------------- Comment By: Max Neunh?ffer (neunhoef) Date: 2004-12-20 04:18 Message: Logged In: YES user_id=350896 I can no longer understand what made me file this bug report. I vaguely remember having had the problem that no dup was done, but I am no longer sure what I have seen at the time. Sorry for the inconvenience! ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 13:00 Message: Logged In: YES user_id=129426 Why does this seem to be wrong? If I look at the code in socketmodule.c, it seems to me that sock_makefile does a dup() on the socket's fd, and returns a file based on the new fd.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 From noreply at sourceforge.net Mon Dec 20 19:29:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 19:29:42 2004 Subject: [ python-Bugs-1088563 ] calculation wrong rounding Message-ID: Bugs item #1088563, was opened at 2004-12-20 19:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088563&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Rockel (buzz42) Assigned to: Jack Jansen (jackjansen) Summary: calculation wrong rounding Initial Comment: I am using python 2.4 on MAC OS 10.3.7 with gcc V3.3 20030304 (Apple Computer, Inc. build 1666) It is a simple calculation. There seems to be a little rounding problem: >>> 4053020.7+10*324241.6 7295436.7000000002 It shoult be of course 7295436.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088563&group_id=5470 From noreply at sourceforge.net Mon Dec 20 20:09:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 20 20:10:01 2004 Subject: [ python-Bugs-1088563 ] calculation wrong rounding Message-ID: Bugs item #1088563, was opened at 2004-12-20 13:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088563&group_id=5470 Category: Macintosh >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Sebastian Rockel (buzz42) Assigned to: Jack Jansen (jackjansen) Summary: calculation wrong rounding Initial Comment: I am using python 2.4 on MAC OS 10.3.7 with gcc V3.3 20030304 (Apple Computer, Inc. build 1666) It is a simple calculation. There seems to be a little rounding problem: >>> 4053020.7+10*324241.6 7295436.7000000002 It shoult be of course 7295436.7 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-12-20 14:09 Message: Logged In: YES user_id=31435 Please read the Appendix about floating-point issues in the Python Tutorial -- what you're seeing is an unavoidable consquence of using binary floating-point hardware. If you require exact decimal representations, use the new ``decimal`` module intead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088563&group_id=5470 From noreply at sourceforge.net Tue Dec 21 09:10:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 09:11:07 2004 Subject: [ python-Bugs-1088891 ] _sre.c references uninitialised memory Message-ID: Bugs item #1088891, was opened at 2004-12-21 19:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088891&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Andrew McNamara (andrewmcnamara) Assigned to: Gustavo Niemeyer (niemeyer) Summary: _sre.c references uninitialised memory Initial Comment: In _sre.c, data_stack_grow(), realloc'ed memory is not initialised before use. When complex regexps are used, this results in a core dump. Initialising the newly allocated memory to 0x55 and executing an offending regexp results in a fatal reference to an address like 0x55555558: static int data_stack_grow(SRE_STATE* state, int size) { int minsize, cursize; minsize = state->data_stack_base+size; cursize = state->data_stack_size; if (cursize < minsize) { void* stack; cursize = minsize+minsize/4+1024; TRACE(("allocate/grow stack %d\n", cursize)); stack = realloc(state->data_stack, cursize); if (!stack) { data_stack_dealloc(state); return SRE_ERROR_MEMORY; } memset(stack+state->data_stack_size, 0x55, cursize-state- >data_stack_size); state->data_stack = stack; state->data_stack_size = cursize; } return 0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088891&group_id=5470 From noreply at sourceforge.net Tue Dec 21 13:37:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 13:38:04 2004 Subject: [ python-Bugs-1088891 ] _sre.c references uninitialised memory Message-ID: Bugs item #1088891, was opened at 2004-12-21 08:10 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088891&group_id=5470 Category: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Andrew McNamara (andrewmcnamara) Assigned to: Gustavo Niemeyer (niemeyer) Summary: _sre.c references uninitialised memory Initial Comment: In _sre.c, data_stack_grow(), realloc'ed memory is not initialised before use. When complex regexps are used, this results in a core dump. Initialising the newly allocated memory to 0x55 and executing an offending regexp results in a fatal reference to an address like 0x55555558: static int data_stack_grow(SRE_STATE* state, int size) { int minsize, cursize; minsize = state->data_stack_base+size; cursize = state->data_stack_size; if (cursize < minsize) { void* stack; cursize = minsize+minsize/4+1024; TRACE(("allocate/grow stack %d\n", cursize)); stack = realloc(state->data_stack, cursize); if (!stack) { data_stack_dealloc(state); return SRE_ERROR_MEMORY; } memset(stack+state->data_stack_size, 0x55, cursize-state- >data_stack_size); state->data_stack = stack; state->data_stack_size = cursize; } return 0; } ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-12-21 12:37 Message: Logged In: YES user_id=7887 The real problem is not initializing realloced memory, but acknowledging memory reallocation in situations where data may be reallocated outside of the main matching function. Please, have a look at the bug at http://python.org/sf/1072259 for more information and for a patch fixing the problem. Thanks for reporting it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088891&group_id=5470 From noreply at sourceforge.net Tue Dec 21 16:08:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 16:08:59 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sebastian Hartte (dark-storm) >Assigned to: M.-A. Lemburg (lemburg) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-21 16:08 Message: Logged In: YES user_id=89016 Here is a third version of the patch. Changes are: 1) The problem with the \r\n split between two read() calls is fixed. 2) The first read() from the byte stream in readline() no longer requires characters beyond the first line. 3) Tests for these cases have been added. 4) The join call has been fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 22:19 Message: Logged In: YES user_id=38388 Looks good, please check it in with one correction: "".join() should be u"".join(). Thanks, Walter ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-17 19:12 Message: Logged In: YES user_id=89016 Here is a second version of the patch (fix_readline_and_read2.diff) that implements all those changes. With this we get "universal newline" support for free. Note that there is still one corner case: If the byte stream is temporarily exhausted and the last character read is a \r, and the next character read (once the stream contains new data) is an \n, this will result in two lines instead of one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 13:59 Message: Logged In: YES user_id=38388 Walter, the fix to .read() looks OK, but the implementation of .readline() is not correct: there are far more line break characters in Unicode than just \n. The correct way to check would be by using .splitlines() which does know about all the possible line break characters in Unicode, plus it also handles line ends such as \r\n and just \r correctly. If .splitlines() returns a list with more than one entry you know that you've hit a line end and you can push the remaining entries entries back onto the .charbuffer. Another nit: you should bump the default for readsize to 72 - the average line size used in text files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Tue Dec 21 16:32:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 16:32:27 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sebastian Hartte (dark-storm) >Assigned to: Walter D?rwald (doerwalter) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-21 16:32 Message: Logged In: YES user_id=38388 Even better. Please check it in. Thanks and Merry Christmas :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-21 16:08 Message: Logged In: YES user_id=89016 Here is a third version of the patch. Changes are: 1) The problem with the \r\n split between two read() calls is fixed. 2) The first read() from the byte stream in readline() no longer requires characters beyond the first line. 3) Tests for these cases have been added. 4) The join call has been fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 22:19 Message: Logged In: YES user_id=38388 Looks good, please check it in with one correction: "".join() should be u"".join(). Thanks, Walter ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-17 19:12 Message: Logged In: YES user_id=89016 Here is a second version of the patch (fix_readline_and_read2.diff) that implements all those changes. With this we get "universal newline" support for free. Note that there is still one corner case: If the byte stream is temporarily exhausted and the last character read is a \r, and the next character read (once the stream contains new data) is an \n, this will result in two lines instead of one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 13:59 Message: Logged In: YES user_id=38388 Walter, the fix to .read() looks OK, but the implementation of .readline() is not correct: there are far more line break characters in Unicode than just \n. The correct way to check would be by using .splitlines() which does know about all the possible line break characters in Unicode, plus it also handles line ends such as \r\n and just \r correctly. If .splitlines() returns a list with more than one entry you know that you've hit a line end and you can push the remaining entries entries back onto the .charbuffer. Another nit: you should bump the default for readsize to 72 - the average line size used in text files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Tue Dec 21 17:23:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 17:24:05 2004 Subject: [ python-Bugs-1065427 ] sre_parse group limit check missing with 'python -O' Message-ID: Bugs item #1065427, was opened at 2004-11-12 20:46 Message generated for change (Comment added) made by kbriggs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065427&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sam Rushing (rushing) Assigned to: Fredrik Lundh (effbot) Summary: sre_parse group limit check missing with 'python -O' Initial Comment: sre_parse.py includes a check to ensure that the hard-coded limit of 100 groups is not exceeded. Since the check uses an assert(), it's not present when running in '-O' mode, so you can easily segfault the re engine: rushing@fang:~$ /usr/local/bin/python -O Python 2.3.4 (#2, Oct 23 2004, 05:24:36) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 >>> import re >>> p = re.compile ('(' + '|'.join (['(xxx)']*200) + ')') >>> p.search ('asdfasdfasdfasdfasdf') Segmentation fault (core dumped) The assert() should be changed to an 'if/raise'. NOTE: I've sent changes to Frederik to remove the limitation altogether - so if those get in before this bug is addressed then please ignore. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2004-12-21 16:23 Message: Logged In: YES user_id=888261 There is a further problem here - the error message refers to "100 named groups", whereas the exception seems to be raised when there are too many groups, whether they are named or not. What is the reason for this limit? Can it easily be removed? It is causing me many problems. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-13 07:02 Message: Logged In: YES user_id=38376 This was changed in 2.4b1 (didn't I mail you about this?): >>> p = re.compile ('(' + '|'.join (['(xxx)']*200) + ')') Traceback (most recent call last): File "", line 1, in ? File "/home/fredrik/NOBACKUP/python- dev/python/dist/src/Lib/sre.py", line 180, in compile return _compile(pattern, flags) File "/home/fredrik/NOBACKUP/python- dev/python/dist/src/Lib/sre.py", line 225, in _compile p = sre_compile.compile(pattern, flags) File "/home/fredrik/NOBACKUP/python- dev/python/dist/src/Lib/sre_compile.py", line 506, in compile raise AssertionError( AssertionError: sorry, but this version only supports 100 named groups As for the real fix, it arrived too close to the beta release, and while it looks pretty solid, I'm not sure if it's a good idea to add it this close to a major release. I'll bring this up on python-dev, when I find the time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1065427&group_id=5470 From noreply at sourceforge.net Tue Dec 21 22:02:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 22:02:44 2004 Subject: [ python-Bugs-1089358 ] need siginterrupt() on Linux - impossible to do timeouts Message-ID: Bugs item #1089358, was opened at 2004-12-21 16:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089358&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason (jvd66) Assigned to: Nobody/Anonymous (nobody) Summary: need siginterrupt() on Linux - impossible to do timeouts Initial Comment: On latest versions of Linux (eg. Red Hat FC2 / FC3, kernel 2.6+, glibc 2.3.3+) it seems to be impossible to get a system call invoked by Python to time out if it enters a blocking operation (eg read, recvfrom) using Python's signal or threading modules. A good example is 'gethostbyname' - if the network cable is unplugged, or the name servers are not contactable, then a Python program will hang for a very long time (5 minutes by default) before being able to proceed. I've tried to do timeouts using either the signal module or using threading timers (see attached examples) - but though the signal handler is called when the SIGALRM is received , and the timer activates the callback, the main thread is still blocked in gethostbyname and the whole process is blocked - so timeouts cannot be implemented. If anyone knows a better way of getting a blocking system call to timeout in python, please let me know. I've finally resorted to invoking the BIND 'dig' program with timeout parameters from commands.getstatusoutput so my app can recover from network connectivity problems. I think we need to be able to invoke the glibc siginterrupt() function from Python; ONLY by doing so are signals allowed to interrupt system calls so that they return EINTR . Note that this differs from "old" Linux behaviour . The siginterrupt man page states: " system calls will be restarted if interrupted by the speci- fied signal sig. This is the default behaviour in Linux. " (this is true) " However, when a new signal handler is specified with the signal(2) function, the system call is interrupted by default. " ( THIS IS FALSE !) With modern Linux kernels + glibcs, all signals are restarted UNLESS the siginterrupt( sig, 1 ) call is invoked. This may be a glibc bug, but many glibcs out there have it. This issue can be reproduced using the attached c program - without the siginterrupt, the system call is not interrupted . PLEASE provide a wrapper to call the siginterrupt(3) glibc function from Python - THANKS . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089358&group_id=5470 From noreply at sourceforge.net Tue Dec 21 23:02:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 23:02:17 2004 Subject: [ python-Bugs-1089395 ] segfault/assert in tokenizer Message-ID: Bugs item #1089395, was opened at 2004-12-21 23:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L?wis (loewis) Summary: segfault/assert in tokenizer Initial Comment: The attached script fail.py (with the attached codec evilascii.py) leads to a segfault in both Python 2.3 and 2.4. With a debug build I get: python: Parser/tokenizer.c:367: fp_readl: Assertion `strlen(str) < (size_t)size' failed. Aborted Assigning to Martin, because this seems to be PEP 263 related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089395&group_id=5470 From noreply at sourceforge.net Tue Dec 21 23:10:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 21 23:10:08 2004 Subject: [ python-Bugs-1089399 ] Carbon.Res misses GetIndString Message-ID: Bugs item #1089399, was opened at 2004-12-21 23:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089399&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.Res misses GetIndString Initial Comment: GetIndString (and probably one or two others) are missing from Carbon.Res, because they're declared in TextUtils.h. We need to add manual generators for them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089399&group_id=5470 From noreply at sourceforge.net Wed Dec 22 06:12:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 06:12:19 2004 Subject: [ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info Message-ID: Bugs item #1085300, was opened at 2004-12-14 10:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walrus (unclewalrus) Assigned to: Brett Cannon (bcannon) Summary: Mac Library Modules 1.1.1 Bad Info Initial Comment: Document states that OS X's TextEdit only saves RTF files. This is incorrect; you can make a plaintext file by choosing 'Make Plain Text' from the Format menu. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-21 21:12 Message: Logged In: YES user_id=357491 Yes, it's true; RTF and plaintext are the two possible output. Walrus, where exactly in the docs does it claim this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 13:35 Message: Logged In: YES user_id=80475 Brett, can you verify this and, if true, add an appropriate note to the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 From noreply at sourceforge.net Wed Dec 22 06:14:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 06:14:57 2004 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 02:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-21 21:14 Message: Logged In: YES user_id=357491 Since I believe this was fixed with the patch Tino mentions and Roberto has not replied, I am closing as fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-16 16:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 15:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Wed Dec 22 06:43:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 06:43:17 2004 Subject: [ python-Bugs-1088119 ] Comments regarding 'macintosh' behaviour wrong for MacOS X Message-ID: Bugs item #1088119, was opened at 2004-12-19 16:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088119&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: James Matthew Farrow (jmfarrow) Assigned to: Brett Cannon (bcannon) Summary: Comments regarding 'macintosh' behaviour wrong for MacOS X Initial Comment: Comments in the documentation regarding the behaviour on the Macintosh appear to be referring to the behaviour under MacOS 9 and the behaviour under MacOS X is different. For example, the documentation (for at least 2.3.4 and 2.4) for os.path.expanduser states "On the Macintosh, this always returns path unchanged." Under MacOS X (the example below is for 10.3.7) this is not true: [ezri:~] jmfarrow% uname -a Darwin ezri.internal 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc [ezri:~] jmfarrow% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.expanduser("~jmfarrow") '/Users/jmfarrow' ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-21 21:43 Message: Logged In: YES user_id=357491 You're right; "Machintosh" in the docs refer to MacOS 9 and not OS X. You can pretty much always view things in terms of UNIX for OS X. Should probably go through the docs and double-check all Macintosh references, perhaps even rename all "Macintosh" references to "darwin". As for this specific case, fixed in rev. 1.41 for 2.5 and 1.40.2.1 for 2.4 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1088119&group_id=5470 From noreply at sourceforge.net Wed Dec 22 08:07:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 08:08:14 2004 Subject: [ python-Bugs-1068268 ] subprocess is not EINTR-safe Message-ID: Bugs item #1068268, was opened at 2004-11-18 05:07 Message generated for change (Comment added) made by mattjohnston You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Peter ?strand (astrand) Assigned to: Peter ?strand (astrand) Summary: subprocess is not EINTR-safe Initial Comment: The subprocess module is not safe for use with signals, because it doesn't retry the system calls upon EINTR. However, as far as I understand it, this is true for most other Python modules as well, so it isn't obvious that the subprocess needs to be fixed. The problem was first noticed by John P Speno. ---------------------------------------------------------------------- Comment By: Matt Johnston (mattjohnston) Date: 2004-12-22 15:07 Message: Logged In: YES user_id=785805 I've hit this on a Solaris 9 box without explicitly using signals. Using the DCOracle module, a seperate Oracle process is executed. When this terminates, a SIGCHLD is sent to the calling python process, which may be in the middle of a select() in the communicate() call, causing EINTR. From the output of truss (like strace), a sigchld handler doesn't appear to be getting explicitly installed by the Oracle module. SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2004-11-18 05:15 Message: Logged In: YES user_id=344921 One way of testing subprocess for signal-safeness is to insert these lines just after _cleanup(): import signal signal.signal(signal.SIGALRM, lambda x,y: 1) signal.alarm(1) import time time.sleep(0.99) Then run test_subprocess.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470 From noreply at sourceforge.net Wed Dec 22 10:51:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 10:51:09 2004 Subject: [ python-Bugs-1089624 ] Carbon.File.FSCatalogInfo.createDate implementation Message-ID: Bugs item #1089624, was opened at 2004-12-22 10:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089624&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.File.FSCatalogInfo.createDate implementation Initial Comment: In Mac/Modules/file/_Filemodule.c UTCDateTime values are converted using these functions: static int UTCDateTime_Convert(PyObject *v, UTCDateTime *ptr) { return PyArg_Parse(v, "(HlH)", &ptr->highSeconds, &ptr- >lowSeconds, &ptr->fraction); } static PyObject * UTCDateTime_New(UTCDateTime *ptr) { return Py_BuildValue("(HlH)", ptr->highSeconds, ptr- >lowSeconds, ptr->fraction); } Shouldn't the format string be "(HLH)" in both cases? The struct definition of UTCDateTime contains unsigned times (UInt16, UInt32 and UInt16). The same problem is present in Python 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089624&group_id=5470 From noreply at sourceforge.net Wed Dec 22 11:07:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 11:07:55 2004 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 15:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Wed Dec 22 11:11:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 11:11:20 2004 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 15:37 Message generated for change (Settings changed) made by saravanand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 9 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Wed Dec 22 11:21:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 11:21:47 2004 Subject: [ python-Bugs-1089643 ] Carbon.File.FSCatalogInfo.createDate implementation Message-ID: Bugs item #1089643, was opened at 2004-12-22 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089643&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.File.FSCatalogInfo.createDate implementation Initial Comment: In Mac/Modules/file/_Filemodule.c UTCDateTime values are converted using these functions: static int UTCDateTime_Convert(PyObject *v, UTCDateTime *ptr) { return PyArg_Parse(v, "(HlH)", &ptr->highSeconds, &ptr- >lowSeconds, &ptr->fraction); } static PyObject * UTCDateTime_New(UTCDateTime *ptr) { return Py_BuildValue("(HlH)", ptr->highSeconds, ptr- >lowSeconds, ptr->fraction); } Shouldn't the format string be "(HLH)" in both cases? The struct definition of UTCDateTime contains unsigned times (UInt16, UInt32 and UInt16). The same problem is present in Python 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089643&group_id=5470 From noreply at sourceforge.net Wed Dec 22 11:23:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 11:23:56 2004 Subject: [ python-Bugs-1089643 ] Carbon.File.FSCatalogInfo.createDate implementation Message-ID: Bugs item #1089643, was opened at 2004-12-22 11:21 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089643&group_id=5470 Category: Macintosh Group: Python 2.4 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.File.FSCatalogInfo.createDate implementation Initial Comment: In Mac/Modules/file/_Filemodule.c UTCDateTime values are converted using these functions: static int UTCDateTime_Convert(PyObject *v, UTCDateTime *ptr) { return PyArg_Parse(v, "(HlH)", &ptr->highSeconds, &ptr- >lowSeconds, &ptr->fraction); } static PyObject * UTCDateTime_New(UTCDateTime *ptr) { return Py_BuildValue("(HlH)", ptr->highSeconds, ptr- >lowSeconds, ptr->fraction); } Shouldn't the format string be "(HLH)" in both cases? The struct definition of UTCDateTime contains unsigned times (UInt16, UInt32 and UInt16). The same problem is present in Python 2.3 ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-12-22 11:23 Message: Logged In: YES user_id=580910 whoops, submitted the same bug twice ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089643&group_id=5470 From noreply at sourceforge.net Wed Dec 22 13:41:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 13:41:19 2004 Subject: [ python-Bugs-1085208 ] Installation ends prematurely Message-ID: Bugs item #1085208, was opened at 2004-12-14 17:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: anamh0001 (anamh0001) Assigned to: Martin v. L?wis (loewis) Summary: Installation ends prematurely Initial Comment: Test machine: Pentium 4M 1.7Ghz Win XP Pro w/ SP2 512Mb RAM 30Gb HD .Net Framework 1.0 and 1.1 Windows Scripting Host 5.6 After double clicking the installation file. It proceeds to act like any other Windows Installer. After accepting c:\Python24 as the install directory, I am presented with this screen saying that there was an error and that the installation has ended prematurely. FYI, I tried to install over Python 2.3 (as in upgrade) but I got the same error. So I proceeded to uninstall Python 2.3 and other installed libraries. I then restarted the PC and tried to install Python 2.4 again. This bug is the symptom of this second try. Please find the screenshot attached showing the final screen. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:41 Message: Logged In: YES user_id=21627 This is fixed for 2.4.1, which will not require VB anymore. ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 16:21 Message: Logged In: YES user_id=1178107 BUG FIXED -- solution below. 1) BTW I actually thought the installer was looking for c:\python24. So I created the folder before running the installer again. But it didnt work. When I ran the script. It returned this error: I used cscript. c:\x.vbs(2, 7) (null): The specified module could not be found. 2) The version of wscript and cscript is 5.6.0.8825 3) This is latest version because I read that installing the latest version of scripting host fixes installation problems. **** I managed to fix it. I registered scrrun.dll by typing: regsvr32 c:\windows\system32\scrrun.dll Thanks for all the help.. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:07 Message: Logged In: YES user_id=21627 Can you please try the following things? 1. Run the script ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== in wscript.exe (i.e. save it into c:\x.vbs, then run c:\x.vbs) 2. Report the version of C:\WINDOWS\SYSTEM32\wscript.exe (5.6 is too imprecise - could it be that you have 5.6.0.8820?) 3. Install VBScript, from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943 -7E4B-4622-86EB-95A22B832CAA&displaylang=en ---------------------------------------------------------------------- Comment By: anamh0001 (anamh0001) Date: 2004-12-16 11:04 Message: Logged In: YES user_id=1178107 Please find the msi log file attached. I managed to pinpoint the area where it breaks.. It's failing on CheckDir with an error 2896. ----- MSI (c) (88:54) [09:50:38:430]: Doing action: CheckDir Action start 09:50:38: CheckDir. MSI (c) (88:3C) [09:50:38:440]: Cloaking enabled. MSI (c) (88:3C) [09:50:38:440]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (88:3C) [09:50:38:440]: Connected to service for CA interface. MSI (c) (88:88) [09:50:38:580]: Entering MsiProvideComponentFromDescriptor. Descriptor: 2eAq^]D2g (8V7Xaq(hoRIngresDBMS>M5KDYSUnf(HA*L[xeX)y, PathBuf: 1C4F348, pcchPathBuf: 1C4F344, pcchArgsOffset: 1C4F2A4 MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (88:88) [09:50:38:580]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 09:50:38: CheckDir. Return value 3. MSI (c) (88:54) [09:50:38:921]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 09:50:38: SelectDirectoryDlg. Return value 3. MSI (c) (88:94) [09:50:38:931]: Doing action: FatalError Action start 09:50:38: FatalError. Action 09:50:38: FatalError. Dialog created Action ended 09:50:39: FatalError. Return value 2. Action ended 09:50:40: INSTALL. Return value 3. MSI (c) (88:94) [09:50:40:012]: Destroying RemoteAPI object. MSI (c) (88:3C) [09:50:40:012]: Custom Action Manager thread ending. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-15 23:35 Message: Logged In: YES user_id=21627 Can you please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log (do NOT paste it into the SF comment box). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085208&group_id=5470 From noreply at sourceforge.net Wed Dec 22 13:43:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 13:43:11 2004 Subject: [ python-Bugs-1079545 ] python-2.4.msi install error Message-ID: Bugs item #1079545, was opened at 2004-12-05 21:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 Category: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: maharal (maharal) Assigned to: Martin v. L?wis (loewis) Summary: python-2.4.msi install error Initial Comment: when I try to install python2.4. using the python- 2.4.msi-file, it stopps with the error message: "The installer has encountered an unexpected error installing this package. This may inidicate a problem with this package. The error code is 2738" ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:43 Message: Logged In: YES user_id=21627 I have now made the changes to drop VB for 2.4.1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 23:12 Message: Logged In: YES user_id=21627 Ok, I have added an entry into http://www.python.org/2.4/bugs.html For 2.4.1, I will try to do without VB. ---------------------------------------------------------------------- Comment By: maharal (maharal) Date: 2004-12-08 15:16 Message: Logged In: YES user_id=1171290 Dear Mr. L?wis, Your presumption was right: vbscript 5.6 was all that was needed to make the installation run! Thanks a lot for your help! Ralf ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:59 Message: Logged In: YES user_id=21627 Can you please try to install VBScript, from http://msdn.microsoft.com/downloads/list/webdev.asp and report whether this works? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470 From noreply at sourceforge.net Wed Dec 22 13:45:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 13:45:09 2004 Subject: [ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues Message-ID: Bugs item #1074873, was opened at 2004-11-28 23:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 Category: Installation Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: dmerrill (davemerrill) Assigned to: Martin v. L?wis (loewis) Summary: Windows 2.4c1 installer default location issues Initial Comment: On win2k sp4, python-2.4c1.msi defaults to installing in c:\Python24\, rather than the more usual c:\Program Files\Python24\ like 2.3.3 did. When I pointed it to c:\Program Files\Python24\, it installed there, but I couldn't get IDLE to run; silent failure. Not sure if there were other similar issues. Uninstalled, and reinstalled to the default location, all is (apparently, so far) well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:45 Message: Logged In: YES user_id=21627 The IDLE problem is fixed for 2.4.1, by properly supporting spaces in the target directory name. The default location is not a bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:45 Message: Logged In: YES user_id=21627 Not sure what the bug is that you are reporting here. It is intentional that Python installs into c:\python24, not into Program Files. The IDLE problem indicates a bug, of course. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-01 17:30 Message: Logged In: YES user_id=832557 More details on the IDLE issue in bug report 1076861, here ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470 From noreply at sourceforge.net Wed Dec 22 13:56:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 13:56:48 2004 Subject: [ python-Bugs-1076985 ] Incorrect behaviour of StreamReader.readline leads to crash Message-ID: Bugs item #1076985, was opened at 2004-12-01 19:51 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sebastian Hartte (dark-storm) Assigned to: Walter D?rwald (doerwalter) Summary: Incorrect behaviour of StreamReader.readline leads to crash Initial Comment: StreamReader.readline in codecs.py misinterprets the size parameter. (File: codecs.py, Line: 296). The reported crash happens if a file processed by the python tokenizer is using a not built-in codec for source file encoding (i.e. iso-8859-15) and has lines that are longer than the define BUFSIZ in stdio.h on the platform python is compiled on. (On Windows for MSVC++ this define is 512, thus a line that is longer than 511 characters should suffice to crash python with the correct encoding). The crash happens because the python core assumes that the StreamReader.readline method returns a string shorter than the platforms BUFSIZ macro (512 for MSVC). The current StreamReader.readline() looks like this: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 line = u"" while True: data = self.read(size) line += data pos = line.find("\n") if pos>=0: self.charbuffer = line[pos+1:] + self.charbuffer if keepends: line = line[:pos+1] else: line = line[:pos] return line elif not data: return line if size<8000: size *= 2 --------------------------------------- However, the core expects readline() to return at most a string of the length size. readline() instead passes size to the read() function. There are multiple ways of solving this issue. a) Make the core reallocate the token memory if the string returned by the readline function exceeds the expected size (risky if the line is very long). b) Fix, rename, remodel, change StreamReader.readline. If no other part of the core or code expects size to do nothing useful, the following readline() function does behave correctly with arbitrarily long lines: --------------------------------------- def readline(self, size=None, keepends=True): """ Read one line from the input stream and return the decoded data. size, if given, is passed as size argument to the read() method. """ if size is None: size = 10 data = self.read(size) pos = data.find("\n") if pos>=0: self.charbuffer = data[pos+1:] + self.charbuffer if keepends: data = data[:pos+1] else: data = data[:pos] return data else: return data # Return the data directly since otherwise # we would exceed the given size. --------------------------------------- Reproducing this bug: This bug can only be reproduced if your platform does use a small BUFSIZ for stdio operations (i.e. MSVC), i didn't check but Linux might use more than 8000 byte for the default buffer size. That means you would have to use a line with more than 8000 characters to reproduce this. In addition, this bug only shows if the python libraries StreamReader.readline() method is used, if internal codecs like Latin-1 are used, there is no crash since the method isn't used. I've attached a file that crashes my Python 2.4 on Windows using the official binary released on python.org today. Last but not least here is the assertion that is broken if python is compiled in debug mode with MSVC++ 7.1: Assertion failed: strlen(str) < (size_t)size, file \Python-2.4\Parser\tokenizer. c, line 367 ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-12-22 13:56 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.36 Lib/test/test_codecs.py 1.16 Misc/NEWS 1.1213 Lib/codecs.py 1.35.2.1 Lib/test/test_codecs.py 1.15.2.1 Misc/NEWS 1.1193.2.9 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-21 16:32 Message: Logged In: YES user_id=38388 Even better. Please check it in. Thanks and Merry Christmas :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-21 16:08 Message: Logged In: YES user_id=89016 Here is a third version of the patch. Changes are: 1) The problem with the \r\n split between two read() calls is fixed. 2) The first read() from the byte stream in readline() no longer requires characters beyond the first line. 3) Tests for these cases have been added. 4) The join call has been fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 22:19 Message: Logged In: YES user_id=38388 Looks good, please check it in with one correction: "".join() should be u"".join(). Thanks, Walter ! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-17 19:12 Message: Logged In: YES user_id=89016 Here is a second version of the patch (fix_readline_and_read2.diff) that implements all those changes. With this we get "universal newline" support for free. Note that there is still one corner case: If the byte stream is temporarily exhausted and the last character read is a \r, and the next character read (once the stream contains new data) is an \n, this will result in two lines instead of one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-17 13:59 Message: Logged In: YES user_id=38388 Walter, the fix to .read() looks OK, but the implementation of .readline() is not correct: there are far more line break characters in Unicode than just \n. The correct way to check would be by using .splitlines() which does know about all the possible line break characters in Unicode, plus it also handles line ends such as \r\n and just \r correctly. If .splitlines() returns a list with more than one entry you know that you've hit a line end and you can push the remaining entries entries back onto the .charbuffer. Another nit: you should bump the default for readsize to 72 - the average line size used in text files. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-16 00:55 Message: Logged In: YES user_id=89016 OK, here is a patch (fix_readline_and_read.diff) that keeps the new readline behaviour when size is None and calls read only once (i.e. the 2.3 behaviour) otherwise. The "read() cleanup patch" is also included. Running dark-storm's test script on Windows with the patch applied confirms that it fixed this particular problem (of course the tokenizer should still be fixed). Marc-Andr?, if there are no objections, can I check this in? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 22:45 Message: Logged In: YES user_id=377356 and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? Woopsie. Thats correct and i missed that. I thought we were talking about the UTF-8 codec here. Then it's correct, that fixing readline() alone probably wont fix the issue. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 21:01 Message: Logged In: YES user_id=89016 > I checked the decoding_fgets function (and the enclosed call > to fp_readl). The patch is more problematic than i thought > since decoding_fgets not only takes a pointer to the token > state but also a pointer to a destination string buffer. > Reallocating the buffer within fp_readl would mean a very > very bad hack since you'd have to reallocate "foreign" > memory based on a pointer comparison (comparing the passed > string buffers pointer against tok->inp || tok->buf...). Maybe all pointers pointing into the buffer should be moved into a struct? > As it stands now, patching the tokenizer would mean changing > the function signatures or otherwise change the structure > (more error prone). All the affected function seem to be static, so at least in this regard there shouldn't be any problem. > Another possible solution would be to > provide a specialized readline() function for which the > assumption that at most size bytes are returned is correct. All the codecs would have to provide such a readline(). BTW, the more I look at your patch the more I think that it gets us as close to the old behaviour as we can get. > Oh and about that UTF-8 decoding. readline()'s size > restriction works on the already decoded string (at least it > should), so that shouldn't be an issue. I don't understand that. fp_readl() does the following two calls: buf = PyObject_Call(tok->decoding_readline, args, NULL); utf8 = PyUnicode_AsUTF8String(buf); and puts the resulting byte string into the char * passed in, so even if we fix the readline call the UTF-8 encoded string might still overflow the avaliable space. How can tokenizer.c be sure how much the foo->utf8 transcoding shrinks or expands the string? > Maybe another > optional parameter should be added to readline() called > limit=None which doesn't limit the returned string by > default, but does so if the parameter is a positive number. But limit to what? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 20:43 Message: Logged In: YES user_id=89016 > The problem with the change is that it applies to *all* > codecs. If only the UTF-16 codec has a problem with the > standard logic, it should override the .readline() > method as necessary, but this should not affect all > the other codecs. readline() had to be rewritten anyway to take the bytebuffer into account. True, the bytebuffer is only needed for UTF-8, UTF-16, UTF-16-LE, UTF-16-BE and maybe a few others, but unless we'd introduced a ByteBufferStreamReader that those codecs can subclass this would have meant code duplication. I'try to come up with a readline() patch (for the base class readline() next week. > >> BTW, the logic in read() looks rather convoluted to me >> now that a look at it a second time. Should we clean >> this up a bit? > > If that's possible, yes :-) Attached is a patch (fixread.diff) that makes read() a *little* simpler. Making it much simple breaks several tests. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-03 16:42 Message: Logged In: YES user_id=377356 I checked the decoding_fgets function (and the enclosed call to fp_readl). The patch is more problematic than i thought since decoding_fgets not only takes a pointer to the token state but also a pointer to a destination string buffer. Reallocating the buffer within fp_readl would mean a very very bad hack since you'd have to reallocate "foreign" memory based on a pointer comparison (comparing the passed string buffers pointer against tok->inp || tok->buf...). As it stands now, patching the tokenizer would mean changing the function signatures or otherwise change the structure (more error prone). Another possible solution would be to provide a specialized readline() function for which the assumption that at most size bytes are returned is correct. Oh and about that UTF-8 decoding. readline()'s size restriction works on the already decoded string (at least it should), so that shouldn't be an issue. Maybe another optional parameter should be added to readline() called limit=None which doesn't limit the returned string by default, but does so if the parameter is a positive number. Just my 0.2$ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 15:46 Message: Logged In: YES user_id=38388 >>In Python 2.3, the size parameter was simply passed down >>to the stream's .readline() method, so semantics were >>defined by the stream rather than the codec. > > > In most cases this meant that there were at most size bytes > read from the byte stream. It seems that tokenizer.c:fp_readl > () assumes that, so it broke with the change. > > >>I think that we should restore this kind of behaviour >>for Python 2.4.1. > > > That's not possible (switching back to calling readline() on the > bytestream), because it breaks the UTF-16 decoder, but we > can get something that is close. The problem with the change is that it applies to *all* codecs. If only the UTF-16 codec has a problem with the standard logic, it should override the .readline() method as necessary, but this should not affect all the other codecs. Unless, I'm missing something, the other codecs work just fine with the old implementation of the method. >>What was the reason why you introduced the change >>in semantics ? > > > 1) To get readline() to work with UTF-16 it's no longer > possible to call readline() for the byte stream. This has to be > replaced by one or more calls to read(). > > 2) As you say size was always just a hint. With line buffering > (which is required for UTF-16 readline) this hint becomes even > more meaningless. That's OK for the UTF-16 codec, but why the generic change in the base class ? > So I'd say: > > 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had > a problem in this spot anyway: There's an > > assert(strlen(str) < (size_t)size); /* XXX */ > > in the code, and a string *can* get longer when it's encoded > to UTF-8 which fp_readl() does. > > dark-storm, if you can provide a patch for this problem, go > ahead. +1 > 2) change readline(), so that calling it with a size parameter > results in only one call to read(). If read() is called with > chars==-1 (which it will in this case), this will in turn only call > read() for the byte stream once (at most). If size isn't > specified the caller should be able to cope with any returned > string length, so I think the current behaviour (calling read() > multiple times until a "\n" shows up) can be kept. +1 for UTF-16 I'm not sure whether the current implementation is needed for all other codecs. > BTW, the logic in read() looks rather convoluted to me now > that a look at it a second time. Should we clean this up a bit? If that's possible, yes :-) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-03 12:58 Message: Logged In: YES user_id=89016 > In Python 2.3, the size parameter was simply passed down > to the stream's .readline() method, so semantics were > defined by the stream rather than the codec. In most cases this meant that there were at most size bytes read from the byte stream. It seems that tokenizer.c:fp_readl () assumes that, so it broke with the change. > I think that we should restore this kind of behaviour > for Python 2.4.1. That's not possible (switching back to calling readline() on the bytestream), because it breaks the UTF-16 decoder, but we can get something that is close. > What was the reason why you introduced the change > in semantics ? 1) To get readline() to work with UTF-16 it's no longer possible to call readline() for the byte stream. This has to be replaced by one or more calls to read(). 2) As you say size was always just a hint. With line buffering (which is required for UTF-16 readline) this hint becomes even more meaningless. So I'd say: 1) Fix tokenizer.c:fp_readl(). It looks to me like the code had a problem in this spot anyway: There's an assert(strlen(str) < (size_t)size); /* XXX */ in the code, and a string *can* get longer when it's encoded to UTF-8 which fp_readl() does. dark-storm, if you can provide a patch for this problem, go ahead. 2) change readline(), so that calling it with a size parameter results in only one call to read(). If read() is called with chars==-1 (which it will in this case), this will in turn only call read() for the byte stream once (at most). If size isn't specified the caller should be able to cope with any returned string length, so I think the current behaviour (calling read() multiple times until a "\n" shows up) can be kept. BTW, the logic in read() looks rather convoluted to me now that a look at it a second time. Should we clean this up a bit? ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:38 Message: Logged In: YES user_id=377356 I forgot to reply to doerwalter's comment. *snip* I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. *snip* Linux is using a larger BUFSIZ for me. MUCH larger i have to add. MSVC used 512 bytes for me while the c standard library on my linux box defines BUFSIZ to be 8192 bytes long. That should suffice for looooong lines. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-02 22:35 Message: Logged In: YES user_id=377356 The problem here is that the tokenizer tries to read at most 512 bytes into its token buffer and then read another 512 bytes if the line isn't complete yet. At least that is what a quick look at the tokenizers freadln (or whatever the function the assert is in is called) function made me think. The problem here is that the tokens buffer either has to be reallocated (easy) or another solution has to be found. If the reallocation of the tokens buffer is sufficient, i can easily provide a patch for that. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-02 22:21 Message: Logged In: YES user_id=38388 Walter, your analysis is not quite right: the size parameter for .readline() was always just a hint and never intended to limit the number of bytes returned by the method (like the size parameter in .read()). In Python 2.3, the size parameter was simply passed down to the stream's .readline() method, so semantics were defined by the stream rather than the codec. I think that we should restore this kind of behaviour for Python 2.4.1. Any code which makes assumptions on the length of the returned data is simply broken. If the Python parser makes such an assumption it should be fixed. Again, the size parameter is just a hint for the implementation. It might as well ignore it completely. The reason for having the parameter is to limit the number of bytes read in case the stream does not include line breaks - otherwise, .readline() could end up reading the whole file into memory. What was the reason why you introduced the change in semantics ? I would have complained about it, had I known about this change (I only saw you change to .read() which was required for the stateful codecs). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-02 21:58 Message: Logged In: YES user_id=89016 I couldn't get Linux Python to crash or assert with the attached gurk.py, Windows Python crashed at i=70. The problem we have is that Python 2.4 changed the meaning of the size parameter in StreamReader.readline(). There are at least four possible interpretations: 1) Never read more than size bytes from the underlying byte stream in one call to readline() 2) Never read more than size characters from the underlying byte stream in one call to readline() 3) If calling readline() requires reading from the underlying byte stream, do the reading in chunks of size bytes. 4) Never return more than size characters from readline(), if there's no linefeed within size characters the result is a partial line. In Python 2.3 1) was used with the implicit assumption that this guarantees that the result will never be longer than size. You're patch looks like it could restore the old behaviour, but we'd loose the ability to reliably read a line until a "\n" is available without passing size=-1 into read() with would read the whole stream. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:36 Message: Logged In: YES user_id=377356 I attached the .diff file for my patch. I hope i got this right. ---------------------------------------------------------------------- Comment By: Sebastian Hartte (dark-storm) Date: 2004-12-01 21:32 Message: Logged In: YES user_id=377356 "Can you attach a proper diff for your changes to StreamReader.readline()?" I would like to, but i don't have access to a proper diff utility on windows. I will try to get one and then attach the diff file. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-12-01 20:13 Message: Logged In: YES user_id=89016 What I get when I execute your test.py on Windows is: --- Fatal Python error: GC object already tracked This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. --- Is this the expected failure? Can you attach a proper diff for your changes to StreamReader.readline()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076985&group_id=5470 From noreply at sourceforge.net Wed Dec 22 13:58:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 13:58:44 2004 Subject: [ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP Message-ID: Bugs item #1076861, was opened at 2004-12-01 17:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Martin v. L?wis (loewis) Summary: Bad IDLE shortcut by 2.4 installer on XP Initial Comment: There is a problem with the Python 2.4 installer on Windows XP. The IDLE shortcut set up by the installer in the StartUp folder does not work. If the shortcut is removed and recreated manually, it works fine. That was *after* a complete reinstall of Python 2.4 and after removing the previous version of Python 2.3 on the machine. With Python 2.3 present, the IDLE shortcut installed by Python 2.4 runs the 2.3 version. See also and ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:58 Message: Logged In: YES user_id=21627 This is now fixed in msi.py 1.19 and 1.16.2.3 ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-09 02:16 Message: Logged In: YES user_id=832557 One more piece of data. We installed Python 2.4 in directory "C:\Program Files\Python24". Maybe the space in the name is causing the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 23:13 Message: Logged In: YES user_id=21627 I've added an entry to http://www.python.org/2.4/bugs.html now and hope to fix the problem for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 From noreply at sourceforge.net Wed Dec 22 14:11:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 14:11:41 2004 Subject: [ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP Message-ID: Bugs item #1076861, was opened at 2004-12-01 17:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 Category: Installation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Martin v. L?wis (loewis) Summary: Bad IDLE shortcut by 2.4 installer on XP Initial Comment: There is a problem with the Python 2.4 installer on Windows XP. The IDLE shortcut set up by the installer in the StartUp folder does not work. If the shortcut is removed and recreated manually, it works fine. That was *after* a complete reinstall of Python 2.4 and after removing the previous version of Python 2.3 on the machine. With Python 2.3 present, the IDLE shortcut installed by Python 2.4 runs the 2.3 version. See also and ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:58 Message: Logged In: YES user_id=21627 This is now fixed in msi.py 1.19 and 1.16.2.3 ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2004-12-09 02:16 Message: Logged In: YES user_id=832557 One more piece of data. We installed Python 2.4 in directory "C:\Program Files\Python24". Maybe the space in the name is causing the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-08 23:13 Message: Logged In: YES user_id=21627 I've added an entry to http://www.python.org/2.4/bugs.html now and hope to fix the problem for 2.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470 From noreply at sourceforge.net Wed Dec 22 14:13:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 14:13:27 2004 Subject: [ python-Bugs-1085172 ] Uninstaller should restore file associations if possible Message-ID: Bugs item #1085172, was opened at 2004-12-14 16:13 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Martin v. L?wis (loewis) Summary: Uninstaller should restore file associations if possible Initial Comment: On installing on Windows, the Python installer associates .py and .pyw files to the new installation of python. The installer should cache the previous associations, and in the event of uninstallation restore them to their previous values if the application the are associated with still exists. This allows for easier migration back to 2.3 in this case, but also for easier back migration in the case of installing a beta version of python 2.5 or whatever in the future. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-16 14:09 Message: Logged In: YES user_id=21627 This is not possible to implement. If you want to not add associations for 2.4, you need to uncheck the "Register Extensions" feature in the installer UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085172&group_id=5470 From noreply at sourceforge.net Wed Dec 22 15:19:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 15:19:05 2004 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 19:21 Message generated for change (Comment added) made by akosprime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- >Comment By: A. Stocker (akosprime) Date: 2004-12-22 14:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Wed Dec 22 15:27:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 15:27:43 2004 Subject: [ python-Bugs-974757 ] urllib2's HTTPPasswordMgr and uri's with port numbers Message-ID: Bugs item #974757, was opened at 2004-06-17 14:09 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=974757&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chris Withers (fresh) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2's HTTPPasswordMgr and uri's with port numbers Initial Comment: Python 2.3.3 The title just about sums it up. If you add a password with a uri containing a port number using add_password, then it probably won't be returned by find_user_password. That's not right ;-) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-12-22 14:27 Message: Logged In: YES user_id=31392 Fixed in rev 1.78 of urllib2 ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-11-05 10:08 Message: Logged In: YES user_id=24723 This patch fixes it for me: --- urllib2.py.cvs Fri Nov 05 10:02:26 2004 +++ urllib2.py.new Fri Nov 05 10:05:48 2004 @@ -720,7 +720,7 @@ return self.retry_http_basic_auth(host, req, realm) def retry_http_basic_auth(self, host, req, realm): - user,pw = self.passwd.find_user_password(realm, host) + user,pw = self.passwd.find_user_password(realm, req.get_full_url()) if pw is not None: raw = "%s:%s" % (user, pw) auth = 'Basic %s' % base64.encodestring(raw).strip() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=974757&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:28:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:28:58 2004 Subject: [ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info Message-ID: Bugs item #1085300, was opened at 2004-12-14 13:43 Message generated for change (Comment added) made by unclewalrus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walrus (unclewalrus) Assigned to: Brett Cannon (bcannon) Summary: Mac Library Modules 1.1.1 Bad Info Initial Comment: Document states that OS X's TextEdit only saves RTF files. This is incorrect; you can make a plaintext file by choosing 'Make Plain Text' from the Format menu. ---------------------------------------------------------------------- >Comment By: Walrus (unclewalrus) Date: 2004-12-22 10:28 Message: Logged In: YES user_id=1178211 Mac Library Modules, section 1.1.1, about halfway down. http://www.python.org/doc/2.4/mac/node5.html ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-22 00:12 Message: Logged In: YES user_id=357491 Yes, it's true; RTF and plaintext are the two possible output. Walrus, where exactly in the docs does it claim this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:35 Message: Logged In: YES user_id=80475 Brett, can you verify this and, if true, add an appropriate note to the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:50:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:51:04 2004 Subject: [ python-Bugs-1067732 ] wininst --install-script leaves residual files on C:Mime-Version: 1.0 Message-ID: Bugs item #1067732, was opened at 2004-11-17 01:14 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067732&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: J Livingston (jlivingston) Assigned to: Thomas Heller (theller) Summary: wininst --install-script leaves residual files on C: Initial Comment: I'm running Python 2.3.4 and using distutils ( __revision__ of 1.58 2003/02/19) on WinXP SP2 to create a windows .exe installer. Both installation and removal of the package result in a residual file on the root of C: drive. This seems to be directly related to the use of the windows install-script which is provided with the --install-script switch. The residual file has a naming convention of sxxx where 'xxx' is any alphanumeric combination. There is never an extension on the file name. On installation, the residual file contains the same text the install-script prints in the install screen window. On removal, the residual file is empty (the install-script does not print anything when removing.) Users attempting to execute the installer from a network drive experience installer crash as they do not have file system permission to generate the residual file.. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-12-22 16:50 Message: Logged In: YES user_id=11105 Fixed with rev. 1.1.14.8 PC/bdist_wininst/install.c. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:51 Message: Logged In: YES user_id=21627 Thomas, can you take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067732&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:52:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:52:23 2004 Subject: [ python-Bugs-988022 ] bdist_wininst improvements Message-ID: Bugs item #988022, was opened at 2004-07-09 17:17 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988022&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: bdist_wininst improvements Initial Comment: bdist_wininst installed programs show a ridiculous size in the Add/Remove programs list. For example, py2exe reports 126 MB, and pywin32 reports 113 MB. This article explains why . ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-12-22 16:52 Message: Logged In: YES user_id=11105 No time nor interest any more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988022&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:54:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:54:10 2004 Subject: [ python-Bugs-600952 ] Installing w/o admin generates key error Message-ID: Bugs item #600952, was opened at 2002-08-27 21:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600952&group_id=5470 Category: Distutils Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phil Rittenhouse (prittenh) Assigned to: Thomas Heller (theller) Summary: Installing w/o admin generates key error Initial Comment: I encountered the following problem when trying to install a package I had generated with distutils (Python 2.2 on Win2k, logged in as a user without adminstrative priveleges): When the installer was run, it would go through the steps nicely, but towards the end, it generated two errors: "Could not open key Software\Microsoft\Windows\CurrentVersion\Unins tall" "Could not create key dsp-py2.1" At first I thought the problem might be the result of installing Python as Administrator, and the package as just a user, so I re-installed Python as a user, but I still got the same error. I ran my test on Win2K with both Python 2.1 and 2.2, and I always got the same result. I tracked the code generating the error to install.c in distutils-1.0.2/misc (see below). I did some digging and it appears that to use KEY_ALL_ACCESS, the code must be running with Administrator privileges. I checked the CVS archives to see if KEY_ALL_ACCESS is still being used, and it is. I made the following changes to install.c (from Distutils 1.0.2), recompiled, and it works now. 796c796 < KEY_CREATE_SUB_KEY, --- > KEY_ALL_ACCESS, 806c806 < KEY_WRITE, --- > KEY_ALL_ACCESS, 1177c1177 < KEY_WRITE, --- > KEY_ALL_ACCESS, 1208c1208 < KEY_WRITE, --- > KEY_ALL_ACCESS, I chose KEY_CREATE_SUB_KEY for the open, since that is the only operation that will be performed on it. For the new key itself, I chose KEY_WRITE, since that was also the minimal operation. While I was at it, I changed the code for deleting the registry key and value to also use the minimal KEY_WRITE. The last two changes allowed the uninstaller to work properly when run as a normal user. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-12-22 16:54 Message: Logged In: YES user_id=11105 I believe this is long fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=600952&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:55:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:55:48 2004 Subject: [ python-Bugs-848871 ] Windows installer halts Message-ID: Bugs item #848871, was opened at 2003-11-25 12:38 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jens Olsson (morr) Assigned to: Thomas Heller (theller) Summary: Windows installer halts Initial Comment: The Windows installer halts when starting to install files, more exactly when installing the file "UNWISE.EXE" and the progress bar reads "1%". Python versions tested: 2.2.3 2.3.1 2.3.2 2.3.2-1 All tested versions behave the same. Since I don't believe it's a common bug I attach selected computer specs for the system in question. I find it hard to believe it is the python windows installer by itself that contains the bug but since I haven't experienced this with any other installer I submit the bug anyway. It can't be my system by itself either. - Varying the installation options does not seem to help (non exhaustive testing done). - Running install on on specific processor (Hyper Threading is enabled) does not change things Test system summary (see attachment for full specs): Gigabyte 8KNXP motherboard, intel Northwood 3.0GHz HT, 2x512MB Corsair 3500, Radeon 9700 AIW, Seagate Barracuda 160GB, Windows XP Pro SP1a. Reproduction steps: 1. Launch installer 2. Click 'next' when asked for directory 3. Click 'next' when asked about backups 4. Click 'next' when asked for component selection 5. Click 'next' when asked for start menu group selection 6. Click 'next' when prompted with the "ready to install" screen 7. Observere bug ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-12-22 16:55 Message: Logged In: YES user_id=11105 No time to struggle with WISE. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-25 20:14 Message: Logged In: YES user_id=11105 Nope, there isn't really progress. I spend some time in the wise support news group, but didn't really get a useful answer. I have to limit the time I spend on this. IMO a better thing would be to bring the innosetup script in CVS up to date with the current inno version - they are at 4.1.x currently, and add code for the missing features. I have the impression that innosetup is powerful enough to handle all that is needed. The only downside would that probably Python 2.3.4 will be the only version using this installer, since 2.4 will be released as MSI file. ---------------------------------------------------------------------- Comment By: Jens Olsson (morr) Date: 2004-02-24 10:29 Message: Logged In: YES user_id=917179 Any news on this one? Latest version behaves the same. Is there any alternative Windows install procedure that is reasonable easy to perform? ---------------------------------------------------------------------- Comment By: Jens Olsson (morr) Date: 2003-12-10 12:38 Message: Logged In: YES user_id=917179 I couldn't update comments and didn't have time to figure out how I should do it so I hope this attached file will do. Follow up: I ran the installer with the suggested /m1 option. The install asked for the following directories (in order): windows system system32 temp source All input boxes had default values which seemed reasonable so I left them unchanged. Then the actual installer window showed (as without /m1). After submitting the requested information (as reported in the inital bugreport) the installer halted when the small window titled "installing" showed, at 1% and the file unwise.exe... just as before. No question about registring files (besides the five windows promting for manual input of directories as described above). No error messages. Just the same behaviour as before with some additional directory prompting dialoges at the beginning. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 20:49 Message: Logged In: YES user_id=11105 Here is advice I got from a Wise rep: """ This sounds like it is hanging at the point that the install is trying to self register files. You can test this by running the setup.exe with a /m1. This will run the install in manual mode, and prompt when each file is trying to self register. This will indicate which file it is trying to self register, and then the error message. """ Can you try this, please, and report the result? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-03 21:58 Message: Logged In: YES user_id=11105 I've asked in the WISE support news group for help, I've also seen similar behaviour in other software built with WISE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:56:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:56:17 2004 Subject: [ python-Bugs-895567 ] os.listdir fails for pathprefix \?\d:... Message-ID: Bugs item #895567, was opened at 2004-02-12 10:15 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Guenter Kruschina (kruschina) >Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir fails for pathprefix \?\d:... Initial Comment: The function os.listdir() fails with arguments beggining with \?\... . This is necessary under windows to switch off pathchecking for all Win32-Widecharacter functions. The problem is located in the posixmodule. A diff -u will show the solution for this problem: --- posixmodule.c 2004-01-30 16:51:18.768574400 +0100 +++ posixmodule.c.org 2003-12-03 02:21:01.000000000 +0100 @@ -1386,7 +1386,7 @@ len = wcslen(wnamebuf); wch = (len > 0) ? wnamebuf[len-1] : L'\0'; if (wch != L'/' && wch != L'\' && wch != L':') - wnamebuf[len++] = L'\'; + wnamebuf[len++] = L'/'; wcscpy(wnamebuf + len, L"*.*"); if ((d = PyList_New(0)) == NULL) return NULL; By the way: The functions isdir..isfile...etc also does not work with the pathprefix \? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:56:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:57:08 2004 Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings Message-ID: Bugs item #781614, was opened at 2003-08-01 19:04 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) >Assigned to: Nobody/Anonymous (nobody) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-18 21:18 Message: Logged In: YES user_id=11105 Potentially dangerous - of course. The question is whether this is responsible for some bugs or not. If we cannot link to the DLL then we have to change the build settings for the static builds of libdb41s.lib. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-18 20:58 Message: Logged In: YES user_id=21627 I think we should avoid linking with the DLL if possible; in some application context, it may be impossible to find the DLL dynamically, or there might be confusion which DLL to load. The linker warning means that there is a conflict between the static (libc.a) and dynamic (msvcr71.dll) version of _free, etc, which potentially means that we are linking conflicting copies of the CRT, which is potentially dangerous. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-18 18:41 Message: Logged In: YES user_id=11105 It looks to me like we could link to the import library build_win32\Release\libdb41.lib instead of the static library build_win32\Release_static\libdb41s.lib. The former is built with 'multithreaded dll' flags. The downside is that libdb41.dll plus MSVCP60.DLL would have to be distributed. Are the linker warnings a real problem, or only cosmetical? Of course we have to update the build procedure for 2.4 anyway... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-17 00:54 Message: Logged In: YES user_id=31435 Thomas, you have any insight into this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 21:50 Message: Logged In: YES user_id=21627 Can you propose a specific patch? Also, it would be preferable if changing the source code of the Sleepycat distribution would not be necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 From noreply at sourceforge.net Wed Dec 22 16:57:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 16:57:59 2004 Subject: [ python-Bugs-886492 ] Python 2.2.3 crashes using popen2 to spawn lots of children Message-ID: Bugs item #886492, was opened at 2004-01-28 21:33 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frank Terhaar-Yonkers (frankty) >Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.2.3 crashes using popen2 to spawn lots of children Initial Comment: WinPython 2.3.3 crashes when using popen2 to spawn *lots* of children > 100. Running the test case on either W2k or Wxp causes Python 2.3.3 to crash. Looking at the drwatson file, it appears to be a race condition where the child is in the process of crashing, while the popen2 code in posixmodule.c is attempting to PyFile_SetBufSize() on one of the pipes. Evil juju in ntdll.dll .. I've no idea what system resource is being exhausted (heap memory?) causing the crash. If you look at the hacks in posixmodule.c, the Python crash can be eliminated by simply commenting out the calls to PyFile_SetBufSize. There is still the problem of resource exhaustion. To gain more child processes I included a hack such that with the setting of an env-var (NOPYCMD) popen2 will NOT use cmd.exe /c to run a child, but simply run the child command as passed (yeah, I know that is has to be an absolute path or in the CWD then ..). I'm sure there is a better way to eliminate the cmd.exe /c - like maybe a new method: popen2.popenXabspath .. In any case, it appears we have an NT kernel bug combined with an inefficient way of doing popen2 that is making a mess. I started doing some exploration of heap_chunk_size to attack to resource issue but haven't gotten very far. As for *why* I'm doing this, it's because we're using Pyton as a system simulator tool to emulate a large pile of PCs. The actual work *must* be done by external .exe code that cannot be changed. The attached zip contains a test case, the posixmodule hack, drwatson file and a sample program written in VisC++ which does basically the same as the Python test case. cheers, - Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=886492&group_id=5470 From noreply at sourceforge.net Wed Dec 22 19:53:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 19:53:46 2004 Subject: [ python-Feature Requests-1089955 ] optparse .error() should print options list Message-ID: Feature Requests item #1089955, was opened at 2004-12-22 18:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1089955&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: optparse .error() should print options list Initial Comment: Why doesn't optparse.OptionParser.error() print the list of correct options along with the error message and usage? This is what the user needs to know whenever there's an error. One can override this in a subclass, but it's frustrating to have to do it every time. To do this, change the first line in OptionParser.error() from: self.print_usage(sys.stderr) to: self.print_help(sys.stderr) print >>sys.stderr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1089955&group_id=5470 From noreply at sourceforge.net Wed Dec 22 20:00:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 20:00:53 2004 Subject: [ python-Bugs-1066490 ] special methods become static Message-ID: Bugs item #1066490, was opened at 2004-11-14 23:46 Message generated for change (Comment added) made by kquick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&group_id=5470 Category: Type/class unification Group: Python 2.3 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Michael Hudson (mwh) Summary: special methods become static Initial Comment: This *may* be a duplicate of 729913, but there's either additional info here, or this is actually different. The issue is that any special method (e.g. __call__, __str__, etc.) defined for a new-style (i.e. object-based) class seems to be static (i.e. unchangeable) with some special lookup applied for that method, but this doesn't seem to be the case for regular methods. class A: def foo(self): return 1 def __call__(self): return 2 def bar(self): return 3 def adjust(self): self.foo = self.bar self.__call__ = self.bar a = A() print a.foo(), a() a.adjust() print a.foo(), a() Will print: 1 2 3 3 But if the A is turned into a new-style class by changing the first line: class A(object): then the printed results are: 1 2 3 2 To the best of my understanding of the migration from classic classes to new-style classes (and metaclassing), this shouldn't occur. I have also tried various name munging for the special method (e.g. setting _B__call__, using setattr, etc.), but I haven't found the special trick yet. The attached script shows the example in more detail. ---------------------------------------------------------------------- >Comment By: Kevin Quick (kquick) Date: 2004-12-22 12:00 Message: Logged In: YES user_id=6133 Thanks for the clarifcation. However IMHO it is wrong to have different behavior for different methods. To wit, if I defined a method, it is a bound method, and ergo a "self" initial argument is automatically supplied. However, a __repr__, even though I define it, acts as an unbound method, with the self argument having a default of the current instance but overrideable if an argument is supplied on the call. This means that the argument evaluation/passing is different for these types of builtins as opposed to other methods, both of which I have defined myself. This just doesn't seem right to me, which is why I'm re-opening this bug report... sorry to be annoying, but this definitely seems inconsistent and a better explanation. My current workaround is to do the following: class foo: def __str__(self): return my_str() def my_str(self): return 'something' So that I can do "foo.my_str = lambda self: return 'something else'". When what I should be able to do is: class foo: def __str__(self): return 'something' ... foo.__str__ = lambda self: return 'something else' ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 01:22 Message: Logged In: YES user_id=6656 Oh, sorry, I think I got that a bit wrong. The issue is more with bound/unbound methods -- given class O(object): def __repr__(self): ... should O.__repr__ be a bound method (O is an instance of type) or an unbound method so O.__repr__(O()) does what you expect? Python chooses the latter, but this means that you can't implement the builtin function repr as def repr(o): return o.__repr__() Hope this helps, a little at least. ---------------------------------------------------------------------- Comment By: Kevin Quick (kquick) Date: 2004-11-15 07:29 Message: Logged In: YES user_id=6133 OK, I didn't find anything documenting this change anywhere (obviously). I read Guido's description of new-classes (www.python.org/2.2/descrintro.py) and the various documentation, but either I overlooked it therein or it's talked about somewhere else. I'm curious as to why special methods are treated specially in regards to this lookup. Specifically for your example, why wouldn't you just use the __repr__ attribute of o if it exists, instead of o's class, just like it does for non-special methods? Can you briefly explain this or provide me with a reference? Leaving this closed is OK with me since it's apparently known and expected... I'd just like to understand it a bit better. Sorry for the bandwidth, and Thanks! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-15 00:16 Message: Logged In: YES user_id=6656 The change you are observing is that special methods are now only looked up on the *class* of the object concerned. This, or something like this is actually unavoidable -- in >>> repr(o) what do you do if both o and the type of o define a __repr__ method? There are articles on new-style classes out there that should explain this in more depth. It probably could/should be documented better in the core -- there are bugs open to that effect already. Closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066490&group_id=5470 From noreply at sourceforge.net Wed Dec 22 20:22:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 20:22:32 2004 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-22 14:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Wed Dec 22 20:27:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 20:27:23 2004 Subject: [ python-Bugs-1089978 ] exec scoping problem Message-ID: Bugs item #1089978, was opened at 2004-12-22 12:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089978&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: exec scoping problem Initial Comment: Python 2.3.3 (#1, Oct 18 2004, 16:10:24) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Using exec on a code object with an "in ..." statement to specify locals and globals does not appear to set the globals for any code objects called by the exec'd code object. As a workaround, I can exec a file object containing the relevant code objects and the scope appears to work, although the following issues are noted (these are possibly separate bugs, but all demonstrated by the attached... let me know if you'd like separate bugreport submissions, but I figured it was easiest to start with one in case I'm way off base in some fundamental way). 1. exec won't process an opened .pyc file, only a .py file. However, the module's __file__ attribute will specify the .pyc or the .py, depending on which one is more recent. This forces me to reset the extension to .py at all times. It also means that if I use this technique I must ensure that the .py is always available relative to the .pyc. 2. The exec'd file needs the addition of a "if __name__ == '__main__'" to invoke the functionality I want. This makes sense for exec'ing a file, but because I'm forced to exec the file to get globals scoped as I wanted, rather than using the code object, I am then limited to that single function invocation for any __name__ == "__main__" invocation of the file. 3. Specifying "in locals()" for the code object invocation has no adverse (or positive) effect, but specifying it for the file object seems to cause the interpreter to recurse the *current* file, not the exec'd file (this is Test #5 in the attachment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089978&group_id=5470 From noreply at sourceforge.net Wed Dec 22 23:23:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 22 23:23:36 2004 Subject: [ python-Bugs-1090076 ] Defaults in ConfigParser.get overrides section values Message-ID: Bugs item #1090076, was opened at 2004-12-22 19:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: Defaults in ConfigParser.get overrides section values Initial Comment: ConfigParser.get has an optional argument vars that - according to the docstring- "which must be a dictionary whose contents overrides any pre-existing defaults." I understand that it overrides the default values, but should not override an actual value existing in the file. That is, given this contents: [DEFAULT] key1=default1 [section] key2=value2 vars={'key1:vars1','key2:vars2'} cfg.get('section','key1',0,vars) gives 'vars1' (ok) cfg.get('section','key2',0,vars) gives 'vars2' (wrong, should be 'value2', since key2 is actually in the section and no default is needed). To correct this behavior, simply move this two lines of code up in ConfigParser.get (ConfigParser.py), just below the first line and before the first try/except: # Update with the entry specific variables if vars is not None: d.update(vars) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090076&group_id=5470 From noreply at sourceforge.net Thu Dec 23 02:00:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 02:00:23 2004 Subject: [ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called Message-ID: Bugs item #1090139, was opened at 2004-12-22 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) Assigned to: Nobody/Anonymous (nobody) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text:
args
should be changed to:
args
to match the rest of the items on the page. This may require changing the LaTeX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 From noreply at sourceforge.net Thu Dec 23 16:19:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 16:20:02 2004 Subject: [ python-Bugs-973507 ] sys.stdout problems with pythonw.exe Message-ID: Bugs item #973507, was opened at 2004-06-15 22:34 Message generated for change (Comment added) made by pfremy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973507&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdout problems with pythonw.exe Initial Comment: >>> sys.version '2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]' >>> sys.platform 'win32' >>> sys.getwindowsversion() (5, 1, 2600, 2, '') Hi. I have written this script for reproducing the bug: import sys class teeIO: def __init__(self, *files): self.__files = files def write(self, str): for i in self.__files: print >> trace, 'writing on %s: %s' % (i, str) i.write(str) print >> trace, '-' * 70 def tee(*files): return teeIO(*files) log = file('log.txt', 'w') err = file('err.txt', 'w') trace = file('trace.txt', 'w') sys.stdout = tee(log, sys.__stdout__) sys.stderr = tee(err, sys.__stderr__) def write(n, width): sys.stdout.write('x' * width) if n == 1: return write(n - 1, width) try: 1/0 except: write(1, 4096) [output from err.log] Traceback (most recent call last): File "sys.py", line 36, in ? write(1, 4096) File "sys.py", line 28, in write sys.stdout.write('x' * width) File "sys.py", line 10, in write i.write(str) IOError: [Errno 9] Bad file descriptor TeeIO is needed for actually read the program output, but I don't know if the problem is due to teeIO. The same problem is present for stderr, as can be seen by swapping sys.__stdout__ and sys.__stderr__. As I can see, 4096 is the buffer size for sys.stdout/err. The problem is the same if the data is written in chunks, ad example: write(2, 4096/2). The bug isn't present if I use python.exe or if I write less than 4096 bytes. Thanks and regards Manlio Perillo ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2004-12-23 16:19 Message: Logged In: YES user_id=233844 Manlio, thanks a lot for the tip. I ran into the same problem (a program that can both be used with python.exe and pythonw.exe). I will apply your fix. I think that the fix should be applied somehow to pythonw.exe, so that it does something more understandable to the user. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2004-06-20 15:39 Message: Logged In: YES user_id=1054957 Thanks for sys.executable and 'nul' hints! I only want to add two notes: 1) isrealfile(file('nul')) -> True So 'nul' has a 'real' implementation 2) sys.executables isn't very useful for me, since I can do: pythonw ascript.py > afile In this case sys.stdout is a 'real file', so I don't want to redirect it to a null device. In all cases, isrealfile work as I want. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-20 05:13 Message: Logged In: YES user_id=31435 Just noting that "the usual" way to determine whether you're running under pythonw is to see whether sys.executable.endswith("pythonw.exe") The usual way to get a do-nothing file object on Windows is to open the special (to Windows) file named "nul" (that's akin to opening the special file /dev/null on Unixish boxes). Note that file('nul').fileno() does return a handle on Windows, despite that it's not a file in the filesystem. ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2004-06-18 18:42 Message: Logged In: YES user_id=1054957 I have found a very simple patch. First I have implemented this function: import os def isrealfile(file): """ Test if file is on the os filesystem """ if not hasattr(file, 'fileno'): return False try: tmp = os.dup(file.fileno()) except: return False else: os.close(tmp); return True Microsoft implementation of stdout/err/in when no console is created (and when no pipes are used) actually are not 'real' files. Then I have added the following code in sitecustomize.py: import sys class NullStream: """ A file like class that writes nothing """ def close(self): pass def flush(self): pass def write(self, str): pass def writelines(self, sequence): pass if not isrealfile(sys.__stdout__): sys.stdout = NullStream() if not isrealfile(sys.__stderr__): sys.stderr = NullStream() I have tested the code only on Windows XP Pro. P.S. isrealfile could be added in os module. Regards Manlio Perillo ---------------------------------------------------------------------- Comment By: Manlio Perillo (manlioperillo) Date: 2004-06-16 19:05 Message: Logged In: YES user_id=1054957 The problem with this bug is that I have a script that can be executed both with python.exe that with pythonw.exe! How can I know if stdout is connected to a console? I think a 'patch' would be to replace sys.stdout/err with a null stream instead of using windows stdout/err implementation. If fileno can't be implemented, it should not be a problem. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-16 01:09 Message: Logged In: YES user_id=31435 Ya, this is well known, although it may not be documented. pythonw's purpose in life is *not* to create (or inherit) a console window (a "DOS box"). Therefore stdin, stdout, and stderr aren't attached to anything usable. Microsoft's C runtime seems to attach them to buffers that aren't connected to anything, so they complain if you ever exceed the buffer size. The short course is that stdin, stdout and stderr are useless in programs without a console window, so you shouldn't use them. Or you should you install your own file-like objects, and make them do something useful to you. I think it would be helpful if pythonw did something fancier (e.g., pop up a window containing attempted output), but that's in new-feature terrority, and nobody has contributed code for it anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973507&group_id=5470 From noreply at sourceforge.net Thu Dec 23 17:41:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 17:41:15 2004 Subject: [ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called Message-ID: Bugs item #1090139, was opened at 2004-12-22 20:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) >Assigned to: Raymond Hettinger (rhettinger) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text:
args
should be changed to:
args
to match the rest of the items on the page. This may require changing the LaTeX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 From noreply at sourceforge.net Thu Dec 23 17:57:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 17:57:21 2004 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-22 11:22 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-23 08:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Thu Dec 23 20:39:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 20:39:59 2004 Subject: [ python-Bugs-1048495 ] Memory leaks? Message-ID: Bugs item #1048495, was opened at 2004-10-16 17:49 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048495&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Roman Mamedov (romanrm) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leaks? Initial Comment: Open python command-line interpreter. Enter: >>> a = range (10000000) Observe Python memory usage. 20 Mb real, 159 Mb virtual memory here(I'm on windows). Enter: >>> a = 0 Observe memory usage again. 120 mb real/120 mb virtual. OK, this is a garbage collected language, lets try to garbage-collect. >>> import gc >>> gc.collect() 0 That didn't help. The memory usage is still at 120/120. So, the question is, when that "range" object will get deleted, or how to do delete it manually? Why garbage collection doesn't get rid of "orphaned" objects? Any comments? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-23 14:39 Message: Logged In: YES user_id=80475 Closing because there is no bug here. You're welcome to submit a patch attempting to improve memory utilization while keeping int/float performance constant. ---------------------------------------------------------------------- Comment By: Roman Mamedov (romanrm) Date: 2004-10-17 13:50 Message: Logged In: YES user_id=943452 Thank you very much for a detailed explaination. In my opinion, this issue deserves more attention and consideration. There's a trend to create not just simple fire-off/throw-away scripts, but complex, long-running, GUI software in Python(as well as in other scripting/VM languages), and this tradeoff could make memory usage unnecessary high in not-so-rare usage patterns. That way, a split-second gain caused by having immortal integers could easily be eaten by VM trashing due to overconsumption of memory. I believe that comparable integer/float performance can be attained even without having these types as infinitely-immortal. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-10-16 19:04 Message: Logged In: YES user_id=31435 range() constructs a list. The list takes 4 bytes/entry, so you get about 40MB reclaimed when the list goes away. The space for integer objects happens to be immortal, though, and the approximately 12 bytes per integer doesn't go away. Space for floats is also immortal, BTW. There aren't easy resolutions. For example, the caching of space for integer objects in a dedicated internal int freelist speeds many programs. And if Python didn't do special memory allocation for ints, malloc overhead would probably boost the memory burden in your example to 16 bytes/int. So there are tradeoffs. Note that xrange() can usually be used instead to create one integer at a time (instead of creating 10 million simultaneously). Then the memory burden is trivial. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1048495&group_id=5470 From noreply at sourceforge.net Thu Dec 23 23:08:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 23:08:38 2004 Subject: [ python-Bugs-991754 ] _bsddb segfault Message-ID: Bugs item #991754, was opened at 2004-07-15 17:27 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jim Fulton (dcjim) Assigned to: Gregory P. Smith (greg) Summary: _bsddb segfault Initial Comment: I have to remove the _bsddb extension to run the Python tests. Otherwise I get a segfault when test_anydbm is run. I also get a segfault running test_bsddb uname -r 2.4.22-1.2188.nptlsmp rpm -q db4 db4-4.1.25-14 gdb ./python GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r -E -tt ./Lib/test/regrtest.py -vv test_bsddb Starting program: /home/jim/src/python/cvs2/dist/src/python -E -tt ./Lib/test/regrtest.py -vv test_bsddb [Thread debugging using libthread_db enabled] [New Thread -1084317568 (LWP 19122)] test_bsddb test__no_deadlock_first (test.test_bsddb.TestBTree) ... ERROR Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1084317568 (LWP 19122)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () (gdb) r -E -tt ./Lib/test/regrtest.py -vv test_anydbm The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/jim/src/python/cvs2/dist/src/python -E -tt ./Lib/test/regrtest.py -vv test_anydbm [Thread debugging using libthread_db enabled] [New Thread -1084645248 (LWP 19132)] test_anydbm test_anydbm_creation (test.test_anydbm.AnyDBMTestCase) ... ERROR Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1084645248 (LWP 19132)] 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () ---------------------------------------------------------------------- >Comment By: Jim Fulton (dcjim) Date: 2004-12-23 22:08 Message: Logged In: YES user_id=73023 That seems to have fixed it, at least for me. The tests run without seg-faulting and I can even import bsddb. :) Thanks. P.S. I only tested the head. Lemme know if you want be to test the 2.4 branch. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2004-12-13 12:07 Message: Logged In: YES user_id=413 I just rewrote the setup.py section that finds the header and library file for use when building the bsddb module. Previously it could pick different versions of the header + lib which would compile and link fine but fail at runtime. Its checked in to HEAD. Could you try that out and let me know if that fixes anything for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470 From noreply at sourceforge.net Thu Dec 23 23:14:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 23:14:50 2004 Subject: [ python-Bugs-980352 ] coercion results used dangerously Message-ID: Bugs item #980352, was opened at 2004-06-26 17:26 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980352&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: coercion results used dangerously Initial Comment: The C core uses the result of PyNumber_CoerceEx() dangerously: it gets passed to tp_compare, and most tp_compare slots assume they get two objects of the same type. This assumption is never checked, even when a user-defined __coerce__() is called: >>> class X(object): ... def __coerce__(self, other): ... return 4, other ... >>> slice(1,2,3) == X() Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-12-23 22:14 Message: Logged In: YES user_id=4771 Patch applied. ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 14:15 Message: Logged In: YES user_id=908995 I just filed patch #995939 which should address this. A review would be appreciated. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-26 22:42 Message: Logged In: YES user_id=80475 I looked back at one of my ASPN recipes, http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/265894 , and saw that the use of __coerce__ dramatically simplified the code. Also, the API for rich comparisons is not only complex, but it is not entirely sef-consistent. See Tim's "mini-bug" comment in sets.py for an example. IOW, I think it is premature to pull the plug. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2004-06-26 19:21 Message: Logged In: YES user_id=35752 This bug should obviously get fixed but in long term I think __coerce__ should go away. Do you think deprecating it for 2.4 and then removing support for it in 2.5 or 2.6 is feasible? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980352&group_id=5470 From noreply at sourceforge.net Thu Dec 23 23:35:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 23:35:44 2004 Subject: [ python-Bugs-1089978 ] exec scoping problem Message-ID: Bugs item #1089978, was opened at 2004-12-22 19:27 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089978&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Kevin Quick (kquick) Assigned to: Nobody/Anonymous (nobody) Summary: exec scoping problem Initial Comment: Python 2.3.3 (#1, Oct 18 2004, 16:10:24) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Using exec on a code object with an "in ..." statement to specify locals and globals does not appear to set the globals for any code objects called by the exec'd code object. As a workaround, I can exec a file object containing the relevant code objects and the scope appears to work, although the following issues are noted (these are possibly separate bugs, but all demonstrated by the attached... let me know if you'd like separate bugreport submissions, but I figured it was easiest to start with one in case I'm way off base in some fundamental way). 1. exec won't process an opened .pyc file, only a .py file. However, the module's __file__ attribute will specify the .pyc or the .py, depending on which one is more recent. This forces me to reset the extension to .py at all times. It also means that if I use this technique I must ensure that the .py is always available relative to the .pyc. 2. The exec'd file needs the addition of a "if __name__ == '__main__'" to invoke the functionality I want. This makes sense for exec'ing a file, but because I'm forced to exec the file to get globals scoped as I wanted, rather than using the code object, I am then limited to that single function invocation for any __name__ == "__main__" invocation of the file. 3. Specifying "in locals()" for the code object invocation has no adverse (or positive) effect, but specifying it for the file object seems to cause the interpreter to recurse the *current* file, not the exec'd file (this is Test #5 in the attachment). ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-12-23 22:35 Message: Logged In: YES user_id=4771 This is actually all expected behavior, although the test 5 suprised me much at first, because there should be no difference at all between test 4 and test 5: the "in locals()" has no effect. In fact, there is no difference. You can add or remove "in locals()" in both tests 4 and 5 and it's always test 5 (i.e. the second time the same test) that fails. The reason is a bit subtle. Specifying a globals in exec is "not recursive", so to say, because every function call executes the callee in the globals where it was originally defined. These globals are attached to the function object (but not to the code object). So tests 2 and 3 (which are exactly equivalent) strip naked the code of greet and run it into a globals where it was not expected to be; it's as if you took the source code of the function and pasted it in place of the exec. It finds globalvar in the current module, and it also finds show_globalvar() because you imported it in the line "from submod import *", but this calls the unmodified show_globalvar() in submod.py, hence the NameError. If you wanted so-called recursive custom globals, all functions calls would have to be replaced by exec's. I assume you know that using classes and instances looks like a much cleaner solution... Now test 4 passes because it's as if you had pasted the whole source code of submod.py there. In particular, you are creating a new version of all the functions, which live in the execprob module. Now when test 5 runs, the expression 'greet.__module__' has a new meaning: 'greet' is now the name of the function defined in the current module by the test 4... so now 'greet.__module__' actually names the current module, and you're executing the current module recursively. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089978&group_id=5470 From noreply at sourceforge.net Thu Dec 23 23:55:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 23 23:55:17 2004 Subject: [ python-Feature Requests-985094 ] getattr(object, name) accepts only strings Message-ID: Feature Requests item #985094, was opened at 2004-07-04 23:21 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=985094&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: getattr(object,name) accepts only strings Initial Comment: getattr(object,name) function accepts only strings. This behavior prohibits some interesting usage of callables as names in database column and field references. For example: Someone references a database field: value=record.field_name Programmatically, when name is the name of the field: value=getattr(record,field_name) Calculated fields could be implemented by passing a callable as a field name: def fn(record): return '%s (%s)'%(record.name,record.number) value=getattr(record,fn) The database backend checks if the name is callable and then call the name with the record. But this cannot be implemented in the simple way if getattr checks if the name is a string or not. This is an unneccessary check in getattr, setattr and delattr, since prevents interesting solutions. Temporary workaround: value=record.__getattr__(fn) There can be many unneccessary type checks and limitations in core and library functions. They should be removed to allow free usage. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-12-23 22:55 Message: Logged In: YES user_id=4771 This is in part due to historical reasons. I guess you know about "property"? This is exactly what database people usually call calculated fields. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=985094&group_id=5470 From noreply at sourceforge.net Fri Dec 24 00:46:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 00:46:46 2004 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 11:07 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Fri Dec 24 00:50:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 00:50:15 2004 Subject: [ python-Bugs-1071597 ] configure problem on HP-UX 11.11 Message-ID: Bugs item #1071597, was opened at 2004-11-23 11:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Harri Pasanen (harripasanen) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem on HP-UX 11.11 Initial Comment: Python 2.4c1 has this problem (but if I recall, so did 2.3.3)_ Using gcc 3.3.3 to build on HP-UX 11.11, the configure out of the box is a bit off, resulting in a failed build, due to missing thread symbols: /usr/ccs/bin/ld: Unsatisfied symbols: PyThread_acquire_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_exit_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_allocate_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_free_lock (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_start_new_thread (first referenced in libpython2.4.a(threadmodule.o)) (code) PyThread_release_lock (first referenced in libpython2.4.a(import.o)) (code) PyThread_get_thread_ident (first referenced in libpython2.4.a(import.o)) (code) PyThread__init_thread (first referenced in libpython2.4.a(thread.o)) (code) collect2: ld returned 1 exit status A workaround is to manually edit pyconfig.h, adding #define _POSIX_THREADS (The reason it is not picked up is that unistd.h on HP-UX has this comment: /************************************************************************ * The following defines are specified in the standard, but are not yet * implemented: * * _POSIX_THREADS can't be defined until all * features are implemented ) The implementation seems however to be sufficiently complete to permit compiling and running Python with _POSIX_THREADS. While I'm editing pyconfig.h, I also comment out _POSIX_C_SOURCE definition, as it will result in lots of compilation warnings, of the style: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Python-2.4c1/Include -DPy_BUILD_CORE -o Objects/frameobject.o ../Python-2.4c1/Objects/frameobject.c In file included from ../Python-2.4c1/Include/Python.h:8, from ../Python-2.4c1/Objects/frameobject.c:4: pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined :6:1: warning: this is the location of the previous definition ------------ So, to recapitulate: After configure, add #define _POSIX_THREADS and comment out #define _POSIX_C_SOURCE 200112L That will give you a Python working rather well, with "make test" producing: 251 tests OK. 1 test failed: test_pty 38 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on hp-ux11: test_tcl ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-24 00:50 Message: Logged In: YES user_id=21627 Can you find out why gcc says that "_POSIX_C_SOURCE" is defined on the command line? On the command line you provide, it isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470 From noreply at sourceforge.net Fri Dec 24 03:35:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 03:35:49 2004 Subject: [ python-Bugs-1089632 ] _DummyThread() objects not freed from threading._active map Message-ID: Bugs item #1089632, was opened at 2004-12-22 02:07 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: saravanand (saravanand) Assigned to: Nobody/Anonymous (nobody) Summary: _DummyThread() objects not freed from threading._active map Initial Comment: Problem Background: =============== I have Python Server module (long running) which accepts calls from several Python Clients over socket interface and forwards the call to a C++ component. This C++ component gives the reponses back to Python Server in a separate thread(created by C++ module) via callback. In the Python Callback implementation, the responses are sent to client in a synchronised manner using Python primitive threading.Semaphore. This Synchronisation is required as the C++ component can deliver parallel responses in different C++ threads. Here, the Python Server creates the semaphore object per client when the client request arrives (in Python thread). This same object is acquired & released in the C++ callback thread(s). Here we observed that Windows Events are getting created whenever the acquire method is executed in the Python Callback implementation in the context of C++ thread. But the same event is not freed by the Python Interpreter even after the termination of the C++ thread. Because of this, a Windows Event handles are getting leaked in the Python Server. Problem Description: ============== When we checked the Python module threading.py, we found that, every time a non-python thread (in our case C++ created thread), enters python and accessesn a primitive in threading module (eg: Semaphore, RLock), python looks for an entry for this thread in the _active map using thread ID as the Key. Since no entry exists for such C++ created threads, a _DummyThread object is created and added to the _active map for this C++ thread. For every _DummyThread object that is created, there is a corresponding Windows Event also getting created. Since this entry is never removed from the _active map even after the termination of the C++ thread ( as we could make out from the code in threading.py),for every "unique" C++ thread that enters python, a Windows Event is allocated and this manifests as continuous increase in the Handle count in my Python server ( as seen in Windows PerfMon/Task Manager). Is there a way to avoid this caching in Python Interpreter? Why cant Python remove this entry from the map when the C++ thread terminates. Or if Python can't get to know about the thread termination, should it not implement some kind of Garbage collection for the entries in this Map (especially entries for the _DummyThread objects). Does this require a correction in Python modulethreading.py? or is this caching behaviour by design? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-23 18:35 Message: Logged In: YES user_id=357491 Yes, it is by design. If you read the source you will notice that the comment mentions that the _DummyThread object is flagged as a daemon thread and thus should not be expected to be killed. The comment also mentions how they are not garbage collected. As stated in the docs, dummy threads are of limited functionality. You could cheat and remove the entries yourself from threading._active, but that might not be future-safe. I would just make sure that all threads are created through the threading or thread module, even if it means creating a minimal wrapper in Python for your C++ code to call through that to execute your C++ threads. If you want the docs to be more specific please feel free to submit a patch for the docs. Or if you can come up with a good way for the dummy threads to clean up after themselves then you can also submit that. But since the source code specifies that this expected and the docs say that dummy threads are of limited functionality I am closing as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089632&group_id=5470 From noreply at sourceforge.net Fri Dec 24 03:43:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 03:43:17 2004 Subject: [ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info Message-ID: Bugs item #1085300, was opened at 2004-12-14 10:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walrus (unclewalrus) Assigned to: Brett Cannon (bcannon) Summary: Mac Library Modules 1.1.1 Bad Info Initial Comment: Document states that OS X's TextEdit only saves RTF files. This is incorrect; you can make a plaintext file by choosing 'Make Plain Text' from the Format menu. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-23 18:43 Message: Logged In: YES user_id=357491 Fixed in rev. 1.13 in 2.5, rev. 1.12.2.1 in 2.4, and rev. 1.9.6.2 in 2.3 . Thanks, unclewalrus. ---------------------------------------------------------------------- Comment By: Walrus (unclewalrus) Date: 2004-12-22 07:28 Message: Logged In: YES user_id=1178211 Mac Library Modules, section 1.1.1, about halfway down. http://www.python.org/doc/2.4/mac/node5.html ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-21 21:12 Message: Logged In: YES user_id=357491 Yes, it's true; RTF and plaintext are the two possible output. Walrus, where exactly in the docs does it claim this? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 13:35 Message: Logged In: YES user_id=80475 Brett, can you verify this and, if true, add an appropriate note to the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1085300&group_id=5470 From noreply at sourceforge.net Fri Dec 24 15:30:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 15:30:17 2004 Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads Message-ID: Bugs item #1016880, was opened at 2004-08-26 15:58 Message generated for change (Comment added) made by irmen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 6 Submitted By: David Abrahams (david_abrahams) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: urllib.urlretrieve silently truncates downloads Initial Comment: The following script appears to be unreliable on all versions of Python we can find. The file being downloaded is approximately 34 MB. Browsers such as IE and Mozilla have no problem downloading the whole thing. ---- import urllib import os os.chdir('/tmp') urllib.urlretrieve ('http://cvs.sourceforge.net/cvstarballs/boost- cvsroot.tar.bz2', 'boost-cvsroot.tar.bz2') ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-12-24 15:30 Message: Logged In: YES user_id=129426 Suggested addition to the doc of urllib (liburllib.tex, if I'm not mistaken): """ urlretrieve will raise IOError when it detects that the amount of data available was less than the expected amount (which is the size reported by a Content-Length header). This can occur, for example, when the download is interrupted. The Content-Length is treated as a lower bound (just like tools such as wget and Ffirefox appear to do): if there's more data to read, urlretrieve reads more data, but if less data is available, it raises IOError. If no Content-Length header was supplied, urlretrieve can not check the size of the data it has downloaded, and just returns it. In this case you just have to assume that the download was successful. """ ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 21:17 Message: Logged In: YES user_id=129426 a patch is at 1062060 (raises IOError when download is incomplete) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-11-07 20:47 Message: Logged In: YES user_id=129426 Confirmed here (mandrakelinux 10.0, python 2.4b2) However, I doubt it is a problem in urllib.urlretrieve, because I tried downloading the file with wget, and got the following: [irmen@isengard tmp]$ wget -S http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 --20:38:11-- http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 => `boost-cvsroot.tar.bz2.1' Resolving cvs.sourceforge.net... 66.35.250.207 Connecting to cvs.sourceforge.net[66.35.250.207]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Date: Sun, 07 Nov 2004 19:38:15 GMT 3 Server: Apache/2.0.40 (Red Hat Linux) 4 Last-Modified: Sat, 06 Nov 2004 15:11:39 GMT 5 ETag: "b63d5b-25c3808-687d80c0" 6 Accept-Ranges: bytes 7 Content-Length: 39598088 8 Content-Type: application/x-bzip2 9 Connection: close 31% [=======================> ] 12,665,616 60.78K/s ETA 03:55 20:40:07 (111.60 KB/s) - Connection closed at byte 12665616. Retrying. --20:40:08-- http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.bz2 (try: 2) => `boost-cvsroot.tar.bz2.1' Connecting to cvs.sourceforge.net[66.35.250.207]:80... connected. HTTP request sent, awaiting response... ....... so the remote server just closed the connection halfway trough! I suspect that a succesful download is sheer luck. Also, the download loop in urllib looks fine to me. It only stops when the read() returns an empty result, and that means EOF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 22:04 Message: Logged In: YES user_id=80475 Followed the same procedure (no chdir, add a hook) but bombed out at 9.1Mb: . . . (1117, 8192, 34520156) ('boost-cvsroot.tar.bz2', ) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-26 20:52 Message: Logged In: YES user_id=31435 Hmm. I don't know anything about this, but thought I'd just try it. Didn't chdir(), did add a reporthook: def hook(*args): print args WinXP Pro SP1, current CVS Python, cable modem over a wireless router. Output looked like this: (0, 8192, 34520156) (1, 8192, 34520156) (2, 8192, 34520156) ... (4213, 8192, 34520156) (4214, 8192, 34520156) (4215, 8192, 34520156) Had the whole file when it ended: > wc boost-cvsroot.tar.bz2 125368 765656 34520156 boost-cvsroot.tar.bz2 *Maybe* adding the reporthook changed timing in some crucial way. Don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 19:09 Message: Logged In: YES user_id=80475 Confirmed. On Py2.4 (current CVS), I got 12.7 Mb before the connection closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 From noreply at sourceforge.net Fri Dec 24 16:19:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 16:19:51 2004 Subject: [ python-Bugs-778804 ] CGIHTTPServer cannot manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 04:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) >Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer cannot manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- Comment By: Titus Brown (titus) Date: 2004-12-19 01:19 Message: Logged In: YES user_id=23486 same as bug 737202, which has an attached patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 12:06 Message: Logged In: YES user_id=80475 Eric, this was your change (2/9/2001). Will you take it from here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply at sourceforge.net Fri Dec 24 16:49:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 16:49:52 2004 Subject: [ python-Bugs-718532 ] inspect, class instances and __getattr__ Message-ID: Bugs item #718532, was opened at 2003-04-09 15:01 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) >Assigned to: Raymond Hettinger (rhettinger) Summary: inspect, class instances and __getattr__ Initial Comment: inspect.isclass(class_instance) fails if the corresponding class uses a "wildcard" implementation of __getattr__. Example: Python 2.2.2 (#1, Nov 13 2002, 22:53:57) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> class X: ... def __getattr__(self, name): ... if name == 'foo': ... return 1 ... if name == 'bar': ... return 2 ... else: ... return "default" ... >>> x = X() >>> inspect.isclass(x) 1 The problematic expression in inspect.isclass is hasattr(object, '__bases__') which returns a true value. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-15 05:40 Message: Logged In: YES user_id=80475 Ping, if this change is made, will isclass() still be able to find extension classes? The addition of the hasattr(object, '__bases__') was made by you in ver 1.11 about two years ago. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-04-15 05:01 Message: Logged In: YES user_id=89016 type(object) in (types.TypeType, types.ClassType) won't work with custom metaclasses. isinstance(object, (type, types.ClassType)) would be better. ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-04-15 03:01 Message: Logged In: YES user_id=383516 Hello Raymond, thanks for your reply. In fact, I'm also not sure if it counts as a bug. I also suggested a patch (handle __getattr__ requests for __bases__ with an AttributeError) for for the SF project which causes/d the problem. I think, if there's a better way to decide on "class-ness" than now, the code in inspect should be changed. Fortunately, it doesn't have to be backward-compatible, because the module is always distributed with a certain interpreter version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-14 19:36 Message: Logged In: YES user_id=80475 Hmm. I'm not sure that counts as a bug. In an OO language, it's a feature that objects can be made to look like and be substituable for other types. In this case, you've taught your object to be able to fake some classlike behavior (having a __bases__ attribute). OTOH, inspect could have a stronger test for classhood: type(object) in (types.TypeType, types.ClassType) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=718532&group_id=5470 From noreply at sourceforge.net Fri Dec 24 16:53:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 24 16:53:42 2004 Subject: [ python-Bugs-831271 ] httplib.HTTPConnection._send_request header parsing bug Message-ID: Bugs item #831271, was opened at 2003-10-27 14:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Alex Martelli (aleax) Summary: httplib.HTTPConnection._send_request header parsing bug Initial Comment: The test on lines 730-731 of httplib.py as released with Python 2.3.2 doesn't do what it's intended to do. Consider >>> headers = { 'hoST': 'www.someplace.org' } >>> 'Host' in ( headers or [k for k in headers.iterkeys() if k.lower() == 'host' ] ) False This sample code demonstrates that the code in httplib at line 730 doesn't work as intended (it should return true for any dict who's keys include 'host' of any case). Clearly the 'or' syntax has confused someone here, because the portion after the or (if executed) is always an empty list. I recommend instead if 'host' in map( str.lower, headers.keys() ): Or a better general solution might be to force all header keys to be case-insensitive strings by overriding str and dict to new case-insensitive versions, something like the attached. This idea, however, is just a suggestion, and probably needs to be thought through more thoroughly. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 10:53 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Kaj J. Niemi (kajtzu) Date: 2004-02-17 18:06 Message: Logged In: YES user_id=978076 Won't this fail if Host is None? Reason I'm asking is that this changed between python 2.3.2 and 2.3.3 and broke something :) File "/usr/lib/python2.3/httplib.py", line 718, in request self._send_request(method, url, body, headers) File "/usr/lib/python2.3/httplib.py", line 730, in _send_request if 'host' in [k.lower() for k in headers]: AttributeError: 'NoneType' object has no attribute 'lower' ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-11-02 11:51 Message: Logged In: YES user_id=60314 You're certainly right that lines 730-731 cannot be correct, for exactly the reason you specify; and that forcing case-insensitive header dicts may be a cool idea but it's too invasive for such a simple fix. I've done some timing and I think the simplest and fastest way to check is: if 'host' in [k.lower() for k in headers]: accordingly, I have committed this change to the 2.3 branch in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470 From noreply at sourceforge.net Sat Dec 25 01:32:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 25 01:32:12 2004 Subject: [ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off Message-ID: Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by netvigator You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. ---------------------------------------------------------------------- >Comment By: Rick Graves (netvigator) Date: 2004-12-24 19:32 Message: Logged In: YES user_id=1167414 I posted the "bug" on the Tk list as suggested. Today I got this: begin quote >Comment By: Jeffrey Hobbs (hobbs) Date: 2004-12-24 11:25 Message: Logged In: YES user_id=72656 This is not a bug, but rather just that Tk differentiates between the regular arrow up and keypad up on some systems, depending on how their system keymaps operate. The first is and the second is on Linux, but both are on Windows. This has always been the case for KP_Enter as well. The fact that Windows doesn't separate these is by design, but has also caused people to want them separated (see TIP http://www.tcl.tk/cgi-bin/tct/tip/158.html). IOW, the bindings should be on and if they are to be considered equivalent in an app. This is best handled by using virtual events (like <>) and adding the specific event names that you want to apply to it. Please filter this back to the other reports. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1090719&group_id=12997 end quote Would someone please either reopen this or let me know what my next step should be. Thanks, Rick ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-20 07:59 Message: Logged In: YES user_id=469548 OP = opening poster. So yes, the ball is in your court. :) ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-12-20 01:14 Message: Logged In: YES user_id=1167414 > Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ 1) Who is OP? 2) Is this ball in my court or someone else's? Thanks, netvigator aka Rick Graves ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 18:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 From noreply at sourceforge.net Sun Dec 26 10:32:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 10:32:08 2004 Subject: [ python-Bugs-1091302 ] minor bug in what's new > decorators Message-ID: Bugs item #1091302, was opened at 2004-12-26 10:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091302&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: vincent wehren (vinweh) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in what's new > decorators Initial Comment: In What's New > 5 PEP 318: Decorators for Functions and Methods > ca. 5 Paragraph @A @B @C def f (): ... should say @A @B @C def f(): ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091302&group_id=5470 From noreply at sourceforge.net Sun Dec 26 10:34:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 10:34:54 2004 Subject: [ python-Bugs-1091302 ] minor bug in what's new > decorators Message-ID: Bugs item #1091302, was opened at 2004-12-26 10:32 Message generated for change (Comment added) made by vinweh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091302&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: vincent wehren (vinweh) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in what's new > decorators Initial Comment: In What's New > 5 PEP 318: Decorators for Functions and Methods > ca. 5 Paragraph @A @B @C def f (): ... should say @A @B @C def f(): ... ---------------------------------------------------------------------- >Comment By: vincent wehren (vinweh) Date: 2004-12-26 10:34 Message: Logged In: YES user_id=541292 Should have added the link: http://docs.python.org/whatsnew/node6.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091302&group_id=5470 From noreply at sourceforge.net Sun Dec 26 15:46:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 15:46:19 2004 Subject: [ python-Bugs-608635 ] Unix popen does not return exit status Message-ID: Bugs item #608635, was opened at 2002-09-12 19:03 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Thomas Wouters (twouters) Summary: Unix popen does not return exit status Initial Comment: The documentation for os.popen[234] states that the close will return the rc of the process. This works well on windows, but the unix code does not work, None is returned. The attached version of popen2.py fixes the problem by wrapping the fromchild fd with an object that implements the documented close() behaviour. I have also extended the test() to cover testing the rc and run on FreeBSD against 2.2.1 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 11:46 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Barry Alan Scott (barry-scott) Date: 2002-09-16 19:15 Message: Logged In: YES user_id=28665 I don't care how this is fixed. I just want a fix. It would be nice if any fix can make it into a 2.2.x maint release rather then wait for 2.3. If you also think this way then exploiting 2.3 features is not reasonable. Which version should I diff against to make a patch? On the specific points: Why not return -1? The -1 is the value set that means no status available. (See sts variable - not sure how this works as a class variable!) This will be the case if you close the fd before the process exits. Windows version seems to return None in cases where the exit code is not available. But I've not read the code to find out details. A suppose a __get__() would allow forwarding of gets to all of the fd's properties. I may be worth copying the functions from the fd to the wrapper for speed. Note: fd.close() returns None not zero. I was hoping whoever designed the API could comment on how they though it should work. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-16 09:29 Message: Logged In: YES user_id=562624 It seems that Taral has beat me to it. http://python.org/sf/608182 "Enhanced file constructor" This patch would make it possible to implement popen as a subclass of file. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-16 04:41 Message: Logged In: YES user_id=562624 I think I have a cleaner solution than a wrapper object. Now that we can inherit from built-in types it should be possible to make a subclass of file and override the close method. There's a small problem because file.__new__ returns an uninitialized file object and there is no way to initialize it in Python, only from C. I noticed this a while ago but now that I see an actual use for subclassing file objects I think it's time to fix it. Patch coming soon. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-09-13 06:12 Message: Logged In: YES user_id=34209 Hm, for some reason I thought the C 'close()' function (and os.close()) did return the status. They don't, it should be 'pclose()'. os.popen() passes this as the 'close' function to the file constructor, so the rest of the statements still stand :) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-09-13 06:03 Message: Logged In: YES user_id=34209 Assigned to me because I'm last in the 'assigned to' select box. - Points off because you didn't upload a patch, you uploaded a new version. I think I diff'ed against the right version, but a patch is much better. - I'm not happy with the selective copying of attributes to the wrapper object. For example, you aren't copying xreadlines -- and what else ? Copying all 'public' attributes (those not starting with _) seems a much safer bet. - The test is wrong; you mean 'exit 6', not 'return 6'; return might work in some shells, but it isn't the correct way and it doesn't work in bash, at least. I'm also not sure how portable this is; howmany platforms use the popen2 module ? - Why do you a result of convert -1 to None ? -1 seems a valid return value to me, especially if it's documented as meaning "process has not finished yet" :) - I'm not happy with this solution in general. The problem lies in Python's handling of the (f)close function (and its return value) on the fileobject.. os.pipe() returns a fd, which is turned into a fileobject by os.fdopen -- which passes 'fclose' as the close method, which always returns 0. I'd much rather go for a solution where fdopen (or a new function) handles pipes specially, passing in a fake-fclose that really does 'close' on the fd (the infrastructure is all there) or the Popen* classes should just provide a file-wrapper (or subclass?) altogether, and have the close method call close on the fd. But that's just me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470 From noreply at sourceforge.net Sun Dec 26 15:52:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 15:52:43 2004 Subject: [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 06:22 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 11:52 Message: Logged In: YES user_id=752496 Could you please provide a test case? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 11:52 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-11 03:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 06:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply at sourceforge.net Sun Dec 26 16:00:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 16:00:29 2004 Subject: [ python-Bugs-711268 ] A large block of commands after an " if" cannot be Message-ID: Bugs item #711268, was opened at 2003-03-28 07:47 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) >Summary: A large block of commands after an "if" cannot be Initial Comment: A Generated Python script Contains the code: if 1: file = bugreport.vim ... long list of commands .... Executing this code with: exec cmds in globals(), globals() Results in the error: SystemError: com_backpatch: offset too large Looking into the code for com_backpatch() it appears that the code is more than what can be jumped over. Possible solutions: 1. When there is too much code, use another jump statement that allows for a larger offset. 2. Always use a jump statement with a large offset 3. When "if 1" is used, don't generate a jump statement (not a real fix, but works for the situation where I ran into the bug). It looks like this bug exists in all versions of Python. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 12:00 Message: Logged In: YES user_id=752496 Can not reproduce the problem in Py2.3.4 using the method posted by vimboss. It's already fixed? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 12:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-03-28 17:03 Message: Logged In: YES user_id=57665 I can reproduce the problem with this text: if 1: a = "a" Repeat the assignment 7282 times. Feed this text to "exec". With 7281 assignments you do not get the error. Looks like 9 bytes are produced per assignment. Good luck fixing this! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 16:18 Message: Logged In: YES user_id=6380 Hm, the 32-bit argument doesn't work because of what backpatch does. It would require a totally different approach to allow backpatching a larer offset, or we'd always have to reserve 4 bytes for the offset. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 16:13 Message: Logged In: YES user_id=6380 Just curious. How big was the block of code? Also, I wonder if the error message is bogus; opcode arguments can now be 32 bits AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 From noreply at sourceforge.net Sun Dec 26 16:06:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 16:06:28 2004 Subject: [ python-Bugs-737947 ] Failed assert in stringobject.c Message-ID: Bugs item #737947, was opened at 2003-05-14 19:51 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fernando P?rez (fer_perez) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Failed assert in stringobject.c Initial Comment: Here's how to reproduce the problem: [~]> cat test.py import readline readline.get_completer_delims() [~]> echo 'execfile("test.py");print 10' | python python: Objects/stringobject.c:111: PyString_FromString: Assertion `str !=((void *)0)' failed. Abort This was tested with 2.2.1 under RedHat 8.0. On c.l.py, a Mandrake 9.0 (py2.2.2) user reported a segfault with the same. Martin reported not seeing the problem with 2.3b1. However, others suggested still filing it for a possible backport, and also in case the fix was accidental. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 12:06 Message: Logged In: YES user_id=752496 It's fixed in Py2.3.4. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-09-03 00:35 Message: Logged In: YES user_id=12800 I obviously didn't get to this for 2.2.3. Reassigning to Fred who threatened to be the 2.2.4 RM. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 18:14 Message: Logged In: YES user_id=33168 Barry, should this be handled for 2.2.3? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-14 23:28 Message: Logged In: YES user_id=33168 revision 2.54 in Modules/readline.c fixed this problem. Patch #512981: Update readline input stream on sys.stdin/out change. The patch must be modified for 2.2.3 because there is an API change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=737947&group_id=5470 From noreply at sourceforge.net Sun Dec 26 16:32:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 16:32:50 2004 Subject: [ python-Bugs-1091302 ] minor bug in what's new > decorators Message-ID: Bugs item #1091302, was opened at 2004-12-26 03:32 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091302&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: vincent wehren (vinweh) >Assigned to: Skip Montanaro (montanaro) Summary: minor bug in what's new > decorators Initial Comment: In What's New > 5 PEP 318: Decorators for Functions and Methods > ca. 5 Paragraph @A @B @C def f (): ... should say @A @B @C def f(): ... ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-12-26 09:32 Message: Logged In: YES user_id=44345 Thanks. Corrected in whatsnew24.tex v 1.125. ---------------------------------------------------------------------- Comment By: vincent wehren (vinweh) Date: 2004-12-26 03:34 Message: Logged In: YES user_id=541292 Should have added the link: http://docs.python.org/whatsnew/node6.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091302&group_id=5470 From noreply at sourceforge.net Sun Dec 26 20:11:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 20:11:42 2004 Subject: [ python-Bugs-711268 ] A large block of commands after an " if" cannot be Message-ID: Bugs item #711268, was opened at 2003-03-28 02:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: A large block of commands after an "if" cannot be Initial Comment: A Generated Python script Contains the code: if 1: file = bugreport.vim ... long list of commands .... Executing this code with: exec cmds in globals(), globals() Results in the error: SystemError: com_backpatch: offset too large Looking into the code for com_backpatch() it appears that the code is more than what can be jumped over. Possible solutions: 1. When there is too much code, use another jump statement that allows for a larger offset. 2. Always use a jump statement with a large offset 3. When "if 1" is used, don't generate a jump statement (not a real fix, but works for the situation where I ran into the bug). It looks like this bug exists in all versions of Python. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-12-26 11:11 Message: Logged In: YES user_id=357491 I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in CVS using 8000 lines. Closing as out of date. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:00 Message: Logged In: YES user_id=752496 Can not reproduce the problem in Py2.3.4 using the method posted by vimboss. It's already fixed? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-03-28 12:03 Message: Logged In: YES user_id=57665 I can reproduce the problem with this text: if 1: a = "a" Repeat the assignment 7282 times. Feed this text to "exec". With 7281 assignments you do not get the error. Looks like 9 bytes are produced per assignment. Good luck fixing this! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 11:18 Message: Logged In: YES user_id=6380 Hm, the 32-bit argument doesn't work because of what backpatch does. It would require a totally different approach to allow backpatching a larer offset, or we'd always have to reserve 4 bytes for the offset. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 11:13 Message: Logged In: YES user_id=6380 Just curious. How big was the block of code? Also, I wonder if the error message is bogus; opcode arguments can now be 32 bits AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 From noreply at sourceforge.net Sun Dec 26 22:17:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 22:17:45 2004 Subject: [ python-Bugs-1091468 ] DESTROOTed frameworkinstall fails Message-ID: Bugs item #1091468, was opened at 2004-12-26 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091468&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: DESTROOTed frameworkinstall fails Initial Comment: A "make frameworkinstall" with DESTROOT will fail if the same version of Python you're trying to install destrooted has not also been installed normally beforehand. The reason is that some of the parameters to the applet-building tools are filenames that are actually read while building the applet, and these files don't exist. Other filenames, however, are recorded for use during runtime, so passing the DESTROOTed filenames will also not work. A fix for this needs to be applied to 2.3.X and 2.4.X too, so fink and darwinports maintainers can benefit too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091468&group_id=5470 From noreply at sourceforge.net Sun Dec 26 22:55:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 22:55:55 2004 Subject: [ python-Bugs-754016 ] urlparse goes wrong with IP:port without scheme Message-ID: Bugs item #754016, was opened at 2003-06-13 12:15 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Kr?ger (kruegi) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse goes wrong with IP:port without scheme Initial Comment: urlparse doesnt work if IP and port are given without scheme: >>> urlparse.urlparse('1.2.3.4:80','http') ('1.2.3.4', '', '80', '', '', '') should be: >>> urlparse.urlparse('1.2.3.4:80','http') ('http', '1.2.3.4', '80', '', '', '') ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 18:55 Message: Logged In: YES user_id=752496 The problem is still present in Py2.3.4. IMO, it should support dirs without the "http://" or raise an error if it's not present (never fail silently!). ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-14 01:18 Message: Logged In: YES user_id=589306 Ok, I researched this a bit, and the situation isn't as simple as it first appears. The RFC that urlparse tries to follow is at http://www.faqs.org/rfcs/rfc1808.html and notice specifically sections 2.1 and 2.2. It seems to me that the source code follows rfc1808 religiously, and in that sense it does the correct thing. According to the RFC, the netloc should begin with a '//', and since your example didn't include one then it technical was an invalid URL. Here is another example where it seems Python fails to do the right thing: >>> urlparse.urlparse('python.org') ('', '', 'python.org', '', '', '') >>> urlparse.urlparse('python.org', 'http') ('http', '', 'python.org', '', '', '') Note that it is putting 'python.org' as the path and not the netloc. So the problem isn't limited to just when you use a scheme parameter and/or a port number. Now if we put '//' at the beginning, we get: >>> urlparse.urlparse('//python.org') ('', 'python.org', '', '', '', '') >>> urlparse.urlparse('//python.org', 'http') ('http', 'python.org', '', '', '', '') So here it does the correct thing. There are two problems though. First, it is common for browsers and other software to just take a URL without a scheme and '://' and assume it is http for the user. While the URL is technically not correct, it is still common usage. Also, urlparse does take a scheme parameter. It seems as though this parameter should be used with a scheme-less URL to give it a default one like web browsers do. So somebody needs to make a decision. Should urlparse follow the RFC religiously and require '//' in front of netlocs? If so, I think the documentation should give an example showing this and showing how to use the 'scheme' parameter. Or should urlparse use the more commonly used form of a URL where '//' is omitted when the scheme is omitted? If so, urlparse.py will need to be changed. Or maybe another fuction should be added to cover whichever behaviour urlparse doesn't cover. In any case, you can temporarily solve your problem by making sure that URL's without a scheme have '//' at the front. So your example becomes: >>> urlparse.urlparse('//1.2.3.4:80', 'http') ('http', '1.2.3.4:80', '', '', '', '') ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-13 23:39 Message: Logged In: YES user_id=589306 Sorry, previous comment got cut off... urlparse.urlparse takes a url of the format: <scheme>://<netloc>/<path>;<params>?<query>#<fragment> And returns a 6-tuple of the format: (scheme, netloc, path, params, query, fragment). An example from the library refrence takes: urlparse('http://www.cwi.nl:80/%7Eguido/Python.html') And produces: ('http', 'www.cwi.nl:80', '/%7Eguido/Python.html', '', '', '') -------------------------------- Note that there isn't a field for the port number in the 6-tuple. Instead, it is included in the netloc. Urlparse should handle your example as: >>> urlparse.urlparse('1.2.3.4:80','http') ('http', '1.2.3.4:80', '', '', '', '') Instead, it gives the incorrect output as you indicated. ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-13 23:26 Message: Logged In: YES user_id=589306 urlparse.urlparse takes a url of the format: <scheme>://<netloc>/<path>;<params>?<query>#<fragment> And returns a 6-tuple of the format: (scheme, netloc, path, params, query, fragment). An example from the library refrence takes: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754016&group_id=5470 From noreply at sourceforge.net Sun Dec 26 22:57:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 22:57:25 2004 Subject: [ python-Bugs-779388 ] sgmllib incorrectly handles entities in attributes Message-ID: Bugs item #779388, was opened at 2003-07-29 02:43 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779388&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Misha Bergal (mbergal) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib incorrectly handles entities in attributes Initial Comment: The following test inserted in test_sgmllib.py fails def test_entities_in_attrs(self): """Be sure quotes entities are treated right attributes""" self.check_events("<a href=\"&amp;\">", [ ("starttag", "a", [("href", '&')]), ]) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 18:57 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779388&group_id=5470 From noreply at sourceforge.net Sun Dec 26 23:00:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 23:00:29 2004 Subject: [ python-Bugs-1003195 ] segfault when running smtplib example Message-ID: Bugs item #1003195, was opened at 2004-08-04 08:43 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when running smtplib example Initial Comment: On my system, running the simple smtplib Example from the Documentation results in a segmentation fault. Execution stops and no mail is submitted. I debugged into the Python source code, but my understanding of the inner mechanisms doesn't suffice to fix the problem. I update my system periodically using "apt-get update ; apt-get upgrade". I don't remember, when it was the last time Python was upgraded. I made the files availabe: http://www.bertram-scharpf.de/tmp/smtpex.py.txt http://www.bertram-scharpf.de/tmp/smtpex.desc.txt ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 19:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-08-08 04:14 Message: Logged In: YES user_id=1097255 Indeed, I did compile python 2.2.1 with Gcc versions 2.95, 3.0 and 3.3. The segfault only occurs in the 2.95 compiled code. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 11:30 Message: Logged In: YES user_id=580910 I cannot reproduce this. I've tested: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Python 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] on linux2 The first is the system python on MacOS X, the other two are current Debian packages (python2.3 and python2.2) on Debian stable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 From noreply at sourceforge.net Sun Dec 26 23:02:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 26 23:02:16 2004 Subject: [ python-Bugs-549081 ] test_signal hangs -- signal broken on OpenBSD? Message-ID: Bugs item #549081, was opened at 2002-04-26 10:54 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470 Category: Installation Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: test_signal hangs -- signal broken on OpenBSD? Initial Comment: This appears to be similar to bug as PR#288, [ 210635 ] test_signal hangs when running as part of testall (PR#288) except that I have this problem on a fresh install of OpenBSD 3.0 while trying to build Python-2.2.1. I did a generic build running as root: ./configure ./make ./make test Yours, Noah ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 19:02 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Frallan the master Jedi (frallan) Date: 2003-12-11 09:14 Message: Logged In: YES user_id=639616 My test program now works. It both terminates and prints the 'got signal' message. Current Platform is: OpenBSD somewhere 3.3 GENERIC#44 i386 Python 2.3.2 (#1, Dec 1 2003, 11:20:01) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 I should receive my OpenBSD 3.4 CDs soon. Then I'll test that too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-31 07:49 Message: Logged In: YES user_id=6656 As far as I am aware (not very) Python signals have always been broken on OpenBSD. None of the Python core developers use OpenBSD, though, so it's always remained a mystery. frallan, does the C equivalent of your Python test work? Do you have any idea what Python (or OpenBSD, maybe) is doing wrong? signals are pain. ---------------------------------------------------------------------- Comment By: Frallan the master Jedi (frallan) Date: 2002-10-31 06:48 Message: Logged In: YES user_id=639616 I get the exact same behavior on OpenBSD 3.1 with Python- 2.2.2. Also this simple test program from the "Python Standard Library" book - fails. The program terminates but the "got signal" message is never printed. import signal import time def handler (signo, frame): print 'got signal', signo signal.signal(signal.SIGALRM, handler) # wake me up in two seconds signal.alarm(2) now = time.time() time.sleep(200) print 'slept for', time.time() - now, "seconds" ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2002-04-27 12:40 Message: Logged In: YES user_id=59261 Below is the output of test_signal.py. I ran it manually. I modified it slightly to print out the pid; the return values from the signal calls; and to print a count of the loop iteration (starting at 1). You can see that after Count 4 it just sits there. After about a minute I hit Ctrl- Z. I have uploaded the modified version of test_signal.py. ... bash-2.05# python test_signal.py pid: 8606 signal.alarm(20): 0 signal.signal(5, handlerA): 0 signal.signal(2, handlerB): <built-in function default_int_handler> signal.signal(3, signal.SIG_IGN): 0 signal.signal(signal.SIGALRM, signal.default_int_handler): 0 starting pause() loop... + sleep 2 count: 1 call pause()... + kill -5 8606 pause() returned + sleep 2 count: 2 call pause()... + kill -2 8606 pause() returned + sleep 2 count: 3 call pause()... + kill -3 8606 pause() returned count: 4 call pause()... ^Z [1]+ Stopped python test_signal.py bash-2.05# ps -p 8606 PID TT STAT TIME COMMAND 8606 p0 T 0:00.09 python test_signal.py bash-2.05# uname -a OpenBSD nobot 3.0 GENERIC#94 i386 bash-2.05# python Python 2.2.1 (#4, Apr 26 2002, 23:06:40) [GCC 2.95.3 20010125 (prerelease)] on openbsd3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470 From noreply at sourceforge.net Mon Dec 27 08:04:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 08:04:16 2004 Subject: [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 02:22 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:04 Message: Logged In: YES user_id=371366 pathname2url and url2pathname are undocumented and are urllib- and platform-specific. My complaints in this old bug report are based on assumptions that thse functions are general-purpose public interfaces. Upon further investigation, I see that they are not. I suggest leaving the implementations unchanged for now; there are too many issues with doing it 'right' to go into here. But perhaps add documentation that is consistent and indicates that the functions are limited in scope. Patches attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:52 Message: Logged In: YES user_id=752496 Could you please provide a test case? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:52 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-10 23:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 02:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply at sourceforge.net Mon Dec 27 08:12:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 08:13:01 2004 Subject: [ python-Bugs-649961 ] nturl2path.url2pathname() mishandles /// Message-ID: Bugs item #649961, was opened at 2002-12-07 01:19 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: nturl2path.url2pathname() mishandles /// Initial Comment: On Windows, urllib.url2pathname('///path/to/file') returns r'\\path\to\file'. This path cannot be used in things like open() and os.access(). It should probably return r'\path\to\file'. In addition, '//localhost/path/to/file' is a special case that should become '\path\to\file'. I'll post this as a separate bug since it affects all file URIs. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:12 Message: Logged In: YES user_id=371366 See #649974 -- url2pathname() and pathname2url() are undocumented, platform-specific, and not really general-purpose. It probably should not be assumed that they are intended to produce values that are usable with open(), os.access(), or anything other than where they are currently used internally in urllib. The solution as proposed for #649974 is probably just to document the functions and discourage their general use. See the suggested diffs attached to that report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 From noreply at sourceforge.net Mon Dec 27 08:15:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 08:15:10 2004 Subject: [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 02:22 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:15 Message: Logged In: YES user_id=371366 See also #649961, where I propose the same solution. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:04 Message: Logged In: YES user_id=371366 pathname2url and url2pathname are undocumented and are urllib- and platform-specific. My complaints in this old bug report are based on assumptions that thse functions are general-purpose public interfaces. Upon further investigation, I see that they are not. I suggest leaving the implementations unchanged for now; there are too many issues with doing it 'right' to go into here. But perhaps add documentation that is consistent and indicates that the functions are limited in scope. Patches attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:52 Message: Logged In: YES user_id=752496 Could you please provide a test case? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:52 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-10 23:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 02:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply at sourceforge.net Mon Dec 27 09:28:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 09:28:19 2004 Subject: [ python-Feature Requests-1089955 ] optparse .error() should print options list Message-ID: Feature Requests item #1089955, was opened at 2004-12-22 13:53 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1089955&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) >Assigned to: Greg Ward (gward) Summary: optparse .error() should print options list Initial Comment: Why doesn't optparse.OptionParser.error() print the list of correct options along with the error message and usage? This is what the user needs to know whenever there's an error. One can override this in a subclass, but it's frustrating to have to do it every time. To do this, change the first line in OptionParser.error() from: self.print_usage(sys.stderr) to: self.print_help(sys.stderr) print >>sys.stderr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1089955&group_id=5470 From noreply at sourceforge.net Mon Dec 27 09:29:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 09:29:32 2004 Subject: [ python-Feature Requests-1087418 ] long int bitwise ops speedup (patch included) Message-ID: Feature Requests item #1087418, was opened at 2004-12-18 00:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) >Assigned to: Raymond Hettinger (rhettinger) Summary: long int bitwise ops speedup (patch included) Initial Comment: The 'inner loop' for applying bitwise ops to longs is quite inefficient. The improvement in the attached diff is - 'a' is never shorter than 'b' (result: only test 1 loop index condition instead of 3) - each operation ( & | ^ ) has its own loop, instead of switch inside loop - I found that, when this is done, a lot of things can be simplified, resulting in further speedup, and the resulting code is not very much longer than before (my libpython2.4.dll .text got 140 bytes longer). Operations on longs of a few thousand bits appear to be 2 ... 2.5 times faster with this patch. I'm not 100% sure the code is right, but it passes test_long.py, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1087418&group_id=5470 From noreply at sourceforge.net Mon Dec 27 11:25:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 11:25:25 2004 Subject: [ python-Bugs-1091634 ] No need to fix Message-ID: Bugs item #1091634, was opened at 2004-12-27 11:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091634&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: No need to fix Initial Comment: > I'll close this bug as "Won't fix". I think that's OK. Bertram ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091634&group_id=5470 From noreply at sourceforge.net Mon Dec 27 11:30:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 11:30:40 2004 Subject: [ python-Bugs-1003195 ] segfault when running smtplib example Message-ID: Bugs item #1003195, was opened at 2004-08-04 13:43 Message generated for change (Comment added) made by bertramscharpf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when running smtplib example Initial Comment: On my system, running the simple smtplib Example from the Documentation results in a segmentation fault. Execution stops and no mail is submitted. I debugged into the Python source code, but my understanding of the inner mechanisms doesn't suffice to fix the problem. I update my system periodically using "apt-get update ; apt-get upgrade". I don't remember, when it was the last time Python was upgraded. I made the files availabe: http://www.bertram-scharpf.de/tmp/smtpex.py.txt http://www.bertram-scharpf.de/tmp/smtpex.desc.txt ---------------------------------------------------------------------- >Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-12-27 11:30 Message: Logged In: YES user_id=1097255 > I'll close this bug as "Won't fix". I think that's OK. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 23:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-08-08 09:14 Message: Logged In: YES user_id=1097255 Indeed, I did compile python 2.2.1 with Gcc versions 2.95, 3.0 and 3.3. The segfault only occurs in the 2.95 compiled code. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 16:30 Message: Logged In: YES user_id=580910 I cannot reproduce this. I've tested: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Python 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] on linux2 The first is the system python on MacOS X, the other two are current Debian packages (python2.3 and python2.2) on Debian stable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 From noreply at sourceforge.net Mon Dec 27 11:33:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 11:33:08 2004 Subject: [ python-Bugs-1091634 ] No need to fix Message-ID: Bugs item #1091634, was opened at 2004-12-27 11:25 Message generated for change (Comment added) made by bertramscharpf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091634&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: No need to fix Initial Comment: > I'll close this bug as "Won't fix". I think that's OK. Bertram ---------------------------------------------------------------------- >Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-12-27 11:33 Message: Logged In: YES user_id=1097255 Weird buttons! I hit the wrong one. Sorry to anyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091634&group_id=5470 From noreply at sourceforge.net Mon Dec 27 11:42:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 11:42:29 2004 Subject: [ python-Bugs-1091634 ] No need to fix Message-ID: Bugs item #1091634, was opened at 2004-12-27 10:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091634&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: No need to fix Initial Comment: > I'll close this bug as "Won't fix". I think that's OK. Bertram ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-12-27 10:42 Message: Logged In: YES user_id=6656 I did wonder! Closing... ---------------------------------------------------------------------- Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-12-27 10:33 Message: Logged In: YES user_id=1097255 Weird buttons! I hit the wrong one. Sorry to anyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091634&group_id=5470 From noreply at sourceforge.net Mon Dec 27 16:11:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 16:11:58 2004 Subject: [ python-Bugs-1021756 ] 2.4a3: unhelpful error message from distutils Message-ID: Bugs item #1021756, was opened at 2004-09-03 13:34 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021756&group_id=5470 Category: Distutils Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4a3: unhelpful error message from distutils Initial Comment: C:\somewhere> python Python 2.4a3 (#56, Sep 2 2004, 20:50:21) ... C:\somewhere> python setup.py build running build_ext Traceback (most recent call last): File "setup.py", line 19, in ? ext_modules = [ File "C:\python24\lib\distutils\core.py", line 150, in setup dist.run_commands() File "C:\python24\lib\distutils\dist.py", line 991, in run_commands self.run_command(cmd) File "C:\python24\lib\distutils\dist.py", line 1011, in run_command cmd_obj.run() File "C:\python24\lib\distutils\command\build_ext.py", line 243, in run force=self.force) File "C:\python24\lib\distutils\ccompiler.py", line 1177, in new_compiler return klass (None, dry_run, force) File "C:\python24\lib\distutils\msvccompiler.py", line 206, in __init__ self.__macros = MacroExpander(self.__version) File "C:\python24\lib\distutils\msvccompiler.py", line 112, in __init__ self.load_macros(version) File "C:\python24\lib\distutils\msvccompiler.py", line 128, in load_macros self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1") File "C:\python24\lib\distutils\msvccompiler.py", line 118, in set_macro self.macros["$(%s)" % macro] = d[key] KeyError: 'sdkinstallrootv1.1' I suppose it's trying to tell me something, but I'm not sure what. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2004-12-27 16:11 Message: Logged In: YES user_id=38376 Original issue fixed in 2.4 final. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-11-30 14:26 Message: Logged In: YES user_id=488897 > python setup.py build --compiler=whatever bdist_wininst This worked for me (with Python 2.4 final, without any patch). I wasn't aware that this simple solution existed. You're right, this should be in the documentation. Many thanks. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-11-30 13:13 Message: Logged In: YES user_id=11105 The solution or workaround is to either run 'python setup.py build --compiler=whatever bdist_wininst' or insert 'compiler=whatever' in a setup.cfg file. I have explained this several times, IMO something should be added to the distutils documentation about this (but I don't have the time). ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-11-30 11:13 Message: Logged In: YES user_id=488897 >I suggest you open a new, more specific bug ("bdist_wininst > relies on msvccompiler"), and follow up with a message to > the python-dev. Well this is a severe bug in Python 2.4: Users of compilers other than Microsoft can no longer build extension modules for Python on Windows. (Well they can build one, but they cannot install it nor create a binary installer). So I wrote a patch for msvccompiler.py and submitted it to sourceforge (see patch 1075887). Could you do me a favor and have a look at this patch (or have somebody else look at it)? There are lots of patches for Python 2.4 already, some very old, and I'm worried that it may take a long time before this gets fixed. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-29 07:54 Message: Logged In: YES user_id=38376 > This makes sense, because no compilation is needed to create the installer. That's an incorrect assumption: bdist_wininst does a full "build" before it builds the installer. All standard distutils commands work this way; you don't have to run them in any specific order. I suggest you open a new, more specific bug ("bdist_wininst relies on msvccompiler"), and follow up with a message to the python-dev. It might be too late for 2.4 (it's been this way through the alpha and beta releases, without anyone noticing), but maybe some distutils expert can come up with a workaround (or explain how this really is supposed to work). ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-11-29 04:08 Message: Logged In: YES user_id=488897 > Are you really claiming that this worked in earlier 2.4 releases? No, it didn't work for any of the 2.4 releases, but it did work for Python 2.3 and 2.2: $ /cygdrive/c/Python23/python setup.py build --compiler=mingw32 ... compiles the extension module using gcc $ /cygdrive/c/Python23/python setup.py bdist_wininst running bdist_wininst running build running build_py running build_ext installing to build\bdist.win32\wininst running install_lib .... creates the installer. > Does it work if you pass in the --compiler switch to bdist_wininst? No, it doesn't, I get the following error message: $ /cygdrive/c/Python24/python setup.py bdist_wininst --compiler=mingw32 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --compiler not recognized This makes sense, because no compilation is needed to create the installer. >From looking at msvccompiler.py, it looks like the problem is that self.__macros = MacroExpander(self.__version) is called when creating the MSVCCompiler, before we know if anything is left that still needs to be compiled. A solution might be to leave self.__macros None in __init__, and check it in the compile function. If it is still None there, we can make the call to MacroExpander then. Users of gcc will not need to run MSVCCompiler's compile function, so they will not run into MacroExpander. There is one remaining problem in __init__: if len (self.__paths) == 0: raise DistutilsPlatformError, ("Python was built with version %s of Visual Studio, " "and extensions need to be built with the same " "version of the compiler, but it isn't installed." % self.__version) Is this true? It would imply that gcc can't be used at all. However, extension modules built with gcc seem to work correctly with Python 2.4, as far as I can tell. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-28 15:09 Message: Logged In: YES user_id=38376 The patch only changed the error message; earlier versions gave a KeyError exception. Are you really claiming that this worked in earlier 2.4 releases? Does it work if you pass in the --compiler switch to bdist_wininst? ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-11-28 14:29 Message: Logged In: YES user_id=488897 The patch probably works fine for Microsoft users, but now gcc users get an unhelpful error message: $ /cygdrive/c/Python24/python setup.py build --compiler=mingw32 ... runs fine, using gcc compiler ... ... now let's try to make the installer: $ /cygdrive/c/Python24/python setup.py bdist_wininst running bdist_wininst running build running build_py running build_ext error: The .NET Framework SDK needs to be installed before building extensions for Python. I'm not sure why distutils is running msvccompiler.py. To check if all components have been compiled and are ready to be included into the installer, it shouldn't matter which compiler was used during the build step. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2004-11-23 15:18 Message: Logged In: YES user_id=539787 Please check patch 1071739. The updated report is: D:\SRC\Imaging-1.1.5b1>python setup.py build_ext -i running build_ext error: The .NET Framework SDK needs to be installed before building extensions for Python. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-11-22 20:00 Message: Logged In: YES user_id=38376 "I would wrap the offending line in load_macros function and throw an exception with more informative args. Do you want me to?" Makes sense to me. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2004-11-22 16:00 Message: Logged In: YES user_id=539787 Please forgive my previous quadruple followup. This page ( http://www.vrplumber.com/programming/mstoolkit/ ) is relevant. The message about sdkinstallroot1.1 should be related to the .NET Framework SDK v1.1 not being installed. I would wrap the offending line in load_macros function and throw an exception with more informative args. Do you want me to? PS I attempted to "pass" the failing statement in line 128 (in the load_macros function); building Imaging complains that VS 7.1 is not installed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-11-22 12:08 Message: Logged In: NO I get the same message trying to build PIL with 2.4rc1, having installed the VC++ toolkit (free command line compiler), so it's not a problem of VS 6. I assume/fear that the .NET SDK framework needs to be installed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2004-11-22 12:08 Message: Logged In: YES user_id=539787 I get the same message trying to build PIL with 2.4rc1, having installed the VC++ toolkit (free command line compiler), so it's not a problem of VS 6. I assume/fear that the .NET SDK framework needs to be installed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2004-11-22 12:07 Message: Logged In: YES user_id=539787 I get the same message trying to build PIL with 2.4rc1, having installed the VC++ toolkit (free command line compiler), so it's not a problem of VS 6. I assume/fear that the .NET SDK framework needs to be installed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2004-11-22 12:05 Message: Logged In: YES user_id=539787 I get the same message trying to build PIL with 2.4rc1, having installed the VC++ toolkit (free command line compiler), so it's not a problem of VS 6. I assume/fear that the .NET SDK framework needs to be installed. ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-10-18 07:44 Message: Logged In: YES user_id=488897 Note that the same error occurs with python setup.py install (using Python 2.4b1): C:\somewhere> python setup.py build .... File "c:\Python24\lib\distutils\msvccompiler.py", line 118, in set_macro self.macros["$(%s)" % macro] = d[key] KeyError: 'sdkinstallrootv1.1' Using MinGW for the compilation works: C:\somewhere> python setup.py build --compiler=mingw32 .... compiles without errors. However, the install still fails: C:\somewhere> python setup.py install File "c:\Python24\lib\distutils\msvccompiler.py", line 118, in set_macro self.macros["$(%s)" % macro] = d[key] KeyError: 'sdkinstallrootv1.1' ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-13 17:56 Message: Logged In: YES user_id=29957 Yep. Can you produce a small patch for this? I have no access to MSVC 6 or 7 (in fact, my Windows box won't even boot at the moment). ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2004-10-13 17:29 Message: Logged In: YES user_id=38376 If I'm using the wrong compiler, distutils should say so, instead of showing me a 10-level KeyError traceback... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-13 17:11 Message: Logged In: YES user_id=29957 It looks (to me) like it's expecting you to have some additional package (Framework SDK?) installed. The code in question was added as part of the MSVC7 support - are you building with MSVC6? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1021756&group_id=5470 From noreply at sourceforge.net Mon Dec 27 16:38:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 16:38:20 2004 Subject: [ python-Bugs-1091740 ] garbage collector still documented as optional Message-ID: Bugs item #1091740, was opened at 2004-12-27 10:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091740&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collector still documented as optional Initial Comment: Section 3.2 of the library reference, first paragraph, says "The gc module is only available if the interpreter was built with the optional cyclic garbage detector" However according to Misc/NEWS, "Compiling out the cyclic garbage collector is no longer an option" as of Python 2.3 alpha 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091740&group_id=5470 From noreply at sourceforge.net Mon Dec 27 17:04:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 17:04:30 2004 Subject: [ python-Bugs-711268 ] A large block of commands after an " if" cannot be Message-ID: Bugs item #711268, was opened at 2003-03-28 11:47 Message generated for change (Comment added) made by vimboss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: A large block of commands after an "if" cannot be Initial Comment: A Generated Python script Contains the code: if 1: file = bugreport.vim ... long list of commands .... Executing this code with: exec cmds in globals(), globals() Results in the error: SystemError: com_backpatch: offset too large Looking into the code for com_backpatch() it appears that the code is more than what can be jumped over. Possible solutions: 1. When there is too much code, use another jump statement that allows for a larger offset. 2. Always use a jump statement with a large offset 3. When "if 1" is used, don't generate a jump statement (not a real fix, but works for the situation where I ran into the bug). It looks like this bug exists in all versions of Python. ---------------------------------------------------------------------- >Comment By: Bram Moolenaar (vimboss) Date: 2004-12-27 17:04 Message: Logged In: YES user_id=57665 It appears between Python 2.2 and 2.3 the efficiency of the produced bytecode was improved. You now need to repeat the command 10923 times to produce the error. Thus the problem remains, it's just further away. You can reproduce the problem with this program: cmds = "if 1:\n" for i in xrange(1, 10923): cmds = cmds + " a = 'a'\n" exec cmds in globals(), globals() I verified with Python 2.3.3, don't have a newer version right now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-26 20:11 Message: Logged In: YES user_id=357491 I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in CVS using 8000 lines. Closing as out of date. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 16:00 Message: Logged In: YES user_id=752496 Can not reproduce the problem in Py2.3.4 using the method posted by vimboss. It's already fixed? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 16:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-03-28 21:03 Message: Logged In: YES user_id=57665 I can reproduce the problem with this text: if 1: a = "a" Repeat the assignment 7282 times. Feed this text to "exec". With 7281 assignments you do not get the error. Looks like 9 bytes are produced per assignment. Good luck fixing this! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 20:18 Message: Logged In: YES user_id=6380 Hm, the 32-bit argument doesn't work because of what backpatch does. It would require a totally different approach to allow backpatching a larer offset, or we'd always have to reserve 4 bytes for the offset. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 20:13 Message: Logged In: YES user_id=6380 Just curious. How big was the block of code? Also, I wonder if the error message is bogus; opcode arguments can now be 32 bits AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 From noreply at sourceforge.net Mon Dec 27 17:10:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 17:10:23 2004 Subject: [ python-Bugs-711268 ] A large block of commands after an " if" cannot be Message-ID: Bugs item #711268, was opened at 2003-03-28 07:47 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 Category: Parser/Compiler >Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: A large block of commands after an "if" cannot be Initial Comment: A Generated Python script Contains the code: if 1: file = bugreport.vim ... long list of commands .... Executing this code with: exec cmds in globals(), globals() Results in the error: SystemError: com_backpatch: offset too large Looking into the code for com_backpatch() it appears that the code is more than what can be jumped over. Possible solutions: 1. When there is too much code, use another jump statement that allows for a larger offset. 2. Always use a jump statement with a large offset 3. When "if 1" is used, don't generate a jump statement (not a real fix, but works for the situation where I ran into the bug). It looks like this bug exists in all versions of Python. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 13:10 Message: Logged In: YES user_id=752496 Also happens in 2.4. I'm reopening the bug, in group 2.4. ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2004-12-27 13:04 Message: Logged In: YES user_id=57665 It appears between Python 2.2 and 2.3 the efficiency of the produced bytecode was improved. You now need to repeat the command 10923 times to produce the error. Thus the problem remains, it's just further away. You can reproduce the problem with this program: cmds = "if 1:\n" for i in xrange(1, 10923): cmds = cmds + " a = 'a'\n" exec cmds in globals(), globals() I verified with Python 2.3.3, don't have a newer version right now. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-26 16:11 Message: Logged In: YES user_id=357491 I can't reproduce it with 2.3, 2.3 maintenance, 2.4 maintenance, or 2.5 in CVS using 8000 lines. Closing as out of date. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 12:00 Message: Logged In: YES user_id=752496 Can not reproduce the problem in Py2.3.4 using the method posted by vimboss. It's already fixed? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 12:00 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-03-28 17:03 Message: Logged In: YES user_id=57665 I can reproduce the problem with this text: if 1: a = "a" Repeat the assignment 7282 times. Feed this text to "exec". With 7281 assignments you do not get the error. Looks like 9 bytes are produced per assignment. Good luck fixing this! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 16:18 Message: Logged In: YES user_id=6380 Hm, the 32-bit argument doesn't work because of what backpatch does. It would require a totally different approach to allow backpatching a larer offset, or we'd always have to reserve 4 bytes for the offset. :-( ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-28 16:13 Message: Logged In: YES user_id=6380 Just curious. How big was the block of code? Also, I wonder if the error message is bogus; opcode arguments can now be 32 bits AFAIK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711268&group_id=5470 From noreply at sourceforge.net Mon Dec 27 17:29:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 27 17:29:09 2004 Subject: [ python-Bugs-1076492 ] BuildApplication includes many unneeded modules Message-ID: Bugs item #1076492, was opened at 2004-12-01 05:35 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076492&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Neil Mayhew (neil_mayhew) Assigned to: Jack Jansen (jackjansen) Summary: BuildApplication includes many unneeded modules Initial Comment: I have a simple application to calculate MD5 sums for Macintosh files with resource forks. BuildApplication includes a whole raft of modules, such as httplib, that seem to be unrelated to my application. My imports are: import sys, os import md5 import EasyDialogs import MacOS import Carbon.File as macfs Apologies if this is a known limitation, but I didn't see it mentioned anywhere. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-12-27 17:29 Message: Logged In: YES user_id=45365 BuildApplication includes all modules that could possibly be needed by recursively inspecting all modules for their imports.In your case I guess EasyDialogs or os somehow indirectly caused httplib to be included. This process can be controlled (you can forcibly include or exclude modules) by adding :macfreeze: directives to your source code, but this is not documented, really. Look in :Mac:Tools:macfreeze for the code that does it, you may be able to infer how it is done. ---------------------------------------------------------------------- Comment By: Neil Mayhew (neil_mayhew) Date: 2004-12-01 05:36 Message: Logged In: YES user_id=709148 MacPython-OS9 2.3.3, on Mac OS 9.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076492&group_id=5470 From noreply at sourceforge.net Tue Dec 28 01:32:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 01:32:27 2004 Subject: [ python-Bugs-649974 ] urllib.url2pathname('file://host/')... Message-ID: Bugs item #649974, was opened at 2002-12-07 06:22 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.url2pathname('file://host/')... Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 21:32 Message: Logged In: YES user_id=752496 The documentation for urllib states that: Although the urllib module contains (undocumented) routines to parse and unparse URL strings, the recommended interface for URL manipulation is in module urlparse. So, if you think that the files should also be modified, change the group of this bug to 2.4. Otherwise it will be closed as won't fix. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 04:15 Message: Logged In: YES user_id=371366 See also #649961, where I propose the same solution. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 04:04 Message: Logged In: YES user_id=371366 pathname2url and url2pathname are undocumented and are urllib- and platform-specific. My complaints in this old bug report are based on assumptions that thse functions are general-purpose public interfaces. Upon further investigation, I see that they are not. I suggest leaving the implementations unchanged for now; there are too many issues with doing it 'right' to go into here. But perhaps add documentation that is consistent and indicates that the functions are limited in scope. Patches attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 11:52 Message: Logged In: YES user_id=752496 Could you please provide a test case? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 11:52 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-11 03:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 06:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply at sourceforge.net Tue Dec 28 01:32:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 01:32:59 2004 Subject: [ python-Bugs-649961 ] nturl2path.url2pathname() mishandles /// Message-ID: Bugs item #649961, was opened at 2002-12-07 05:19 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 Category: Windows Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: nturl2path.url2pathname() mishandles /// Initial Comment: On Windows, urllib.url2pathname('///path/to/file') returns r'\\path\to\file'. This path cannot be used in things like open() and os.access(). It should probably return r'\path\to\file'. In addition, '//localhost/path/to/file' is a special case that should become '\path\to\file'. I'll post this as a separate bug since it affects all file URIs. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 21:32 Message: Logged In: YES user_id=752496 The documentation for urllib states that: Although the urllib module contains (undocumented) routines to parse and unparse URL strings, the recommended interface for URL manipulation is in module urlparse. So, if you think that the files should also be modified, change the group of this bug to 2.4. Otherwise it will be closed as won't fix. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 21:32 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 04:12 Message: Logged In: YES user_id=371366 See #649974 -- url2pathname() and pathname2url() are undocumented, platform-specific, and not really general-purpose. It probably should not be assumed that they are intended to produce values that are usable with open(), os.access(), or anything other than where they are currently used internally in urllib. The solution as proposed for #649974 is probably just to document the functions and discourage their general use. See the suggested diffs attached to that report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 From noreply at sourceforge.net Tue Dec 28 03:02:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 03:02:28 2004 Subject: [ python-Bugs-632323 ] Tkinter: BitmapImage vanishes if not stored in non-local var Message-ID: Bugs item #632323, was opened at 2002-11-01 19:39 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: Invalid Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter: BitmapImage vanishes if not stored in non-local var Initial Comment: The following program incorrectly produces a blank canvas: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) self.init2(self.init1()) #img = self.init1() #self.init2(img) self.mainloop() ---------------- However, the following program correctly draws a small red-and-green icon: #!/usr/bin/env python from Tkinter import * class Me(Canvas): def init1(self): return BitmapImage(foreground = '#ff0000', background = '#00ff00', data = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x3c, 0x3c}; """, maskdata = """#define t_width 8 #define t_height 8 static unsigned char t_bits[] = { 0x18, 0x3c, 0x7e, 0xff, 0xff, 0x7e, 0x3c, 0x18}; """) def init2(self, image): self.create_image(32, 32, anchor = NW, image = image) self = Me() self.pack(expand = 1, fill = BOTH) #self.init2(self.init1()) img = self.init1() self.init2(img) self.mainloop() ---------------- The two programs are identical except that one of them assigns the BitmapImage to a variable rather than passing it directly as an argument. Python 2.2.1, OS = Linux version 2.4.18-3 (bhcompile@daffy.perf.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 23:02 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-11 08:59 Message: Logged In: YES user_id=21627 It's inconsistent with the rest of Tkinter. Everything in Tkinter is an object, and so are images. If you want strings, use plain _tkinter. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-11 06:33 Message: Logged In: YES user_id=38376 "..consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life." ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 06:01 Message: Logged In: YES user_id=33229 What's wrong with simply wrapping what Tk does with an image_create method that returns a string and an image_delete method that accepts a string? It's consistent with Tk usage. You can document the proper usage of image_delete and leave the Image class for backwards compatability. Something like: def image_create(self, imgtype, cnf={}, master=None, **kw): if not master: master = Tkinter._default_root if not master: raise RuntimeError, 'Too early to create image' if kw and cnf: cnf = _cnfmerge((cnf, kw)) elif kw: cnf = kw options = () for k, v in cnf.items(): if callable(v): v = self._register(v) options = options + ('-'+k, v) return master.tk.call(('image', 'create', imgtype,) + options) def image_delete(self, imgname): try: self.tk.call('image', 'delete', imgname) except TclError: # May happen if the root was destroyed pass ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2002-12-08 10:30 Message: Logged In: YES user_id=38376 MvL wrote: As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. +1 from here. I should probably write an essay some day on why the current behaviour is the only one that makes sense if you consider all common use cases -- if you don't do it this way, you either end up with leaks, code that works only by accident, or code that is a lot more convoluted than the simple assignment that is necessary to work around this problem in real life: photo = PhotoImage(...) widget = Label(master, photo=photo) widget._photo = photo # keep a reference martin has already covered most other issues. </F> ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-08 09:37 Message: Logged In: YES user_id=21627 As there appears to be agreement that the current behaviour cannot be changed, I'd like to propose the attached image.txt as a patch. With this patch, people who want to explicitly delete images need to pass a delete=False option to the image ctor, i.e. i = Tkinter.PhotoImage(file="fn", delete=0) Then, when they want to delete the image, they need to call i.delete() If that is an acceptable solution, I'll apply it to Python 2.3. In the case of the original report, the image would become garbage eventually, since the only reference to delete it was a local variable, which is lost. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 16:57 Message: Logged In: YES user_id=8861 Sorry, my previous comment regarding garbage collection wasn't clear. Consider the following situation: object X refers to object Y and to an image, and object Y refers to object X. The image will not be freed until the garbage collector frees objects X and Y. We worked through almost precisely this set of issues in Smalltalk systems at Xerox PARC, and later at ParcPlace Systems, starting in the early 1970s. Smalltalk, like Python, started out using only reference counting, and added garbage collection much later. However, Smalltalk wasn't trying to interact with a foreign memory management system at arm's length, as Python is with Tk: in my opinion, it's very unfortunate that Tkinter makes the existence of the two separate memory management systems visible to the Python programmer, with consequences like the ones discussed here. However, I have to agree with Martin Loewis that it's too late to change this situation, at least without extending the existing API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-12-07 16:40 Message: Logged In: YES user_id=21627 Yes, backwards compatibility can be preserved by new classes, or by an additional constructor argument (I'd personally prefer the latter). However, I doubt the usefulness of such a new construct: nobody would use it unless they are aware of the issue, and if they are aware of the issue, they can easily solve the problem in a different way. Circular references are a red herring here; no image will ever exist in a circle, since image objects don't refer to other objects. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-12-07 15:36 Message: Logged In: YES user_id=8861 Sorry, I don't agree entirely with either of the responses. 1) I should have said no commonly used *on-screen* entity has this behavior. Backward compatibility can be handled easily by creating new subclasses of Image that have the proposed behavior. (I think I also disagree with the behavior for Variables, since unsetting a variable can also cause the screen appearance to change, but I haven't thought about it carefully enough to have a strong opinion.) 2) This is true only if the last reference to the image is the one being held by CPython. If a circular structure refers to an image, the last reference will be deleted by the garbage collector, not by CPython, so the image will not disappear until garbage collection occurs. I understand the reasoning, and it's not worth it to me to go through the PEP process; I just don't agree. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-13 09:04 Message: Logged In: YES user_id=21627 Peter, I have considered these reasons, and believe they don't apply. 1) Dropping the last reference to a Variable (IntVar, StringVar) also causes the variable to be unset. More importantly, changing the behaviour now would cause backwards incompatibilities: Existing applications rely on not having to release images explicitly. 2) While this may be true in general and for the Python language, it is not the case for CPython and Tkinter.Image specifically. If there are no references to the image anymore, it is released immediately, in CPython, withiyt waiting for garbage collection to be invoked. If you need a way to appeal this decision, you will have to write a PEP. Describe the proposed change and implementation strategy (explaining in detail how your approach solves the backwards compatibility issue), then discuss this proposed change with the Python community. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-12 18:58 Message: Logged In: YES user_id=8861 I disagree strongly with the resolution, for two reasons. 1) No other commonly used entity in the Tkinter API has this counter-intuitive behavior. Widgets do not disappear from the screen if Python holds no references to them. Text strings do not disappear from the screen if Python holds no references to the string object or the font object. (I don't know how this is accomplished.) 2) Python does not, and cannot, guarantee that an object will be finalized and freed immediately when there are no longer any references to it: if the object must be reclaimed by garbage collection, an unpredictable amount of time may elapse. Therefore, in my opinion, it is very undesirable to use object finalization in a way that directly affects the user interface. Please consider changing Tkinter so that it handles Image objects the same way that it apparently handles widgets, fonts, strings, etc. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-07 07:11 Message: Logged In: YES user_id=21627 It is now in the library section. If you think it also ought to be in the Image class, please contribute a patch. However, I think anybody looking at the Image class code could not fail to notice the image delete. I agree that the behaviour is counter-intuitive, but I disagree that automatic addition of a reference would be a solution: 1. It would break backwards-compatibility. A number of text books explicitly mention this issue, and applications make use of this property, relying on the fact that you can drop the last reference to the image and thus release the associated memory. 2. Python cannot possibly track all uses of the command. For example, you could put the image into a StrVar, and then expect to use the StrVar as the value for an image= attribute. So in short, I think educating users is the best we can do, until Tk provides better mechanisms. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-07 06:22 Message: Logged In: YES user_id=33229 > When the BitmapImage object is no longer referenced, it is > finalized; finalization causes "image delete" to be > invoked. Martin, thanks for the explanation. The behaviour is counterintuitive for a Tk wrapper, because in Tk images are eternal unless explicitly deleted. They are not GC'd when they are unreferenced, and that's their documented behaviour. IThe documentation I was refering to was the Image class documentation in Tkinter.py - it makes no mention of this, and as a rule in Python, I didn't think you had to keep a global reference to everything you pass to any function if you want it to be still alive when the function uses it. Perhaps the Label/Canvas/Button instances should keep a reference to it, which would be deleted when the instance is deleted? I know it's not in the Library Reference, as I contributed the Tkinter section, but I think it should be clear in Tkinter.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-05 19:13 Message: Logged In: YES user_id=21627 Mentioning "the docs" is somewhat funny when it comes to Tkinter: there was no documentation on images in the first place. I've added a new section on this in tkinter.tex 1.17. I've also added a Tk wishlist item at http://sourceforge.net/tracker/?func=detail&aid=633300&group_id=12997&atid=362997 If they ever act on this, we can improve Tkinter in this respect. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-05 18:23 Message: Logged In: YES user_id=6380 Let's close this as Not A Bug. Maybe it needs to be fixed in the docs? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-04 04:26 Message: Logged In: YES user_id=21627 When the BitmapImage object is no longer referenced, it is finalized; finalization causes "image delete" to be invoked. Tcl does not keep a reference to the image object; if you don't yourself, nobody does. In turn, the image object goes away right after being created. The right approach would be for Tcl to somehow keep a reference to the Python object, but I think this is unimplementable. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-03 16:42 Message: Logged In: YES user_id=8861 The bug does *not* manifest with the following definition for init(): def init(self): self.img = self.init1() self.init2(self.img) I think this is even stronger evidence that we're seeing a reference counting / garbage collection / finalization (?) problem. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 02:14 Message: Logged In: YES user_id=33229 This may be the same as what I'm seeing in Demo/tix/tixwidgets.py Look for image1 in tixwidgets.py: I put the following comment in the code: # This image is not showing up under Python unless it is set to a # global variable - no problem under Tcl. I assume it is being garbage # collected some how, even though the tcl command 'image names' shows # that as far as Tcl is concerned, the image exists and is called pyimage1. Can anyone explain to me what's going on? IMHO, either this is a Tkinter bug, or a documentation bug because the documentation does not explain to me why this image1 has to be global, or am I missing something here. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2002-11-02 01:32 Message: Logged In: YES user_id=8861 Comment #1: This bug is still there in Python 2.2.2. Comment #2: Using a variable isn't the whole story. The bug also manifests if I define: def init(self): img = self.init1() self.init2(img) and then have the calling program invoke self.init(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=632323&group_id=5470 From noreply at sourceforge.net Tue Dec 28 06:18:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 06:18:28 2004 Subject: [ python-Bugs-649974 ] urllib.url2pathname, pathname2url doc strings inconsistent Message-ID: Bugs item #649974, was opened at 2002-12-07 02:22 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 >Category: Documentation >Group: Python 2.4 Status: Open Resolution: None >Priority: 3 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) >Summary: urllib.url2pathname, pathname2url doc strings inconsistent Initial Comment: The Unix version of urllib.url2pathname(), when given a file URL that contains a host part, returns a path with the host embedded in the URL, despite the fact that there is no convention for mapping the host into the URL. The resulting path is not usable. For example, on Windows, there is a convention for mapping the host part of a URL to and from a NetBIOS name. url2pathname('//somehost/path/to/file') returns r'\somehost\path\to\file' which is safe to pass into open () or os.access(). But on Unix, there is no such convention. url2pathname ('//somehost/path/to/file') returns '//somehost/path/to/file', which means the same thing as '/somehost/path/to/file' -- somehost is just another path segment and does not actually designate a host. In my opinion, an exception should be raised in this situation; url2pathname() should not try to produce an OS path for a remote machine when there is no convention for referencing a remote machine in that OS's traditional path format. This way, if no exception is raised, you know that it's safe to pass the result into open() or os.access(). And as noted in other bug reports, 'file://localhost/' is a special case that should be treated the same as 'file:///'. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 22:18 Message: Logged In: YES user_id=371366 OK. I changed the group to Python 2.4, changed the category to Documentation, changed the summary, and lowered the priority. Since there are doc strings for the non-posix versions of url2pathname() and pathname2url(), please just consider the patches I created to be just making all of the docs consistent among each other and consistent with the module-level docs you pointed out. Thanks! -Mike ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 17:32 Message: Logged In: YES user_id=752496 The documentation for urllib states that: Although the urllib module contains (undocumented) routines to parse and unparse URL strings, the recommended interface for URL manipulation is in module urlparse. So, if you think that the files should also be modified, change the group of this bug to 2.4. Otherwise it will be closed as won't fix. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:15 Message: Logged In: YES user_id=371366 See also #649961, where I propose the same solution. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:04 Message: Logged In: YES user_id=371366 pathname2url and url2pathname are undocumented and are urllib- and platform-specific. My complaints in this old bug report are based on assumptions that thse functions are general-purpose public interfaces. Upon further investigation, I see that they are not. I suggest leaving the implementations unchanged for now; there are too many issues with doing it 'right' to go into here. But perhaps add documentation that is consistent and indicates that the functions are limited in scope. Patches attached. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:52 Message: Logged In: YES user_id=752496 Could you please provide a test case? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-26 07:52 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-12-10 23:56 Message: Logged In: YES user_id=250749 There is a sort of convention in Unix - somehost:/path/to/file which comes from NFS, but has been used by tar (for remote tapes via rsh) and ssh's scp, and I believe has been used by some ftp clients (ncftp?) However as far as I know you can't pass such a path to open () or os.access(), so your basic point still has validity. ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2002-12-07 02:24 Message: Logged In: YES user_id=371366 by 'host embedded in the URL' in the first sentence I meant 'host embedded in it' [the path] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649974&group_id=5470 From noreply at sourceforge.net Tue Dec 28 06:25:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 06:25:13 2004 Subject: [ python-Bugs-649961 ] nturl2path.url2pathname() mishandles /// Message-ID: Bugs item #649961, was opened at 2002-12-07 01:19 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 Category: Windows Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: nturl2path.url2pathname() mishandles /// Initial Comment: On Windows, urllib.url2pathname('///path/to/file') returns r'\\path\to\file'. This path cannot be used in things like open() and os.access(). It should probably return r'\path\to\file'. In addition, '//localhost/path/to/file' is a special case that should become '\path\to\file'. I'll post this as a separate bug since it affects all file URIs. ---------------------------------------------------------------------- >Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 22:25 Message: Logged In: YES user_id=371366 Ah, gotcha. I am closing this as "Wont Fix", myself. I have modified the description of #649974 to make it be a Documentation enhancement for 2.4. My proposed patches in that report will satisfy my concerns without going into unnecessary detail. Thanks! -Mike ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 17:32 Message: Logged In: YES user_id=752496 The documentation for urllib states that: Although the urllib module contains (undocumented) routines to parse and unparse URL strings, the recommended interface for URL manipulation is in module urlparse. So, if you think that the files should also be modified, change the group of this bug to 2.4. Otherwise it will be closed as won't fix. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-27 17:32 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-12-27 00:12 Message: Logged In: YES user_id=371366 See #649974 -- url2pathname() and pathname2url() are undocumented, platform-specific, and not really general-purpose. It probably should not be assumed that they are intended to produce values that are usable with open(), os.access(), or anything other than where they are currently used internally in urllib. The solution as proposed for #649974 is probably just to document the functions and discourage their general use. See the suggested diffs attached to that report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649961&group_id=5470 From noreply at sourceforge.net Tue Dec 28 16:31:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 16:31:56 2004 Subject: [ python-Bugs-1092225 ] IDLE hangs due to subprocess Message-ID: Bugs item #1092225, was opened at 2004-12-28 16:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ZACK (kitanek) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE hangs due to subprocess Initial Comment: IDLE GUI hangs after some time when launched in the default mode (i.e. with the subprocess). I have noticed that the subprocess generates fast continuous stream of system calls even if the GUI is not used and not visible (moved to another desktop). Example output from strace (strace -f idle): ... [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] select(4, [3], [], [], {0, 50000} [pid 5355] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) [pid 5355] write(7, "\0", 1 [pid 5356] <... select resumed> ) = 1 (in [6]) [pid 5355] <... write resumed> ) = 1 [pid 5356] futex(0x81c7250, FUTEX_WAIT, 2, NULL [pid 5355] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5356] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable) [pid 5355] <... futex resumed> ) = 0 [pid 5356] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5355] gettimeofday( [pid 5356] <... futex resumed> ) = 0 [pid 5355] <... gettimeofday resumed> {1104246902, 467914}, {4294967236, 0}) = 0 [pid 5356] read(6, [pid 5355] gettimeofday( [pid 5356] <... read resumed> "\0", 1) = 1 [pid 5355] <... gettimeofday resumed> {1104246902, 468040}, {4294967236, 0}) = 0 [pid 5356] select(7, [6], [], [], NULL [pid 5355] select(6, [5], [], [], {0, 50000} [pid 5357] <... select resumed> ) = 0 (Timeout) [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] select(0, NULL, NULL, NULL, {0, 50000} [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 ... If IDLE is launched without the subprocess (idle -n) than it seems to run just fine without the syscall storm: futex(0x83d1fa0, FUTEX_WAIT, 200, NULL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 From noreply at sourceforge.net Tue Dec 28 16:38:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 16:38:33 2004 Subject: [ python-Bugs-1092225 ] IDLE hangs due to subprocess Message-ID: Bugs item #1092225, was opened at 2004-12-28 16:31 Message generated for change (Comment added) made by kitanek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ZACK (kitanek) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE hangs due to subprocess Initial Comment: IDLE GUI hangs after some time when launched in the default mode (i.e. with the subprocess). I have noticed that the subprocess generates fast continuous stream of system calls even if the GUI is not used and not visible (moved to another desktop). Example output from strace (strace -f idle): ... [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] select(4, [3], [], [], {0, 50000} [pid 5355] <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) [pid 5355] write(7, "\0", 1 [pid 5356] <... select resumed> ) = 1 (in [6]) [pid 5355] <... write resumed> ) = 1 [pid 5356] futex(0x81c7250, FUTEX_WAIT, 2, NULL [pid 5355] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5356] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable) [pid 5355] <... futex resumed> ) = 0 [pid 5356] futex(0x81c7250, FUTEX_WAKE, 1 [pid 5355] gettimeofday( [pid 5356] <... futex resumed> ) = 0 [pid 5355] <... gettimeofday resumed> {1104246902, 467914}, {4294967236, 0}) = 0 [pid 5356] read(6, [pid 5355] gettimeofday( [pid 5356] <... read resumed> "\0", 1) = 1 [pid 5355] <... gettimeofday resumed> {1104246902, 468040}, {4294967236, 0}) = 0 [pid 5356] select(7, [6], [], [], NULL [pid 5355] select(6, [5], [], [], {0, 50000} [pid 5357] <... select resumed> ) = 0 (Timeout) [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5357] select(0, NULL, NULL, NULL, {0, 50000} [pid 5359] <... select resumed> ) = 0 (Timeout) [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 [pid 5359] futex(0x81fb798, FUTEX_WAKE, 1) = 0 ... If IDLE is launched without the subprocess (idle -n) than it seems to run just fine without the syscall storm: futex(0x83d1fa0, FUTEX_WAIT, 200, NULL ---------------------------------------------------------------------- >Comment By: ZACK (kitanek) Date: 2004-12-28 16:38 Message: Logged In: YES user_id=1159448 Sorry, I forgot the system specs: Debian Linux, unstable branche (SID) Kernel 2.6.9-1-686 Python 2.3.4 (#2, Dec 3 2004, 13:53:17) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 glib-config --version = 1.2.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092225&group_id=5470 From noreply at sourceforge.net Tue Dec 28 16:59:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 16:59:23 2004 Subject: [ python-Bugs-1092240 ] slice [0:] default is len-1 not len Message-ID: Bugs item #1092240, was opened at 2004-12-28 15:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092240&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Phillips (smoothpodengo) Assigned to: Nobody/Anonymous (nobody) Summary: slice [0:] default is len-1 not len Initial Comment: In this url of my python 2.3 distribution, the tutorial document, section 3.1.2 needs this change. Change: second index defaults to the size of the second string being sliced. To: second index defaults to the size of the second string being sliced minus 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092240&group_id=5470 From noreply at sourceforge.net Tue Dec 28 17:17:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 17:17:27 2004 Subject: [ python-Bugs-1092240 ] slice [0:] default is len-1 not len Message-ID: Bugs item #1092240, was opened at 2004-12-28 15:59 Message generated for change (Comment added) made by smoothpodengo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092240&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Robert Phillips (smoothpodengo) Assigned to: Nobody/Anonymous (nobody) Summary: slice [0:] default is len-1 not len Initial Comment: In this url of my python 2.3 distribution, the tutorial document, section 3.1.2 needs this change. Change: second index defaults to the size of the second string being sliced. To: second index defaults to the size of the second string being sliced minus 1. ---------------------------------------------------------------------- >Comment By: Robert Phillips (smoothpodengo) Date: 2004-12-28 16:17 Message: Logged In: YES user_id=1186030 Please nochange this MR. I have seen the light. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092240&group_id=5470 From noreply at sourceforge.net Tue Dec 28 20:15:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 20:16:04 2004 Subject: [ python-Bugs-1092240 ] slice [0:] default is len-1 not len Message-ID: Bugs item #1092240, was opened at 2004-12-28 16:59 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092240&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Robert Phillips (smoothpodengo) Assigned to: Nobody/Anonymous (nobody) Summary: slice [0:] default is len-1 not len Initial Comment: In this url of my python 2.3 distribution, the tutorial document, section 3.1.2 needs this change. Change: second index defaults to the size of the second string being sliced. To: second index defaults to the size of the second string being sliced minus 1. ---------------------------------------------------------------------- Comment By: Robert Phillips (smoothpodengo) Date: 2004-12-28 17:17 Message: Logged In: YES user_id=1186030 Please nochange this MR. I have seen the light. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092240&group_id=5470 From noreply at sourceforge.net Tue Dec 28 20:24:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 20:24:16 2004 Subject: [ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault Message-ID: Bugs item #1083110, was opened at 2004-12-10 13:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Sam Rushing (rushing) Assigned to: A.M. Kuchling (akuchling) Summary: truncated gzip file triggers zlibmodule segfault Initial Comment: If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:24 Message: Logged In: YES user_id=11375 Smaller test case: import zlib o = zlib.decompressobj() d = o.flush() It segfaults in PyZlib_unflush(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:43 Message: Logged In: YES user_id=80475 On WinME, I can confirm segfaults in Py2.3 and Py2.4. Andrew, I think this is your baby. BTW, the OP's example would make an excellent testcase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 From noreply at sourceforge.net Tue Dec 28 20:38:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 20:38:21 2004 Subject: [ python-Feature Requests-1092365 ] Distutils needs a way *not* to install files Message-ID: Feature Requests item #1092365, was opened at 2004-12-28 19:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092365&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils needs a way *not* to install files Initial Comment: Sometimes you want distutils *not* to install certain files, for instance Dulcinea's scripts. Currently you have to install them to a bogus directory (e.g., /tmp/None) and then delete them. It would be nicer to have a special value for --install-* (e.g., 'None', 'NONE', '/dev/null'), or a set of --no-install-* flags. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092365&group_id=5470 From noreply at sourceforge.net Tue Dec 28 20:59:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 20:59:58 2004 Subject: [ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault Message-ID: Bugs item #1083110, was opened at 2004-12-10 13:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Sam Rushing (rushing) Assigned to: A.M. Kuchling (akuchling) Summary: truncated gzip file triggers zlibmodule segfault Initial Comment: If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:59 Message: Logged In: YES user_id=11375 If flush() is called without an intervening .decompress() call, some fields in the zlib structure are left uninitialized. I'll check in a test and fix. The same problem exists with compression objects, but calling flush() doesn't result in a segfault. Perhaps the zlib code for deflate() doesn't end up dereferencing the garbage fields; I'll check in a fix anyway. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:24 Message: Logged In: YES user_id=11375 Smaller test case: import zlib o = zlib.decompressobj() d = o.flush() It segfaults in PyZlib_unflush(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:43 Message: Logged In: YES user_id=80475 On WinME, I can confirm segfaults in Py2.3 and Py2.4. Andrew, I think this is your baby. BTW, the OP's example would make an excellent testcase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 From noreply at sourceforge.net Tue Dec 28 21:14:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 21:14:45 2004 Subject: [ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault Message-ID: Bugs item #1083110, was opened at 2004-12-10 13:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Sam Rushing (rushing) Assigned to: A.M. Kuchling (akuchling) Summary: truncated gzip file triggers zlibmodule segfault Initial Comment: If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 15:14 Message: Logged In: YES user_id=11375 Test case and fix committed: Modules/zlibmodule.c: 2.67 Lib/test/test_zlib.py: 1.27 Misc/NEWS:1.1214 Backporting 2.4; will check 2.3. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:59 Message: Logged In: YES user_id=11375 If flush() is called without an intervening .decompress() call, some fields in the zlib structure are left uninitialized. I'll check in a test and fix. The same problem exists with compression objects, but calling flush() doesn't result in a segfault. Perhaps the zlib code for deflate() doesn't end up dereferencing the garbage fields; I'll check in a fix anyway. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:24 Message: Logged In: YES user_id=11375 Smaller test case: import zlib o = zlib.decompressobj() d = o.flush() It segfaults in PyZlib_unflush(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:43 Message: Logged In: YES user_id=80475 On WinME, I can confirm segfaults in Py2.3 and Py2.4. Andrew, I think this is your baby. BTW, the OP's example would make an excellent testcase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 From noreply at sourceforge.net Tue Dec 28 21:32:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 21:33:02 2004 Subject: [ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule segfault Message-ID: Bugs item #1083110, was opened at 2004-12-10 13:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Sam Rushing (rushing) Assigned to: A.M. Kuchling (akuchling) Summary: truncated gzip file triggers zlibmodule segfault Initial Comment: If gzip.py reads a mangled/truncated file and leaves the file pointer at EOF, the zlibmodule will crash when it calls 'flush' (PyZlib_unflush()). I've traced through zlib a bit, and I think the problem is that the 'avail_in' slot of the decompression struct is left uninitialized. The problem can be made to go away by setting that slot to zero in either PyZlib_decompressobj(), or in PyZlib_unflush() itself. However, I'm not familiar enough with the code to know if there's some other reason the slot contains garbage. Reproduction: >>> open ('x.gz', 'wb').write ('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00') >>> import gzip >>> gzip.GzipFile ('x.gz', 'rb').read() Segmentation fault (core dumped) [the above data is simply a small gzip file truncated after the zero-terminated filename] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 15:32 Message: Logged In: YES user_id=11375 Applied to 2.4 and 2.3 maintenance branches. (2.2 is probably affected, too, but I won't bother to backport the fix.) Closing bug. Thanks for reporting the problem! ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 15:14 Message: Logged In: YES user_id=11375 Test case and fix committed: Modules/zlibmodule.c: 2.67 Lib/test/test_zlib.py: 1.27 Misc/NEWS:1.1214 Backporting 2.4; will check 2.3. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:59 Message: Logged In: YES user_id=11375 If flush() is called without an intervening .decompress() call, some fields in the zlib structure are left uninitialized. I'll check in a test and fix. The same problem exists with compression objects, but calling flush() doesn't result in a segfault. Perhaps the zlib code for deflate() doesn't end up dereferencing the garbage fields; I'll check in a fix anyway. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 14:24 Message: Logged In: YES user_id=11375 Smaller test case: import zlib o = zlib.decompressobj() d = o.flush() It segfaults in PyZlib_unflush(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 22:43 Message: Logged In: YES user_id=80475 On WinME, I can confirm segfaults in Py2.3 and Py2.4. Andrew, I think this is your baby. BTW, the OP's example would make an excellent testcase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470 From noreply at sourceforge.net Tue Dec 28 21:34:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 21:34:57 2004 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-22 14:22 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) >Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 15:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-23 11:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Tue Dec 28 21:42:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 28 21:42:59 2004 Subject: [ python-Bugs-1080713 ] os.ttyname() accepts wrong arguments Message-ID: Bugs item #1080713, was opened at 2004-12-07 11:32 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080713&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Christian H?ltje (docwhat) >Assigned to: A.M. Kuchling (akuchling) Summary: os.ttyname() accepts wrong arguments Initial Comment: Problem: The doc for os.ttyname says it accepts an fd What Happens: It raises a type error and says it expects an integer instead. Experimentally, it seems to accept fd.fileno() as input What should happen: It should an accept an fd (file object) I have attached a test case for this. The output I get using python 2.2 & 2.3 is: Documentation Sez: ------------------------------------------------------------ ttyname(fd) -> String Return the name of the terminal device connected to 'fd'. ------------------------------------------------------------ TTY Name (should work): exceptions.TypeError an integer is required TTY Name (shouldn't work): /dev/pts/2 Ciao! ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 15:42 Message: Logged In: YES user_id=11375 No, file descriptors are small integers corresponding to a file opened by the current process. File descriptors are not the same as file objects; as you've discovered, you can get the file descriptor for a file object by calling the .fileno() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1080713&group_id=5470 From noreply at sourceforge.net Wed Dec 29 00:51:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 29 00:51:48 2004 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-22 11:22 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-28 15:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-28 12:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-23 08:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Wed Dec 29 03:09:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 29 03:09:39 2004 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-28 21:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Wed Dec 29 06:54:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 29 06:54:25 2004 Subject: [ python-Bugs-1089974 ] mmap missing offset parameter Message-ID: Bugs item #1089974, was opened at 2004-12-23 04:22 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-29 14:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 08:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 05:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 01:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 From noreply at sourceforge.net Wed Dec 29 15:30:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 29 15:30:52 2004 Subject: [ python-Bugs-1092701 ] os.remove fails on win32 with read-only file Message-ID: Bugs item #1092701, was opened at 2004-12-29 09:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092701&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joshua Weage (jpweage) Assigned to: Nobody/Anonymous (nobody) Summary: os.remove fails on win32 with read-only file Initial Comment: On Windows XP SP2 and Python 2.3.3 or 2.4 a call to os.remove returns Errno 13 permission denied on a read-only file. On linux, python will delete a read-only file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092701&group_id=5470 From noreply at sourceforge.net Wed Dec 29 22:52:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 29 22:52:58 2004 Subject: [ python-Bugs-1092962 ] Make Generators Pickle-able Message-ID: Bugs item #1092962, was opened at 2004-12-29 21:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092962&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jayson Vantuyl (jaysonvantuyl) Assigned to: Nobody/Anonymous (nobody) Summary: Make Generators Pickle-able Initial Comment: Would it be possible to make generators pickle-able? I mean, currently the internal state is saved in some way. Would it be possible to make pickle handle them? Put another way, if generators had a __getnewargs__ function that returned some data (say a tuple of module name, function name, locals/globals dicts and some code dependent location data) and then allow: generator.__new__(statedata) to reconstruct it (or something more elegant). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092962&group_id=5470 From noreply at sourceforge.net Thu Dec 30 03:54:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 03:54:36 2004 Subject: [ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off Message-ID: Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Open >Resolution: Accepted >Priority: 5 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-29 21:54 Message: Logged In: YES user_id=149084 OK, thanks for the leg work. I'll take a further look. My keyboards are IBM Model M SpaceSavers. I don't do keypads... :-) ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-12-24 19:32 Message: Logged In: YES user_id=1167414 I posted the "bug" on the Tk list as suggested. Today I got this: begin quote >Comment By: Jeffrey Hobbs (hobbs) Date: 2004-12-24 11:25 Message: Logged In: YES user_id=72656 This is not a bug, but rather just that Tk differentiates between the regular arrow up and keypad up on some systems, depending on how their system keymaps operate. The first is and the second is on Linux, but both are on Windows. This has always been the case for KP_Enter as well. The fact that Windows doesn't separate these is by design, but has also caused people to want them separated (see TIP http://www.tcl.tk/cgi-bin/tct/tip/158.html). IOW, the bindings should be on and if they are to be considered equivalent in an app. This is best handled by using virtual events (like <>) and adding the specific event names that you want to apply to it. Please filter this back to the other reports. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1090719&group_id=12997 end quote Would someone please either reopen this or let me know what my next step should be. Thanks, Rick ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-20 07:59 Message: Logged In: YES user_id=469548 OP = opening poster. So yes, the ball is in your court. :) ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-12-20 01:14 Message: Logged In: YES user_id=1167414 > Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ 1) Who is OP? 2) Is this ball in my court or someone else's? Thanks, netvigator aka Rick Graves ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 18:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. ---------------------------------------------------------------------- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074333&group_id=5470 From noreply at sourceforge.net Thu Dec 30 10:43:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 10:43:53 2004 Subject: [ python-Bugs-1093173 ] distutils/tests not installed Message-ID: Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 From noreply at sourceforge.net Thu Dec 30 15:11:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 15:11:59 2004 Subject: [ python-Bugs-1093173 ] distutils/tests not installed Message-ID: Bugs item #1093173, was opened at 2004-12-30 10:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 15:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 From noreply at sourceforge.net Thu Dec 30 15:16:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 15:16:14 2004 Subject: [ python-Feature Requests-1092962 ] Make Generators Pickle-able Message-ID: Feature Requests item #1092962, was opened at 2004-12-29 22:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayson Vantuyl (jaysonvantuyl) Assigned to: Nobody/Anonymous (nobody) Summary: Make Generators Pickle-able Initial Comment: Would it be possible to make generators pickle-able? I mean, currently the internal state is saved in some way. Would it be possible to make pickle handle them? Put another way, if generators had a __getnewargs__ function that returned some data (say a tuple of module name, function name, locals/globals dicts and some code dependent location data) and then allow: generator.__new__(statedata) to reconstruct it (or something more elegant). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 15:16 Message: Logged In: YES user_id=21627 Moving into the feature requests tracker. I don't think this is possible (or should be done if it were possible). Pickle has traditionally abstained from pickling functions, so IMO it should not picke generators, either. If this was enabled by default, it would open up yet another security hole. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 From noreply at sourceforge.net Thu Dec 30 16:28:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 16:28:09 2004 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Thu Dec 30 17:38:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 17:38:05 2004 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Thu Dec 30 17:44:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 17:44:24 2004 Subject: [ python-Bugs-1086642 ] Compile of _socket fails on 2.4 Message-ID: Bugs item #1086642, was opened at 2004-12-16 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.000000000 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include "addrinfo.h" #endif +#if defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x00000002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. ---------------------------------------------------------------------- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 From noreply at sourceforge.net Thu Dec 30 19:36:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 19:36:04 2004 Subject: [ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs Message-ID: Bugs item #1093389, was opened at 2004-12-30 11:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joe Hildebrand (hildjj) Assigned to: Nobody/Anonymous (nobody) Summary: mapitags.PROP_TAG() doesn't account for new longs Initial Comment: Test case: >>> from win32com.mapi.mapitags import * >>> PROP_TAG(PT_LONG, 0x8041) 2151743491L Should be: -2143223805L or, alternately, the rest of the mapi interfaces should know about unsigned ints. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&group_id=5470 From noreply at sourceforge.net Thu Dec 30 19:37:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 30 19:37:39 2004 Subject: [ python-Feature Requests-1092962 ] Make Generators Pickle-able Message-ID: Feature Requests item #1092962, was opened at 2004-12-29 21:52 Message generated for change (Comment added) made by jaysonvantuyl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayson Vantuyl (jaysonvantuyl) Assigned to: Nobody/Anonymous (nobody) Summary: Make Generators Pickle-able Initial Comment: Would it be possible to make generators pickle-able? I mean, currently the internal state is saved in some way. Would it be possible to make pickle handle them? Put another way, if generators had a __getnewargs__ function that returned some data (say a tuple of module name, function name, locals/globals dicts and some code dependent location data) and then allow: generator.__new__(statedata) to reconstruct it (or something more elegant). ---------------------------------------------------------------------- >Comment By: Jayson Vantuyl (jaysonvantuyl) Date: 2004-12-30 18:37 Message: Logged In: YES user_id=626872 I'm not talking about pickling functions. Which, by the way, is not entirely accurate. See the following: >>> from pickle import dumps,loads >>> loads(dumps(dumps)) >>> As you see, we don't pickle the function code, just a reference to it. I propose doing the same with generators, but including the function namespace and frame info in the pickle to allow it to continue execution after unpickling. Furthermore, this is nothing more than what the interpreter already does internally. When a generator yields, all of its state is neatly stashed away. I just would like pickle to be able to get at it, store it, and then later recover it--without dealing with any actual code objects, just the state. As for security, what I am talking about is nothing more or less secure than pickling classes. When we pickle a class, we don't pickle the methods on it. Rather, we pickle the information to reconstruct the class (__getstate__, __getnewargs__, __reduce__). There is a security concern in that modified pickles could be used to put bogus data into the unpickled classes (i.e. a password stored as an attribute on a class could be replaced). What I'm asking for is nothing more than pickling a form of the frozen frame object (or something akin to it) for the generator. Put another way, when the generator isn't running, something stores the entire state of its execution. I'm not sure what it is, but I'd be willing to be it consists of little more than a few dicts (namespaces), some scoping info, and some sort of instruction pointer. By pickling the generator, I propose nothing more radical than pickling a class. The generator is still instantiated from the some code as before (just as a class or function reference is) and it still can/will act on that information (just as a class does). No actual code is pickled. What this does allow is the use of generators for efficent handling of a class. Specifically, I'm writing an application that uses a seeded pseudo-random number generator. The idea is to transmit the state of the generator over the network so that the client/server can deterministically make the same random choices without communicating the complex state that results from that. I have a choice of the following: def randfunc(seed,num,otherstate): # Costly Setup # Iteration to appropriate number otherside.sendPickle( (seed,num,otherstate,) ) l = [ randfunc(123,i,...) for i in range(5) ] Versus def randGen(seed): # Costly Setup # yield in a simple loop r = randGen(123) otherside.sendPickle(r) l = [ r() for i in range(5) ] I think you can see which one is more efficient in terms of both simplicity of expression and ease of coding. Of course, the standard answer to this is to implement a randgen class that contains all of the state. This complicates the code a great deal, since a generator can't be used. What is problematic is that generators are like black holes. Once information goes into them, it won't come back out. There's not a good way to use them for anything more than runtime. This rules out things like process migration, pickling of any structure involving generator data, and generally using them like any other language component. Using them for counters, prngs, prime number generators, OGR sieves, and anything that needs to be used to durably generate a sequence is impossible if that data needs to be persisted. No one would think about implementing a new pickle without the ability to represent classes and function references, generators shouldn't be second class control structures. FYI, Stackless Python already does this, but it may be easier for them due to the way they've modified frame handling. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 14:16 Message: Logged In: YES user_id=21627 Moving into the feature requests tracker. I don't think this is possible (or should be done if it were possible). Pickle has traditionally abstained from pickling functions, so IMO it should not picke generators, either. If this was enabled by default, it would open up yet another security hole. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 From noreply at sourceforge.net Fri Dec 31 02:08:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 31 02:08:52 2004 Subject: [ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called Message-ID: Bugs item #1090139, was opened at 2004-12-22 20:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) Assigned to: Raymond Hettinger (rhettinger) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text:
args
should be changed to:
args
to match the rest of the items on the page. This may require changing the LaTeX. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-30 20:08 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 From noreply at sourceforge.net Fri Dec 31 03:32:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 31 03:36:07 2004 Subject: [ python-Bugs-1086603 ] segfault in readline Message-ID: Bugs item #1086603, was opened at 2004-12-16 13:02 Message generated for change (Comment added) made by dsm001 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import readline [25290 refs] >>> readline.remove_history_item(-1) Segmentation fault >>> readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. ---------------------------------------------------------------------- >Comment By: DSM (dsm001) Date: 2004-12-30 21:32 Message: Logged In: YES user_id=1175690 This one being simple enough for the likes of me to patch, I did so -- 1093585. Let the school of hard knocks begin! ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-20 05:57 Message: Logged In: YES user_id=671362 I'm +1 for sanity checking rather than waiting for the GNU readline to return NULL in these functions. It's just adding a few lines of code right after PyArg_ParseTuple : if (entry_number < 0) { PyErr_SetString(PyExc_ValueError, "index cannot be a negative value"); return NULL; } Then you can work around the problem without worrying about the return value of remove_history nor replace_history_entry. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-19 11:41 Message: Logged In: YES user_id=6656 Do you want to fix it then? :) I can't imagine it's that hard, but it would be easier for someone who can test that their fix helps... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-12-18 05:45 Message: Logged In: YES user_id=671362 FYI, I can reproduce this with : - Python 2.4 & readline 4.3 under SuSE 9.1 - Python 2.5(snapshot as of 2004-12-17) & readline 4.3 under SuSE 9.1 - Python 2.4 & readline 4.3.5(?) under Cygwin ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-12-17 09:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_id=5470 From noreply at sourceforge.net Fri Dec 31 10:35:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 31 10:35:45 2004 Subject: [ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called Message-ID: Bugs item #1090139, was opened at 2004-12-23 02:00 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) >Assigned to: Greg Ward (gward) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text:
args
should be changed to:
args
to match the rest of the items on the page. This may require changing the LaTeX. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-31 10:35 Message: Logged In: YES user_id=469548 I think the optparse documentation is automatically generated from the optik ReST docs, so Greg should take a look at this as well. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-31 02:08 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 From noreply at sourceforge.net Fri Dec 31 12:23:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 31 12:23:39 2004 Subject: [ python-Bugs-1091468 ] DESTROOTed frameworkinstall fails Message-ID: Bugs item #1091468, was opened at 2004-12-26 22:17 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091468&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: DESTROOTed frameworkinstall fails Initial Comment: A "make frameworkinstall" with DESTROOT will fail if the same version of Python you're trying to install destrooted has not also been installed normally beforehand. The reason is that some of the parameters to the applet-building tools are filenames that are actually read while building the applet, and these files don't exist. Other filenames, however, are recorded for use during runtime, so passing the DESTROOTed filenames will also not work. A fix for this needs to be applied to 2.3.X and 2.4.X too, so fink and darwinports maintainers can benefit too. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-12-31 12:23 Message: Logged In: YES user_id=45365 Fixed in CVS, on the trunk and 23 and 24 maintainance branches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1091468&group_id=5470 From nicolas.kowenski at softogo.com Fri Dec 17 21:54:41 2004 From: nicolas.kowenski at softogo.com (Nicolas Kowenski) Date: Mon Jan 3 06:16:03 2005 Subject: I founded a bug. Message-ID: <41C31D07.7030800@softogo.com> script: (to extend c++ in python) filename: *stpwsusr.py CANT BE "wsusr.py"!!!!!!!!!!!!!!! its bad,because everybody usally name the files like the program/module. *source: /*********************************************/ from distutils.core import setup, Extension mylib_dirs=['/home/dev/WireLessStudio/wsusrlib/debug/src'] libs_trace=['*wsusr*'] <- My module 's name. module3 = Extension('wsl', sources = ['srcwsl.cpp'], library_dirs=mylib_dirs, libraries = libs_trace) setup (name = 'PackageName', version = '1.0', description = 'probando claes en piton, gross', ext_modules = [module3]) /******************************************/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-bugs-list/attachments/20041217/99f3f1a0/attachment.html From noreply at sourceforge.net Mon Dec 6 03:18:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:28 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 04:47 Message generated for change (Comment added) made by guanzijing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: guan zi jing (guanzijing) Date: 2004-12-06 02:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 19:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 02:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 12:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Mon Dec 6 22:56:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:35 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 05:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:56 Message: Logged In: YES user_id=21627 Ok. Can you please put the following code in a file called "x.vbs", and run x.vbs in a cmd.exe window? ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-06 03:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 03:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 13:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Tue Dec 7 03:27:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:39 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 04:47 Message generated for change (Comment added) made by guanzijing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: guan zi jing (guanzijing) Date: 2004-12-07 02:27 Message: Logged In: YES user_id=923521 I run it, and get this error: MessageBox: Script: C:\v.vbs Line: 2 Char: 7 Error: ActiveX component can't create object: 'Scripting.FileSystemObject' Code: 800A01AD Source: Microsoft VBScript runtime error ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 21:56 Message: Logged In: YES user_id=21627 Ok. Can you please put the following code in a file called "x.vbs", and run x.vbs in a cmd.exe window? ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-06 02:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 19:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 02:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 12:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Tue Dec 7 07:38:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:43 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 05:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 07:38 Message: Logged In: YES user_id=21627 Ok, can you please install VBScript from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en and then try again? ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-07 03:27 Message: Logged In: YES user_id=923521 I run it, and get this error: MessageBox: Script: C:\v.vbs Line: 2 Char: 7 Error: ActiveX component can't create object: 'Scripting.FileSystemObject' Code: 800A01AD Source: Microsoft VBScript runtime error ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:56 Message: Logged In: YES user_id=21627 Ok. Can you please put the following code in a file called "x.vbs", and run x.vbs in a cmd.exe window? ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-06 03:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 03:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 13:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Tue Dec 7 08:23:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:47 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 04:47 Message generated for change (Comment added) made by guanzijing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: guan zi jing (guanzijing) Date: 2004-12-07 07:23 Message: Logged In: YES user_id=923521 Oh yes, It works. Before install the new wscript I check my wscript's version : I found: C:\WINDOWS\SYSTEM32\wscript.exe (5.6.0.8820) C:\WINDOWS\ServicePackFiles\i386\wscript.exe (5.6.0.8820) C:\WINDOWS\SoftwareDistribution\Download\6ca7b3a8ef d5a9b6f87fff395a2eb989\wscript.exe (5.6.0.8820) After install the version 5.6.0.8825, I can install python2.4.msi. Thank you very much. :B ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 06:38 Message: Logged In: YES user_id=21627 Ok, can you please install VBScript from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en and then try again? ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-07 02:27 Message: Logged In: YES user_id=923521 I run it, and get this error: MessageBox: Script: C:\v.vbs Line: 2 Char: 7 Error: ActiveX component can't create object: 'Scripting.FileSystemObject' Code: 800A01AD Source: Microsoft VBScript runtime error ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 21:56 Message: Logged In: YES user_id=21627 Ok. Can you please put the following code in a file called "x.vbs", and run x.vbs in a cmd.exe window? ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-06 02:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 19:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 02:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 12:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Tue Dec 7 08:39:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:51 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 05:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 08:39 Message: Logged In: YES user_id=21627 It's really unfortunate that VB support is so different across installations. I think I will have to drop it in favour of native code for 2.4.1. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-07 08:23 Message: Logged In: YES user_id=923521 Oh yes, It works. Before install the new wscript I check my wscript's version : I found: C:\WINDOWS\SYSTEM32\wscript.exe (5.6.0.8820) C:\WINDOWS\ServicePackFiles\i386\wscript.exe (5.6.0.8820) C:\WINDOWS\SoftwareDistribution\Download\6ca7b3a8ef d5a9b6f87fff395a2eb989\wscript.exe (5.6.0.8820) After install the version 5.6.0.8825, I can install python2.4.msi. Thank you very much. :B ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 07:38 Message: Logged In: YES user_id=21627 Ok, can you please install VBScript from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en and then try again? ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-07 03:27 Message: Logged In: YES user_id=923521 I run it, and get this error: MessageBox: Script: C:\v.vbs Line: 2 Char: 7 Error: ActiveX component can't create object: 'Scripting.FileSystemObject' Code: 800A01AD Source: Microsoft VBScript runtime error ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:56 Message: Logged In: YES user_id=21627 Ok. Can you please put the following code in a file called "x.vbs", and run x.vbs in a cmd.exe window? ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-06 03:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 03:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 13:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From phillip.watts at anvilcom.com Fri Dec 10 17:35:14 2004 From: phillip.watts at anvilcom.com (phil) Date: Mon Jan 3 06:16:55 2005 Subject: thread/queue bug Message-ID: <41B9D041.5050200@anvilcom.com> I have a very strange bug. A thread in a .pyc stops dead. This program has many threads and queues and has worked great for months. One thread listens for UDP messages from other programs, and puts the messages in listenq. Procmsgs gets from listenq and for a certain kind of message creates another mq = Queue(0). I don't wish to distribute the source to pnetx.py so I have a short program pnet.py import it, that is pnetx.pyc. Then the procmsgs thread dies at the Queue statement. But if I run pnetx.py as the main program, all works fine. So if pnetx.py or .pyc is imported this thread dies. ??? I've tried this with 2.3.3 and 2.3.4. Anyone? From noreply at sourceforge.net Wed Dec 22 13:42:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:16:59 2005 Subject: [ python-Bugs-1076500 ] python24.msi install error Message-ID: Bugs item #1076500, was opened at 2004-12-01 05:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: guan zi jing (guanzijing) Assigned to: Martin v. L?wis (loewis) Summary: python24.msi install error Initial Comment: I can't install the python24.msi on my notebook ( windows (english version with chinese support) xp with sp2 ) the install programe display an error after chose the install path. btw: I installed the office 2003 and norton system works and norton firewall 2003. and the python2.3.4 install is ok. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-22 13:42 Message: Logged In: YES user_id=21627 I have now made the necessary changes to drop reliance on VB for 2.4.1. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 08:39 Message: Logged In: YES user_id=21627 It's really unfortunate that VB support is so different across installations. I think I will have to drop it in favour of native code for 2.4.1. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-07 08:23 Message: Logged In: YES user_id=923521 Oh yes, It works. Before install the new wscript I check my wscript's version : I found: C:\WINDOWS\SYSTEM32\wscript.exe (5.6.0.8820) C:\WINDOWS\ServicePackFiles\i386\wscript.exe (5.6.0.8820) C:\WINDOWS\SoftwareDistribution\Download\6ca7b3a8ef d5a9b6f87fff395a2eb989\wscript.exe (5.6.0.8820) After install the version 5.6.0.8825, I can install python2.4.msi. Thank you very much. :B ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-07 07:38 Message: Logged In: YES user_id=21627 Ok, can you please install VBScript from http://www.microsoft.com/downloads/details.aspx?FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en and then try again? ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-07 03:27 Message: Logged In: YES user_id=923521 I run it, and get this error: MessageBox: Script: C:\v.vbs Line: 2 Char: 7 Error: ActiveX component can't create object: 'Scripting.FileSystemObject' Code: 800A01AD Source: Microsoft VBScript runtime error ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-06 22:56 Message: Logged In: YES user_id=21627 Ok. Can you please put the following code in a file called "x.vbs", and run x.vbs in a cmd.exe window? ========== SNIP ============ Function CheckDir() Set FSO = CreateObject("Scripting.FileSystemObject") if FSO.FolderExists("c:\python24") then wscript.echo "1" else wscript.echo "0" end if End Function CheckDir() ============= SNIP ============== ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-06 03:17 Message: Logged In: YES user_id=923521 And I found the msiexec is still running after the failed, I can find it at the task Manager. This is the log: === Verbose logging started: 2004-12-6 10:14:25 Build type: SHIP UNICODE 3.00.3790.2180 Calling process: C:\WINDOWS\system32\msiexec.exe === MSI (c) (50:A4) [10:14:25:606]: Resetting cached policy values MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'Debug' is 0 MSI (c) (50:A4) [10:14:25:606]: ******* RunEngine: ******* Product: python-2.4.msi ******* Action: ******* CommandLine: ********** MSI (c) (50:A4) [10:14:25:606]: Machine policy value 'DisableUserInstalls' is 0 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Downloads\python-2.4.msi' against software restriction policy MSI (c) (50:A4) [10:14:25:656]: Note: 1: 2262 2: DigitalSignature 3: -2147287038 MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is not digitally signed MSI (c) (50:A4) [10:14:25:656]: SOFTWARE RESTRICTION POLICY: C:\Downloads\python-2.4.msi is permitted to run at the 'unrestricted' authorization level. MSI (c) (50:A4) [10:14:25:726]: Cloaking enabled. MSI (c) (50:A4) [10:14:25:726]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:A4) [10:14:25:736]: End dialog not enabled MSI (c) (50:A4) [10:14:25:736]: Original package ==> C:\Downloads\python-2.4.msi MSI (c) (50:A4) [10:14:25:736]: Package we're running from ==> C:\DOCUME~1\kyo\LOCALS~1\Temp\a0b14.msi MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:746]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:746]: MSCOREE not loaded loading copy from system32 MSI (c) (50:A4) [10:14:25:746]: Machine policy value 'TransformsSecure' is 0 MSI (c) (50:A4) [10:14:25:746]: User policy value 'TransformsAtSource' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisablePatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AllowLockdownPatch' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableLUAPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableFlyWeightPatching' is 0 MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: looking for appcompat database entry with ProductCode '{82D9302E- F209-4805-B548-52087047483A}'. MSI (c) (50:A4) [10:14:25:756]: APPCOMPAT: no matching ProductCode found in database. MSI (c) (50:A4) [10:14:25:756]: Transforms are not secure. MSI (c) (50:A4) [10:14:25:756]: Command Line: CURRENTDIRECTORY=C:\Downloads CLIENTUILEVEL=0 CLIENTPROCESSID=1104 MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{41AF8B44-C87F-44CE- B1B4-A6C8DD67A0BB}'. MSI (c) (50:A4) [10:14:25:756]: Product Code passed to Engine.Initialize: '' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table before transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product Code from property table after transforms: '{82D9302E-F209-4805-B548- 52087047483A}' MSI (c) (50:A4) [10:14:25:756]: Product not registered: beginning first-time install MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding ProductState property. Its value is '-1'. MSI (c) (50:A4) [10:14:25:756]: Entering CMsiConfigurationManager::SetLastUsedSource. MSI (c) (50:A4) [10:14:25:756]: User policy value 'SearchOrder' is 'nmu' MSI (c) (50:A4) [10:14:25:756]: Adding new sources is allowed. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'. MSI (c) (50:A4) [10:14:25:756]: Package name extracted from package path: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Package to be registered: 'python-2.4.msi' MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2729 MSI (c) (50:A4) [10:14:25:756]: Note: 1: 2262 2: AdminProperties 3: -2147287038 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'DisableMsi' is 0 MSI (c) (50:A4) [10:14:25:756]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: User policy value 'AlwaysInstallElevated' is 0 MSI (c) (50:A4) [10:14:25:756]: Running product '{82D9302E- F209-4805-B548-52087047483A}' with user privileges: It's not assigned. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'C:\Downloads'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1104'. MSI (c) (50:A4) [10:14:25:756]: TRANSFORMS property is now: MSI (c) (50:A4) [10:14:25:756]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'. MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Favorites MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\NetHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\PrintHood MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Recent MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\SendTo MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Templates MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Local Settings\Application Data MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\My Documents\My Pictures MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu\Programs MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Start Menu MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\kyo\Desktop MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Administrative Tools MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs\Startup MSI (c) (50:A4) [10:14:25:756]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu\Programs MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Start Menu MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\All Users\Desktop MSI (c) (50:A4) [10:14:25:766]: SHELL32::SHGetFolderPath returned: C:\WINDOWS\Fonts MSI (c) (50:A4) [10:14:25:766]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16 MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding USERNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding COMPANYNAME property. Its value is ' '. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\DOCUME~1 \kyo\LOCALS~1\Temp\a0b14.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding OriginalDatabase property. Its value is 'C:\Downloads\python- 2.4.msi'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SourceDir property. Its value is 'C:\Downloads\'. MSI (c) (50:A4) [10:14:25:766]: PROPERTY CHANGE: Adding SOURCEDIR property. Its value is 'C:\Downloads\'. MSI (c) (50:A8) [10:14:25:766]: PROPERTY CHANGE: Adding VersionHandler property. Its value is '3.00'. MSI (c) (50:A8) [10:14:25:766]: Note: 1: 2262 2: ControlCondition 3: -2147287038 === Logging started: 2004-12-6 10:14:25 === MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: PatchPackage 3: -2147287038 MSI (c) (50:A4) [10:14:25:796]: Machine policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: User policy value 'DisableRollback' is 0 MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'. MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: INSTALL Action start 10:14:25: INSTALL. MSI (c) (50:A4) [10:14:25:796]: UI Sequence table 'InstallUISequence' is present and populated. MSI (c) (50:A4) [10:14:25:796]: Running UISequence MSI (c) (50:A4) [10:14:25:796]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'. MSI (c) (50:A4) [10:14:25:796]: Doing action: LaunchConditions Action start 10:14:25: LaunchConditions. MSI (c) (50:A4) [10:14:25:796]: Note: 1: 2262 2: LaunchCondition 3: -2147287038 Action ended 10:14:25: LaunchConditions. Return value 1. MSI (c) (50:A4) [10:14:25:796]: Skipping action: PrepareDlg (condition is false) MSI (c) (50:A4) [10:14:25:796]: Doing action: WhichUsersDlg Action start 10:14:25: WhichUsersDlg. MSI (c) (50:A8) [10:14:25:796]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. VerdanaBold10, Verdana, 1 MSI (c) (50:A8) [10:14:25:806]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8, Tahoma, 1 Action 10:14:25: WhichUsersDlg. Dialog created MSI (c) (50:A8) [10:14:25:866]: Note: 1: 2731 2: 0 MSI (c) (50:A8) [10:14:26:848]: PROPERTY CHANGE: Adding ALLUSERS property. Its value is '1'. Action ended 10:14:26: WhichUsersDlg. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: FindRelatedProducts Action start 10:14:26: FindRelatedProducts. Action ended 10:14:26: FindRelatedProducts. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: AppSearch Action start 10:14:26: AppSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: AppSearch 3: -2147287038 Action ended 10:14:26: AppSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: CCPSearch Action start 10:14:26: CCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: CCPSearch. Return value 1. MSI (c) (50:A4) [10:14:26:868]: Doing action: RMCCPSearch Action start 10:14:26: RMCCPSearch. MSI (c) (50:A4) [10:14:26:868]: Note: 1: 2262 2: CCPSearch 3: -2147287038 Action ended 10:14:26: RMCCPSearch. Return value 0. MSI (c) (50:A4) [10:14:26:868]: Doing action: ValidateProductID Action start 10:14:26: ValidateProductID. Action ended 10:14:26: ValidateProductID. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: InitialTargetDir Action start 10:14:26: InitialTargetDir. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\Python24'. Action ended 10:14:26: InitialTargetDir. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Doing action: SetDLLDirToSystem32 Action start 10:14:26: SetDLLDirToSystem32. MSI (c) (50:A4) [10:14:26:878]: PROPERTY CHANGE: Adding DLLDIR property. Its value is 'C:\WINDOWS\system32\'. Action ended 10:14:26: SetDLLDirToSystem32. Return value 1. MSI (c) (50:A4) [10:14:26:878]: Skipping action: SetDLLDirToTarget (condition is false) MSI (c) (50:A4) [10:14:26:878]: Doing action: CostInitialize Action start 10:14:26: CostInitialize. MSI (c) (50:A4) [10:14:26:878]: Machine policy value 'MaxPatchCacheSize' is 10 MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding ROOTDRIVE property. Its value is 'D:\'. MSI (c) (50:A4) [10:14:26:908]: PROPERTY CHANGE: Adding CostingComplete property. Its value is '0'. Action ended 10:14:26: CostInitialize. Return value 1. MSI (c) (50:A4) [10:14:26:908]: Doing action: FileCost Action start 10:14:26: FileCost. MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MsiAssembly 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: IniFile 3: - 2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: MoveFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A4) [10:14:26:908]: Note: 1: 2262 2: ReserveCost 3: -2147287038 Action ended 10:14:26: FileCost. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: IsolateComponents Action start 10:14:26: IsolateComponents. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: IsolatedComponent 3: -2147287038 MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 Action ended 10:14:26: IsolateComponents. Return value 1. MSI (c) (50:A4) [10:14:26:918]: Doing action: CostFinalize Action start 10:14:26: CostFinalize. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (50:A4) [10:14:26:918]: Note: 1: 2262 2: Patch 3: - 2147287038 MSI (c) (50:A4) [10:14:26:928]: Note: 1: 2262 2: Condition 3: -2147287038 MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Python24'. Its new value: 'C:\Python24\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding MenuDir property. Its value is 'C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Doc property. Its value is 'C:\Python24\Doc\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl property. Its value is 'C:\Python24\tcl\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dde1.2 property. Its value is 'C:\Python24\tcl\dde1.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding reg1.1 property. Its value is 'C:\Python24\tcl\reg1.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcl8.4 property. Its value is 'C:\Python24\tcl\tcl8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encoding property. Its value is 'C:\Python24\tcl\tcl8.4 \encoding\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http1.0 property. Its value is 'C:\Python24\tcl\tcl8.4\http1.0\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding http2.4 property. Its value is 'C:\Python24\tcl\tcl8.4\http2.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgcat1.3 property. Its value is 'C:\Python24\tcl\tcl8.4 \msgcat1.3\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding opt0.4 property. Its value is 'C:\Python24\tcl\tcl8.4\opt0.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tcltest2.2 property. Its value is 'C:\Python24\tcl\tcl8.4 \tcltest2.2\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tix8.1 property. Its value is 'C:\Python24\tcl\tix8.1\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bitmaps property. Its value is 'C:\Python24\tcl\tix8.1 \bitmaps\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pref property. Its value is 'C:\Python24\tcl\tix8.1\pref\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tk8.4 property. Its value is 'C:\Python24\tcl\tk8.4\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding demos property. Its value is 'C:\Python24\tcl\tk8.4\demos\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images1 property. Its value is 'C:\Python24\tcl\tk8.4 \demos\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding images property. Its value is 'C:\Python24\tcl\tk8.4\images\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding msgs property. Its value is 'C:\Python24\tcl\tk8.4\msgs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding libs property. Its value is 'C:\Python24\libs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding include property. Its value is 'C:\Python24\include\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding DLLs property. Its value is 'C:\Python24\DLLs\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Lib property. Its value is 'C:\Python24\Lib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding bsddb property. Its value is 'C:\Python24\Lib\bsddb\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test2 property. Its value is 'C:\Python24\Lib\bsddb\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding compiler property. Its value is 'C:\Python24\Lib\compiler\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding curses property. Its value is 'C:\Python24\Lib\curses\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding distutils property. Its value is 'C:\Python24\Lib\distutils\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding command property. Its value is 'C:\Python24 \Lib\distutils\command\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding tests property. Its value is 'C:\Python24\Lib\distutils\tests\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding email property. Its value is 'C:\Python24\Lib\email\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test1 property. Its value is 'C:\Python24\Lib\email\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding data property. Its value is 'C:\Python24\Lib\email\test\data\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding encodings property. Its value is 'C:\Python24\Lib\encodings\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding hotshot property. Its value is 'C:\Python24\Lib\hotshot\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding idlelib property. Its value is 'C:\Python24\Lib\idlelib\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Icons property. Its value is 'C:\Python24\Lib\idlelib\Icons\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_old property. Its value is 'C:\Python24\Lib\lib-old\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding lib_tk property. Its value is 'C:\Python24\Lib\lib-tk\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding logging property. Its value is 'C:\Python24\Lib\logging\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding site_packages property. Its value is 'C:\Python24\Lib\site- packages\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding test property. Its value is 'C:\Python24\Lib\test\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding decimaltestdata property. Its value is 'C:\Python24 \Lib\test\decimaltestdata\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding output property. Its value is 'C:\Python24\Lib\test\output\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding xml property. Its value is 'C:\Python24\Lib\xml\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding dom property. Its value is 'C:\Python24\Lib\xml\dom\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding parsers property. Its value is 'C:\Python24\Lib\xml\parsers\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding sax property. Its value is 'C:\Python24\Lib\xml\sax\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Tools property. Its value is 'C:\Python24\Tools\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding webchecker property. Its value is 'C:\Python24 \Tools\webchecker\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding versioncheck property. Its value is 'C:\Python24 \Tools\versioncheck\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding Scripts property. Its value is 'C:\Python24\Tools\Scripts\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding i18n property. Its value is 'C:\Python24\Tools\i18n\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding pynche property. Its value is 'C:\Python24\Tools\pynche\'. MSI (c) (50:A4) [10:14:26:928]: PROPERTY CHANGE: Adding X property. Its value is 'C:\Python24\Tools\pynche\X\'. MSI (c) (50:A4) [10:14:26:928]: Target path resolution complete. Dumping Directory table... MSI (c) (50:A4) [10:14:26:928]: Note: target paths subject to change (via custom actions or browsing) MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: TARGETDIR , Object: C:\Python24MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: WindowsFolder , Object: C:\WINDOWSMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: ProgramMenuFolder , Object: C:\Documents and Settings\kyo\Start Menu\ProgramsMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: MenuDir , Object: C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: Doc , Object: C:\Python24\DocMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl , Object: C:\Python24\tclMSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: dde1.2 , Object: C:\Python24\tcl\dde1.2MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: reg1.1 , Object: C:\Python24\tcl\reg1.1MSI (c) (50:A4) [10:14:26:928]: Dir (target): Key: tcl8.4 , Object: C:\Python24\tcl\tcl8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encoding , Object: C:\Python24\tcl\tcl8.4\encodingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http1.0 , Object: C:\Python24\tcl\tcl8.4\http1.0MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: http2.4 , Object: C:\Python24\tcl\tcl8.4\http2.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgcat1.3 , Object: C:\Python24\tcl\tcl8.4\msgcat1.3MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: opt0.4 , Object: C:\Python24\tcl\tcl8.4\opt0.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tcltest2.2 , Object: C:\Python24\tcl\tcl8.4\tcltest2.2MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tix8.1 , Object: C:\Python24\tcl\tix8.1MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bitmaps , Object: C:\Python24\tcl\tix8.1\bitmapsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pref , Object: C:\Python24\tcl\tix8.1\prefMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tk8.4 , Object: C:\Python24\tcl\tk8.4MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: demos , Object: C:\Python24\tcl\tk8.4\demosMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images1 , Object: C:\Python24\tcl\tk8.4\demos\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: images , Object: C:\Python24\tcl\tk8.4\imagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: msgs , Object: C:\Python24\tcl\tk8.4\msgsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: libs , Object: C:\Python24\libsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: include , Object: C:\Python24\includeMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLs , Object: C:\Python24\DLLsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Lib , Object: C:\Python24\LibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: bsddb , Object: C:\Python24\Lib\bsddbMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test2 , Object: C:\Python24\Lib\bsddb\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: compiler , Object: C:\Python24\Lib\compilerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: curses , Object: C:\Python24\Lib\cursesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: distutils , Object: C:\Python24\Lib\distutilsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: command , Object: C:\Python24\Lib\distutils\commandMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: tests , Object: C:\Python24\Lib\distutils\testsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: email , Object: C:\Python24\Lib\emailMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test1 , Object: C:\Python24\Lib\email\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: data , Object: C:\Python24\Lib\email\test\dataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: encodings , Object: C:\Python24\Lib\encodingsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: hotshot , Object: C:\Python24\Lib\hotshotMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: idlelib , Object: C:\Python24\Lib\idlelibMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Icons , Object: C:\Python24\Lib\idlelib\IconsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_old , Object: C:\Python24\Lib\lib-oldMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: lib_tk , Object: C:\Python24\Lib\lib-tkMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: logging , Object: C:\Python24\Lib\loggingMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: site_packages , Object: C:\Python24\Lib\site-packagesMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: test , Object: C:\Python24\Lib\testMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: decimaltestdata , Object: C:\Python24 \Lib\test\decimaltestdataMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: output , Object: C:\Python24\Lib\test\outputMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: xml , Object: C:\Python24\Lib\xmlMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: dom , Object: C:\Python24\Lib\xml\domMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: parsers , Object: C:\Python24\Lib\xml\parsersMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: sax , Object: C:\Python24\Lib\xml\saxMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: DLLDIR , Object: C:\WINDOWS\system32MSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Tools , Object: C:\Python24\ToolsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: webchecker , Object: C:\Python24\Tools\webcheckerMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: versioncheck , Object: C:\Python24\Tools\versioncheckMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: Scripts , Object: C:\Python24\Tools\ScriptsMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: i18n , Object: C:\Python24\Tools\i18nMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: pynche , Object: C:\Python24\Tools\pyncheMSI (c) (50:A4) [10:14:26:938]: Dir (target): Key: X , Object: C:\Python24\Tools\pynche\XMSI (c) (50:A4) [10:14:26:938]: PROPERTY CHANGE: Adding INSTALLLEVEL property. Its value is '1'. Action ended 10:14:26: CostFinalize. Return value 1. MSI (c) (50:A4) [10:14:26:938]: Doing action: MigrateFeatureStates Action start 10:14:26: MigrateFeatureStates. Action ended 10:14:26: MigrateFeatureStates. Return value 0. MSI (c) (50:A4) [10:14:26:938]: Doing action: SelectDirectoryDlg Action start 10:14:26: SelectDirectoryDlg. MSI (c) (50:A8) [10:14:26:958]: Note: 1: 2262 2: Error 3: - 2147287038 Info 2898. DlgFont8__UL, Tahoma, 134 Action 10:14:26: SelectDirectoryDlg. Dialog created MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2205 2: 3: _RemoveFilePath MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: DuplicateFile 3: -2147287038 MSI (c) (50:A8) [10:14:27:028]: Note: 1: 2262 2: ReserveCost 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: TypeLib 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: BindImage 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: ProgId 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: PublishComponent 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: SelfReg 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Extension 3: -2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Font 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2262 2: Class 3: - 2147287038 MSI (c) (50:A8) [10:14:27:098]: Note: 1: 2727 2: MSI (c) (50:A8) [10:14:27:669]: Doing action: CheckDir Action start 10:14:27: CheckDir. MSI (c) (50:70) [10:14:27:679]: Cloaking enabled. MSI (c) (50:70) [10:14:27:679]: Attempting to enable all disabled priveleges before calling Install on Server MSI (c) (50:70) [10:14:27:679]: Connected to service for CA interface. MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F348, pcchPathBuf: F7F344, pcchArgsOffset: F7F2A4 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 MSI (c) (50:6C) [10:14:27:769]: Entering MsiProvideComponentFromDescriptor. Descriptor: i7R (d6jnX8iv0l4VX6{Ioleaut32>M5KDYSUnf(HA*L[xeX)y, PathBuf: F7F2F4, pcchPathBuf: F7F2F0, pcchArgsOffset: F7F250 MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value MSI (c) (50:6C) [10:14:27:769]: MsiProvideComponentFromDescriptor is returning: 0 Action ended 10:14:27: CheckDir. Return value 3. MSI (c) (50:A8) [10:14:27:829]: Note: 1: 2262 2: Error 3: - 2147287038 DEBUG: Error 2896: Executing action CheckDir failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: CheckDir, , Action ended 10:14:27: SelectDirectoryDlg. Return value 3. MSI (c) (50:A4) [10:14:27:829]: Doing action: FatalError Action start 10:14:27: FatalError. Action 10:14:27: FatalError. Dialog created Action ended 10:14:28: FatalError. Return value 2. Action ended 10:14:28: INSTALL. Return value 3. MSI (c) (50:A4) [10:14:28:510]: Destroying RemoteAPI object. MSI (c) (50:70) [10:14:28:510]: Custom Action Manager thread ending. Property(C): X = C:\Python24\Tools\pynche\XProperty(C): UpgradeCode = {65E6DE48-A358-434D-AA4F- 4AF72DB4718F} Property(C): ProductName = Python 2.4 Property(C): ProductCode = {82D9302E-F209-4805-B548- 52087047483A} Property(C): ProductVersion = 2.4.150 Property(C): Manufacturer = Martin v. L鰓is Property(C): ProductLanguage = 1033 Property(C): VersionNT = 501 Property(C): WhichUsers = ALL Property(C): TARGETDIR = C:\Python24Property(C): Tools = C:\Python24\ToolsProperty(C): DefaultUIFont = DlgFont8 Property(C): ErrorDialog = ErrorDlg Property(C): Progress1 = Install Property(C): Progress2 = installs Property(C): MaintenanceForm_Action = Repair Property(C): DLLDIR = C:\WINDOWS\system32Property(C): SourceDir = C:\DownloadsProperty(C): Lib = C:\Python24\LibProperty(C): xml = C:\Python24\Lib\xmlProperty(C): sax = C:\Python24\Lib\xml\saxProperty(C): parsers = C:\Python24\Lib\xml\parsersProperty(C): dom = C:\Python24\Lib\xml\domProperty(C): test = C:\Python24\Lib\testProperty(C): output = C:\Python24\Lib\test\outputProperty(C): decimaltestdata = C:\Python24 \Lib\test\decimaltestdataProperty(C): site_packages = C:\Python24\Lib\site-packagesProperty(C): logging = C:\Python24\Lib\loggingProperty(C): lib_tk = C:\Python24\Lib\lib-tkProperty(C): lib_old = C:\Python24\Lib\lib-oldProperty(C): idlelib = C:\Python24\Lib\idlelibProperty(C): Icons = C:\Python24\Lib\idlelib\IconsProperty(C): hotshot = C:\Python24\Lib\hotshotProperty(C): encodings = C:\Python24\Lib\encodingsProperty(C): email = C:\Python24\Lib\emailProperty(C): test1 = C:\Python24\Lib\email\testProperty(C): data = C:\Python24\Lib\email\test\dataProperty(C): distutils = C:\Python24\Lib\distutilsProperty(C): tests = C:\Python24\Lib\distutils\testsProperty(C): command = C:\Python24\Lib\distutils\commandProperty(C): curses = C:\Python24\Lib\cursesProperty(C): compiler = C:\Python24\Lib\compilerProperty(C): bsddb = C:\Python24\Lib\bsddbProperty(C): test2 = C:\Python24\Lib\bsddb\testProperty(C): DLLs = C:\Python24\DLLsProperty(C): include = C:\Python24\includeProperty(C): libs = C:\Python24\libsProperty(C): tcl = C:\Python24\tclProperty(C): tk8.4 = C:\Python24\tcl\tk8.4Property(C): msgs = C:\Python24\tcl\tk8.4\msgsProperty(C): images = C:\Python24\tcl\tk8.4\imagesProperty(C): demos = C:\Python24\tcl\tk8.4\demosProperty(C): images1 = C:\Python24\tcl\tk8.4\demos\imagesProperty(C): tix8.1 = C:\Python24\tcl\tix8.1Property(C): pref = C:\Python24\tcl\tix8.1\prefProperty(C): bitmaps = C:\Python24\tcl\tix8.1\bitmapsProperty(C): tcl8.4 = C:\Python24\tcl\tcl8.4Property(C): tcltest2.2 = C:\Python24\tcl\tcl8.4\tcltest2.2Property(C): opt0.4 = C:\Python24\tcl\tcl8.4\opt0.4Property(C): msgcat1.3 = C:\Python24\tcl\tcl8.4\msgcat1.3Property(C): http2.4 = C:\Python24\tcl\tcl8.4\http2.4Property(C): http1.0 = C:\Python24\tcl\tcl8.4\http1.0Property(C): encoding = C:\Python24\tcl\tcl8.4\encodingProperty(C): reg1.1 = C:\Python24\tcl\reg1.1Property(C): dde1.2 = C:\Python24\tcl\dde1.2Property(C): i18n = C:\Python24\Tools\i18nProperty(C): pynche = C:\Python24\Tools\pyncheProperty(C): Scripts = C:\Python24\Tools\ScriptsProperty(C): versioncheck = C:\Python24\Tools\versioncheckProperty(C): webchecker = C:\Python24\Tools\webcheckerProperty(C): Doc = C:\Python24\DocProperty(C): ProgramMenuFolder = C:\Documents and Settings\kyo\Start Menu\ProgramsProperty(C): MenuDir = C:\Documents and Settings\kyo\Start Menu\Programs\Python 2.4Property(C): SecureCustomProperties = REMOVEOLDSNAPSHOT;REMOVEOLDVERSION Property(C): PackageCode = {41AF8B44-C87F-44CE-B1B4- A6C8DD67A0BB} Property(C): ProductState = -1 Property(C): PackagecodeChanging = 1 Property(C): CURRENTDIRECTORY = C:\Downloads Property(C): CLIENTUILEVEL = 0 Property(C): CLIENTPROCESSID = 1104 Property(C): VersionDatabase = 200 Property(C): VersionMsi = 3.00 Property(C): WindowsBuild = 2600 Property(C): ServicePackLevel = 2 Property(C): ServicePackLevelMinor = 0 Property(C): MsiNTProductType = 1 Property(C): WindowsFolder = C:\WINDOWSProperty(C): WindowsVolume = C:Property(C): SystemFolder = C:\WINDOWS\system32Property(C): System16Folder = C:\WINDOWS\systemProperty(C): RemoteAdminTS = 1 Property(C): TempFolder = C:\DOCUME~1\kyo\LOCALS~1 \TempProperty(C): ProgramFilesFolder = C:\Program FilesProperty(C): CommonFilesFolder = C:\Program Files\Common FilesProperty(C): AppDataFolder = C:\Documents and Settings\kyo\Application DataProperty(C): FavoritesFolder = C:\Documents and Settings\kyo\FavoritesProperty(C): NetHoodFolder = C:\Documents and Settings\kyo\NetHoodProperty(C): PersonalFolder = C:\Documents and Settings\kyo\My DocumentsProperty(C): PrintHoodFolder = C:\Documents and Settings\kyo\PrintHoodProperty(C): RecentFolder = C:\Documents and Settings\kyo\RecentProperty(C): SendToFolder = C:\Documents and Settings\kyo\SendToProperty(C): TemplateFolder = C:\Documents and Settings\kyo\TemplatesProperty(C): CommonAppDataFolder = C:\Documents and Settings\All Users\Application DataProperty(C): LocalAppDataFolder = C:\Documents and Settings\kyo\Local Settings\Application DataProperty(C): MyPicturesFolder = C:\Documents and Settings\kyo\My Documents\My PicturesProperty(C): AdminToolsFolder = C:\Documents and Settings\kyo\Start Menu\Programs\Administrative ToolsProperty(C): StartupFolder = C:\Documents and Settings\kyo\Start Menu\Programs\StartupProperty(C): StartMenuFolder = C:\Documents and Settings\kyo\Start MenuProperty(C): DesktopFolder = C:\Documents and Settings\kyo\DesktopProperty(C): FontsFolder = C:\WINDOWS\FontsProperty(C): GPTSupport = 1 Property(C): OLEAdvtSupport = 1 Property(C): ShellAdvtSupport = 1 Property(C): Intel = 6 Property(C): PhysicalMemory = 511 Property(C): VirtualMemory = 980 Property(C): AdminUser = 1 Property(C): LogonUser = kyo Property(C): UserSID = S-1-5-21-3423288844-3762864566- 3052223681-1005 Property(C): UserLanguageID = 2052 Property(C): ComputerName = KYO-M Property(C): SystemLanguageID = 2052 Property(C): ScreenX = 1280 Property(C): ScreenY = 800 Property(C): CaptionHeight = 19 Property(C): BorderTop = 1 Property(C): BorderSide = 1 Property(C): TextHeight = 16 Property(C): ColorBits = 16 Property(C): TTCSupport = 1 Property(C): MsiNetAssemblySupport = 1.1.4322.2032 Property(C): MsiWin32AssemblySupport = 5.1.2600.2180 Property(C): RedirectedDllSupport = 2 Property(C): Time = 10:14:28 Property(C): Date = 2004-12-6 Property(C): Privileged = 1 Property(C): USERNAME = Property(C): COMPANYNAME = Property(C): DATABASE = C:\DOCUME~1\kyo\LOCALS~1 \Temp\a0b14.msi Property(C): OriginalDatabase = C:\Downloads\python-2.4.msi Property(C): SOURCEDIR = C:\DownloadsProperty(C): VersionHandler = 3.00 Property(C): UILevel = 5 Property(C): ACTION = INSTALL Property(C): EXECUTEACTION = INSTALL Property(C): ROOTDRIVE = D:Property(C): ALLUSERS = 1 Property(C): CostingComplete = 1 Property(C): OutOfDiskSpace = 0 Property(C): OutOfNoRbDiskSpace = 0 Property(C): PrimaryVolumeSpaceAvailable = 0 Property(C): PrimaryVolumeSpaceRequired = 0 Property(C): PrimaryVolumeSpaceRemaining = 0 Property(C): INSTALLLEVEL = 1 === Logging stopped: 2004-12-6 10:14:28 === MSI (c) (50:A4) [10:14:28:560]: Note: 1: 1708 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Note: 1: 2262 2: Error 3: - 2147287038 MSI (c) (50:A4) [10:14:28:560]: Product: Python 2.4 -- Installation failed. MSI (c) (50:A4) [10:14:28:560]: Grabbed execution mutex. MSI (c) (50:A4) [10:14:28:560]: Cleaning up uninstalled install packages, if any exist MSI (c) (50:A4) [10:14:28:570]: MainEngineThread is returning 1603 === Verbose logging stopped: 2004-12-6 10:14:28 === ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-05 20:49 Message: Logged In: YES user_id=21627 To produce a log file, please run msiexec /i python-2.4.msi /l*v python.log and attach the resulting python.log to this report. ---------------------------------------------------------------------- Comment By: guan zi jing (guanzijing) Date: 2004-12-04 03:45 Message: Logged In: YES user_id=923521 Yes, I did. And I have checked the msi version: 3.0.3790.2180. Where can I get the additional information about the install error. (eg. log file ....) ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-12-03 13:31 Message: Logged In: YES user_id=752496 Did you verify your downloaded file with md5sum? What error the installer gives you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470 From noreply at sourceforge.net Fri Dec 24 16:50:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:02 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 04:21 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 10:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 02:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-14 23:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 12:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 05:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 12:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 11:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 05:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 14:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 12:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 00:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 12:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 11:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 11:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 15:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 15:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 14:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 11:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 11:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 11:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 01:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 13:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 05:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 02:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 23:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 13:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 12:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 03:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 11:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 11:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 13:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 13:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 10:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 12:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 22:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 14:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 05:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 21:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 13:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 06:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 07:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 02:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 08:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 08:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 19:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 17:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 09:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 01:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 18:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 12:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 13:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 07:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Fri Dec 24 20:35:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:04 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-24 11:35 Message: Logged In: YES user_id=71407 > Can this be closed? As far as I know my patch for the release23-maint line is still not checked in. This patch is (almost) the same as the one that is now in 2.4 final and does not appear to cause any problems. Could someone please apply my patch to the release23-maint branch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 07:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 00:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-14 21:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 10:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 03:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 10:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 09:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 03:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 12:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Dec 30 11:22:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:06 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 11:22 Message: Logged In: YES user_id=21627 The 2.3 patch is wrong (assuming you are talking about py234c1_socketmodule_patch). It conditionalizes inclusion of addrinfo.h on __sgi being defined; thus breaking all systems that require inclusion of addrinfo.h. Please attach patches rather than pasting them in the comment box, and please use unified or context rather than plain diffs. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-24 20:35 Message: Logged In: YES user_id=71407 > Can this be closed? As far as I know my patch for the release23-maint line is still not checked in. This patch is (almost) the same as the one that is now in 2.4 final and does not appear to cause any problems. Could someone please apply my patch to the release23-maint branch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 16:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 09:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-15 06:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 19:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 12:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 19:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 18:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 12:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 21:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 19:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 07:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 19:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 18:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 18:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 22:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 22:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 21:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 19:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 18:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 18:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 18:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 08:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 20:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 12:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 09:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 06:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 20:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 20:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 10:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 17:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 17:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 19:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 19:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 16:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 18:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 04:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 21:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 12:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 04:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Dec 30 11:53:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:08 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 02:53 Message: Logged In: YES user_id=71407 > The 2.3 patch is wrong (assuming you are talking about > py234c1_socketmodule_patch). I am talking about the patch in my message from 2004-09-14 21:20. > Please attach patches rather than pasting them in the > comment box, and please use unified or context rather than > plain diffs. All right. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 02:22 Message: Logged In: YES user_id=21627 The 2.3 patch is wrong (assuming you are talking about py234c1_socketmodule_patch). It conditionalizes inclusion of addrinfo.h on __sgi being defined; thus breaking all systems that require inclusion of addrinfo.h. Please attach patches rather than pasting them in the comment box, and please use unified or context rather than plain diffs. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-24 11:35 Message: Logged In: YES user_id=71407 > Can this be closed? As far as I know my patch for the release23-maint line is still not checked in. This patch is (almost) the same as the one that is now in 2.4 final and does not appear to cause any problems. Could someone please apply my patch to the release23-maint branch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 07:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 00:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-14 21:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 10:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 03:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 10:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 09:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 03:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 12:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Dec 30 12:49:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:10 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 19:21 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-30 22:49 Message: Logged In: YES user_id=29957 It's probably also worth noting that socketmodule seems to require different things for every single release of Irix. I'd hope that any new patch wouldn't break other versions of Irix. (sgi+socketmodule is becoming the new hp/ux+threads) ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 21:53 Message: Logged In: YES user_id=71407 > The 2.3 patch is wrong (assuming you are talking about > py234c1_socketmodule_patch). I am talking about the patch in my message from 2004-09-14 21:20. > Please attach patches rather than pasting them in the > comment box, and please use unified or context rather than > plain diffs. All right. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 21:22 Message: Logged In: YES user_id=21627 The 2.3 patch is wrong (assuming you are talking about py234c1_socketmodule_patch). It conditionalizes inclusion of addrinfo.h on __sgi being defined; thus breaking all systems that require inclusion of addrinfo.h. Please attach patches rather than pasting them in the comment box, and please use unified or context rather than plain diffs. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-25 06:35 Message: Logged In: YES user_id=71407 > Can this be closed? As far as I know my patch for the release23-maint line is still not checked in. This patch is (almost) the same as the one that is now in 2.4 final and does not appear to cause any problems. Could someone please apply my patch to the release23-maint branch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-25 02:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 17:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-15 14:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-14 03:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 20:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-08 03:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-08 02:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 20:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-07 05:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-06 03:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 15:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-27 03:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-27 02:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-27 02:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 06:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 06:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-26 05:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-26 03:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 02:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-26 02:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-26 02:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 16:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-11 04:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 20:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 17:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 15:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 14:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 04:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 02:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 02:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 18:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-09 03:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-04 03:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-13 05:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-23 05:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-23 02:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-17 04:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 14:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-25 05:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 20:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 12:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-23 04:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 21:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 22:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 17:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-18 04:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 23:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 23:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 10:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 08:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-01 00:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 16:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 09:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-13 03:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-06 04:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 22:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Dec 30 14:43:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:12 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 05:43 Message: Logged In: YES user_id=71407 > It's probably also worth noting that socketmodule seems to > require different things for every single release of Irix. > I'd hope that any new patch wouldn't break other versions > of Irix. The patch in question is not new. The same patch is in 2.4 final and does not appear to cause any problems. I maintain two IRIX machines with versions 6.5.10 and 6.5.21. These machines are not meant to be upgraded. I have access to another IRIX machine which is upgraded regularly. This machine is currently running version 6.5.25. Python 2.4 works fine on all three machines. > (sgi+socketmodule is becoming the new hp/ux+threads) I will keep an eye on IRIX/Python compatibility. If we could just work out a way of applying patches in a timely fashion there would be almost no problem. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-30 03:49 Message: Logged In: YES user_id=29957 It's probably also worth noting that socketmodule seems to require different things for every single release of Irix. I'd hope that any new patch wouldn't break other versions of Irix. (sgi+socketmodule is becoming the new hp/ux+threads) ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 02:53 Message: Logged In: YES user_id=71407 > The 2.3 patch is wrong (assuming you are talking about > py234c1_socketmodule_patch). I am talking about the patch in my message from 2004-09-14 21:20. > Please attach patches rather than pasting them in the > comment box, and please use unified or context rather than > plain diffs. All right. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 02:22 Message: Logged In: YES user_id=21627 The 2.3 patch is wrong (assuming you are talking about py234c1_socketmodule_patch). It conditionalizes inclusion of addrinfo.h on __sgi being defined; thus breaking all systems that require inclusion of addrinfo.h. Please attach patches rather than pasting them in the comment box, and please use unified or context rather than plain diffs. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-24 11:35 Message: Logged In: YES user_id=71407 > Can this be closed? As far as I know my patch for the release23-maint line is still not checked in. This patch is (almost) the same as the one that is now in 2.4 final and does not appear to cause any problems. Could someone please apply my patch to the release23-maint branch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 07:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 00:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-14 21:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 10:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 03:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 10:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 09:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 03:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 12:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 10:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-03 22:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Dec 30 14:55:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 3 06:17:14 2005 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 14:55 Message: Logged In: YES user_id=21627 I have applied this patch as socketmodule.c 1.271.6.9. As for timeliness: it is confusing to have "half-closed" reports. After the patch had been applied to the mainline, and not simultaneously to an older branch, this patch should have been closed, and a new patch submitted, where the subject indicates that this is a backport of a patch that has already been applied. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 14:43 Message: Logged In: YES user_id=71407 > It's probably also worth noting that socketmodule seems to > require different things for every single release of Irix. > I'd hope that any new patch wouldn't break other versions > of Irix. The patch in question is not new. The same patch is in 2.4 final and does not appear to cause any problems. I maintain two IRIX machines with versions 6.5.10 and 6.5.21. These machines are not meant to be upgraded. I have access to another IRIX machine which is upgraded regularly. This machine is currently running version 6.5.25. Python 2.4 works fine on all three machines. > (sgi+socketmodule is becoming the new hp/ux+threads) I will keep an eye on IRIX/Python compatibility. If we could just work out a way of applying patches in a timely fashion there would be almost no problem. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-12-30 12:49 Message: Logged In: YES user_id=29957 It's probably also worth noting that socketmodule seems to require different things for every single release of Irix. I'd hope that any new patch wouldn't break other versions of Irix. (sgi+socketmodule is becoming the new hp/ux+threads) ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 11:53 Message: Logged In: YES user_id=71407 > The 2.3 patch is wrong (assuming you are talking about > py234c1_socketmodule_patch). I am talking about the patch in my message from 2004-09-14 21:20. > Please attach patches rather than pasting them in the > comment box, and please use unified or context rather than > plain diffs. All right. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-12-30 11:22 Message: Logged In: YES user_id=21627 The 2.3 patch is wrong (assuming you are talking about py234c1_socketmodule_patch). It conditionalizes inclusion of addrinfo.h on __sgi being defined; thus breaking all systems that require inclusion of addrinfo.h. Please attach patches rather than pasting them in the comment box, and please use unified or context rather than plain diffs. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-24 20:35 Message: Logged In: YES user_id=71407 > Can this be closed? As far as I know my patch for the release23-maint line is still not checked in. This patch is (almost) the same as the one that is now in 2.4 final and does not appear to cause any problems. Could someone please apply my patch to the release23-maint branch? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-24 16:50 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-10-26 09:27 Message: Logged In: YES user_id=71407 How is my 2004-09-09 patch for the main line doing in 2.4b1? Does my 2004-09-14 submission for the release23-maint branch need any tweaking? AFAICT from the viewcvs page at SourceForge it is still not checked in. Thanks! ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-15 06:20 Message: Logged In: YES user_id=71407 Hi Trent, > Sorry for the delay. Your final socketmodule changes are > finally checked in. Thanks!!! > Yes, that is the correct tag for the latest Py2.3 code. > So you are going to look into the relevant bits to backport > for Py2.3 compilation on IRIX then? Here is the patch (based on socketmodule.c CVS rev. 1.271.6.8): Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.271.6.8 diff -r1.271.6.8 socketmodule.c 194a195 > #undef _SGIAPI /* to avoid warning */ 196a198,206 > #undef _XOPEN_SOURCE > #include > #include > #include > #ifdef _SS_ALIGNSIZE > #define HAVE_GETADDRINFO 1 > #define HAVE_GETNAMEINFO 1 > #endif > 262c272,284 < #include "addrinfo.h" --- > /* include Python's addrinfo.h unless it causes trouble */ > #if defined(__sgi) && _COMPILER_VERSION>700 && defined (_SS_ALIGNSIZE) > /* Do not include addinfo.h on some newer IRIX versions. > * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, > * for example, but not by 6.5.10. > */ > #elif defined(_MSC_VER) && _MSC_VER>1200 > /* Do not include addrinfo.h for MSVC7 or greater. > * addrinfo and EAI_* constants are defined in ws2tcpip.h > */ > #else > # include "addrinfo.h" > #endif Tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Tru64 UNIX V5.1, C V6.3-028 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_271_6 _8_patched_c Cheers, Ralf ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-13 19:50 Message: Logged In: YES user_id=34892 Ralf, Sorry for the delay. Your final socketmodule changes are finally checked in. Checking in socketmodule.c; /cvsroot/python/python/dist/src/Modules/socketmodule.c,v <-- socketmodule.c new revision: 1.306; previous revision: 1.305 >> Can you take over any relevant 2.3 work? > > Which CVS tag should I be using? release23-maint? Yes, that is the correct tag for the latest Py2.3 code. So you are going to look into the relevant bits to backport for Py2.3 compilation on IRIX then? Cheers, Trent ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-09 12:52 Message: Logged In: YES user_id=71407 Sorry for the delay. It took 6+ hours for revision 1.305 to show up in the anonymous cvs. > Do those other patch bits need to go in for IRIX compilation? Absolutely. I've made a new patch again, based on socketmodule.c revision 1.305: Index: socketmodule.c ============================================== ===================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c, v retrieving revision 1.305 diff -u -r1.305 socketmodule.c --- socketmodule.c 7 Sep 2004 17:48:26 -0000 1.305 +++ socketmodule.c 9 Sep 2004 10:25:29 -0000 @@ -192,8 +192,18 @@ /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ +#undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 +#undef _XOPEN_SOURCE +#include +#include +#include +#ifdef _SS_ALIGNSIZE +#define HAVE_GETADDRINFO 1 +#define HAVE_GETNAMEINFO 1 +#endif + #define HAVE_INET_PTON #include #endif Tested again on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 For your convenience and reference: wget http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_305_p atched_c It may be most convenient to wget the complete file as shown, mv, cvs diff. > Can you take over any relevant 2.3 work? Which CVS tag should I be using? release23-maint? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 19:51 Message: Logged In: YES user_id=34892 Now checked in to Python CVS (socketmodule.c revision 1.305) Ralf, Note that I just submitted the #ifdef'ery stuff that I posted and (I now see) not all the stuff that you have in http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_patch Do those other patch bits need to go in for IRIX compilation? Can you take over any relevant 2.3 work? ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-09-07 18:07 Message: Logged In: YES user_id=34892 > The new patch didn't make it into Python 2.4, alpha 3. > Is it still not good? No, I just dropped the ball. I'll look into it right now. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-09-07 12:49 Message: Logged In: YES user_id=883896 > #define _BSD_TYPES > You could try adding this to the top of bsddbmodule.c in > Python 2.3.4. I did as you suggested and added the define (before #include "Python.h") at the top of bsdmodule.c and _ssl.c. Both not compile for 2.3.4, with MIPSpro 7.4.2 without error. Thank you again! The last remaining warning reads: building 'bsddb185' extension cc -DNDEBUG -O -OPT:Olimit=0 -I. [...]-o build/temp.irix64-6.5-2.3/bsddbmodule.o ld -shared -all build/temp.irix64-6.5-2.3/bsddbmodule.o [...] -o build/lib.irix64-6.5-2.3/bsddb185.so *** WARNING: renaming "bsddb185" since importing it failed: 14768:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.3/bsddb185.so: dbopen ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-06 21:03 Message: Logged In: YES user_id=71407 > But it is not compileable in Python 2.3.4. That's expected because I took out this part of my original 2.3.4c1 patch: #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI #define _BSD_TYPES #endif 2.4 doesn't require this anymore because _BSD_TYPES is already defined in pyconfig.h. For 2.3.4 you have to put it back near the top of socketmodule.c. I'll post a patch against the 2.3 maintenance branch after the 2.4 patch is in the CVS. Holding my breath... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-05 19:39 Message: Logged In: NO The patch worked for python 2.4 a2. But I patched the configured source tree (no gmake distclean, ./configure). But it is not compileable in Python 2.3.4. Syntax error about "struct python.api" and some other. I will post this tomorrow (06.09.04). Environment: SGI Irix IP35, MipsPro cc 7.3.1.3, Irix 6.5.24. --maik./ ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-09-04 07:39 Message: Logged In: YES user_id=71407 The new patch didn't make it into Python 2.4, alpha 3. :( :( :( Is it still not good? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 19:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 18:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 18:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 22:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 22:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 21:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 19:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 18:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 18:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 18:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 08:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 20:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 12:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 09:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 06:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 20:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 20:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 10:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 17:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 17:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 19:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 19:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 16:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 18:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 04:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 21:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 12:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 04:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470